[security] PAPE Policy for RPs to force authentication without browser cookie

[Andrew Arnott]

Allen,

Is it really that bad of a privacy problem for the RP to learn how long ago
the user signed in?  Most OPs leave persistent cookies on the browser, so my
OP might say I logged in 3 seconds ago or 3 weeks ago.  Of what use is that
to an RP except to determine whether they can trust the OP's assertion about
my identity, and how might that adversely affect me?

I'm probably missing something simple.  Any explanation will be helpful.

Thanks.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Tue, Jun 30, 2009 at 9:23 PM, Allen Tom <atom at yahoo-inc.com> wrote:

> Many websites require users who are already authenticated to re-verify
> their password before entering a sensitive area.
>
> For instance, retailers like Amazon allow users to browse their website in
> a recognized state, but will verify the user's password in order to place an
> order. Similarly, Facebook requires logged in users to re-verify their
> password in order to manage their credit cards, and Yahoo and Google have
> similar password verification requirements in order to enter sensitive
> flows.
>
> The PAPE Extension seems to be the right way to implement this
> functionality in OpenID, and I believe that the authors of the PAPE spec
> intended RPs to be able to specify openid.pape.max_auth_age=0 in the request
> to ask the OP to authenticate the user without relying on browser cookies.
> In the case where the user is already authenticated at the OP (using
> cookies), the expectation is that the OP re-authenticates the user before
> returning a positive assertion to the RP. In the most common case, where the
> user authenticates with a password, the OP is expected to verify the user's
> password before returning the assertion to the RP.
>
> Although this sounds fairly straightforward, there are some non-obvious
> edge cases that should probably be clarified.
>
> For instance, what if the RP specified max_auth_age=<1 minute>? Sometimes
> users take a few minutes to complete the OpenID sign in flow (they might get
> distracted), and although the user may have entered their password
> immediately after being redirected to the OP, the user may have taken more
> than a minute to navigate through the OP's approval screen, before clicking
> on the button to return back to the RP.
>
> Another case is where the RP specified max_auth_age=999999999999. The PAPE
> spec requires the OP to respond back with the the time the user last
> authenticated, if the max_auth_age is greater than the duration of the
> user's current session with the OP. This effectively gives the RP a way to
> find out when the user last signed in, which potentially violates the user's
> privacy.  Many users expect to be able to sign into their OP silently, and
> to be able to use services at their OP without anyone besides their OP
> knowing that they were online.  Obviously, using OpenID to signin to an RP
> exposes to the RP that the user is online at the moment of authentication,
> however it's probably a very bad idea for the OP to return when the user
> signed into the OP if the sign-in event was more than (X hours?) in the
> past.
>
> In order to provide a standard "force authentication" interface, I propose
> that either we define a new PAPE policy, or we clearly define max_auth_age=0
> as a special value.
>
> The "force authentication" policy must require OPs to re-authenticate the
> user after the user is redirected to the OP and before returning the
> assertion to the RP. In the case where the user is authenticated with a
> password, the OP is required to re-verify the user's password. If the OP
> displays additional screens to the user after verifying the user's password,
> the OP must ensure that the user's IP address did not change after the
> password was verified and the assertion returned.  OPs should be able to
> support this policy without also supporting other non-zero values for
> max_auth_age.
>
> comments?
> Allen
>
>
>
>
>
>
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20090701/8a23c7ad/attachment.htm>