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

[Dick Hardt]

On 30-Jun-09, at 10:32 PM, Allen Tom wrote:

> Hi Nate -
>
> Consider the scenario where the RP specified max_auth_age=1minute in  
> the request, and after being redirected to the OP, the user enters  
> their password, then sees the OP's approval screen and decides to  
> take a 10 minute break before clicking the "continue" button.
>
> Should the OP should re-prompt the user for the password again  
> before returning the assertion to the RP because the RP requested  
> that the password be verified within 1 minute of returning the  
> assertion?

So if the user has authenticated 55 seconds ago, but take 6 seconds to  
click the continue button, then the user will be presented with a  
login screen after clicking the continue button which tells them they  
will be sent to the RP. Jarring user experience. I would suggest we  
think this through.

How common are continue buttons in OPs now?  I would expect that if I  
have an active session with my OP that meets the RP's policy, that I  
won't even see an OP screen.

>
> I believe that you said that the OP should re-verify the user's  
> password in this case, which makes plenty of sense.

One of the intents of this policy it to enable a flow like you have at  
Amazon when purchasing. You can add things to the shopping cart based  
on an old authentication, but when you go to purchase, you have to  
have a fresh authentication.

Given that we want to provide a similar flow, but the authentication  
is now done by the OP, what does Amazon do if the user pauses right  
after re-authenticating, but before completing the purchase?

>
> Now getting back to the original case, where the RP used the magic  
> max_auth_age=0 value. Unless there is zero network latency, and the  
> OP does not have a separate approval screen, it is impossible for  
> the OP to satisfy this requirement.
>
> That's why I was suggesting that we just define max_auth_age=0 as a  
> special case, and clearly define what is expected for this case.

What would you suggest?

>
> Thanks
> Allen
>
>
>
>
>
> Nate Klingenstein wrote:
>>
>>> 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.
>>
>> Isn't it the OP that is obliged to perform the check?  It would be  
>> performed immediately when the user presents the message, I'd  
>> imagine, since it's determining how to handle the request.
>>
>
>
>
>
>
>
>> It wouldn't matter if they dally at the OP if the RP weren't likely  
>> to complain about the auth_time on the user's arrival, which is a  
>> separate matter(and not mandated by spec from what I can tell).   
>> But some check probably needs to be explicitly performed by the RP  
>> on the return leg until authentication requests can be signed.  Sigh.
>>
>> Either way, the RP would only be sabotaging its own user base here,  
>> so this falls more into the category of recommendations or best  
>> practices, in my opinion.
>>
>> The SHOULD there reads strangely to, though.
>>
>>> 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.
>>
>> Having seen other working group applications and spec revisions  
>> move a little gradually, I feel compelled to first ask: how painful  
>> are these options?
>>
>>> comments?
>>
>> Yes.  Signed authentication requests would be nice and limit the  
>> "trust, but verify" the RP needs to do -- that is to say, limit the  
>> amount of private data the OP needs to expose.
>>
>> Take care,
>> Nate.
>
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security