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

[John Bradley]

George,

I think it is clear from the spec that if max_auth_age=0  the OP must  
perform a interactive login.

I think what Eric is suggesting is that a OP may choose to treat all  
values of max_auth_age as 0.
Nothing in the PAPE spec precludes an OP from doing that.

I don't think that precludes other OPs from treating non 0 values of  
max_auth_age differently.
Some may choose to limit max_auth_age to 1 day or some other value.

So it would be more like if(if(max_auth_age < auth_age) or if(auth_age  
 > local_max_auth_age) ) then re-verify credentials.

It is up to the OP to decide what local_max_auth_age should be.  It  
might depend on other PAPE parameters.  eg if the RP is asking for  
multi-factor then you may decide they care more about security and  
make local_max_auth_age = 2h but otherwise be 12h or something like  
that.

The PAPE spec leaves that up to the OP.

John B.
On 7-Jul-09, at 4:23 PM, George Fletcher wrote:

> To be sure I understand...  Are you suggesting, Allen, that we don't  
> define a PAPE URI for "re-auth" and just use max_auth_age=0 as the  
> indicator for this behavior? I think I'd prefer to not define  
> special semantics for max_auth_age=0 and rather have a PAPE URI for  
> "re-auth". Of course if the RP sent a max_auth_age=0 it would almost  
> certainly result in the same behavior, I think it's cleaner to just  
> treat max_auth_age the same regarding it's value:
>    if ( (curr_time - auth_time) > max_auth_age) then re-verify  
> credentials
>
> Thanks,
> George
>
> Allen Tom wrote:
>> Eric Sachs wrote:
>>>
>>> The short version of my suggestion is that IDPs should be "lazy."   
>>> For any value of max_auth_age (including 0), the "lazy" can ALWAYS  
>>> perform a re-authentication before sending the user to the RP.   
>>> The IDP could also send along the "last authentication time" as  
>>> well, but it isn't particularly interesting in this case.
>>>
>> This is a good compromise that satisfies the use case that RPs seem  
>> to be asking for - which is to be able to force the OP to re- 
>> authenticate the user (verify the user's password) before returning  
>> a positive assertion, while making it possible to optimize the user  
>> experience later, if this becomes an issue.
>>
>> As a best practice, we should recommend that we use max_auth_age=0  
>> as the flag for this behavior to eliminate any ambiguity for  
>> implementers.
>>
>> Speaking on behalf of the Yahoo OP, we will implement the "lazy"  
>> behavior, with the recommendation that RPs that want to force a  
>> password reprompt send max_auth_age=0 in the authentication request  
>> to indicate this. Our experience within Yahoo is that applications  
>> that actually care about the user's last authentication time almost  
>> always elect to force a password re-verification, rather than try  
>> to determine if the last authentication time is acceptable.  
>> Although this is can sometimes result in a sub-optimal user  
>> experience, in which the user is forced to enter their password  
>> multiple times within a short interval, in practice, applications  
>> that actually care about this prefer to take the conservative (and  
>> easier) approach of just unconditionally forcing the password to be  
>> re-verified.
>>
>>> In the future we will hopefully find some aggressive early- 
>>> adopters who have a strong need for the more advanced max_auth_age  
>>> flow, and they can help define the best practices.  But in the  
>>> meantime, I'd suggest that IDPs start with the "lazy" version and  
>>> see how far it gets us.
>>>
>> Works for me!
>> Allen
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> security mailing list
>> security at openid.net
>> http://openid.net/mailman/listinfo/security
>>
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security