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

[Allen Tom]

Dick Hardt wrote:
>
> 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.
>
Yes, my point exactly.



> 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 would expect that most OPs would show a continue button, at least the 
very first time the user visits a new  RP, especially is AX is involved.


>
> What would you suggest?
>

The RP should have a flag that they can pass in the request to tell the 
OP to re-authenticate the user before returning a positive assertion to 
the RP, which I think was the intent of max_auth_age=0.

As I mentioned previously, values like max_auth_age=0 or even 
max_auth_age=60 are messy to implement because users may take more than 
max_auth_age seconds to click the continue button after authenticating.

At least from an implementation standpoint, I can imagine that RPs would 
want a "Force Authentication" interface, and it's unclear what the right 
value for max_auth_age would be to satisfy this use case. 60? 120? 300? 0?

I suggest that either we say that this special flag actually is 
max_auth_age=0, or we define a new PAPE policy for this case.

The requirements for the OP are:

- Authenticate the user without relying previously issued authentication 
credentials.
- OPs which use passwords to authenticate the user should re-prompt for 
the password (it's OK to pre-fill the userid in the Login form)
- Ideally, the user's IP address should not change between the time the 
user authenticated and when the assertion is generated. (this is less 
important, but nice to have)

Allen












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