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

[Dick Hardt]

On 30-Jun-09, at 9:23 PM, Allen Tom 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.

Rather then return the time the user last authenticated, the OP return  
the max_auth_age value the RP sent. This lets the RP know the OP  
honored the RP's max)_auth_age request.
As for the max_auth_age=1 case, if the OP has seen the user in 1  
minute or less when they see the user returning, then the OP does not  
need to re-authenticate the user, even if it takes a few minutes for  
the OP and user to complete returning the result back to the RP.

>
> 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.

What are you looking for in this use case where the IP address changes?

-- Dick