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

[Dick Hardt]

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

> Hi Dick,
>
> Welcome back!

shhh

> My comments inline:
>
> Dick Hardt wrote:
>>
>> On 30-Jun-09, at 9:23 PM, Allen Tom wrote:
>>
>>>
>>> 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.
>>
>> 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.
> Well, if the RP is deliberately violating the user's privacy to find  
> out when the user authenticated at the OP, it could send multiple  
> checkid_immediate requests, decrementing the max_auth_age value each  
> time, until it found the real value.

Errr, the RP gets back what it sent each time. I am suggesting  
changing the spec for the privacy reasons you stated. The RP does not  
need to know when the last auth was, just that it met the RP's policy.

It never learns anything except for seeing how long it is before the  
OP returns a result.

Am I missing something?

>
>
>>
>> What are you looking for in this use case where the IP address  
>> changes?
>
> Sites that force the password to be re-verified before entering a  
> sensitive flow often require that the user's IP address remain fixed  
> throughout the flow, or else they'll require the user to re- 
> authenticate.

why?

>
> If the OP authenticates the user and generates the assertion in two  
> separate screens (as appears to be the most common case), there is  
> an edge case where the user's IP address could have changed after  
> the user authenticated. For instance, the user is on wifi, and  
> enters their password while on one wifi network, and then and then  
> roams to a new wifi network while on the OP's approval screen.  If  
> the RP was not using OpenID, and instead authenticated the using a  
> local password, this IP address change would invalidate the user's  
> session. It would be nice to keep this functionality in OpenID.


The user's machine could get a new, dynamic IP address between HTTP  
requests. I don't see that as a security violation. I really don't  
understand the security issue here. Please enlighten me!

-- Dick