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

[Dirk Balfanz]

On Tue, Jun 30, 2009 at 10:33 PM, Dick Hardt <dick.hardt at gmail.com> wrote:

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

Allow me to take the exact opposite view.

I think forcing reauthentication is a useless feature. Rather, what RPs
_should_ be interested in is the freshness of the user's session. Let's look
at the Amazon example that Allen points out. The reason Amazon asks for your
password again before you purchase is because they want to make sure that
it's really still you sitting in front of that browser, and not your room
mate.

Thought experiment: Let's assume that Amazon was an OpenID RP, and wanted to
make sure that it's really you sitting in front of that browser before a
purchase. They send you off to the OP with max_auth_age=0, or this new
proposed PAPE policy. After a day, the user returns to Amazon. (We don't
know what caused this delay.) What is Amazon supposed to do now? Presumably,
this is unacceptable, because at this point they can't really be sure that
the room mate hasn't taken over the session. So Amazon needs to decide what
value X should have so that they believe the following statement: "If the
login session of the user is not older than X seconds, it is exceedingly
likely that the user is still in control of that login session". They need
to know what their own threshold for X is because they will need to refuse
responses from the OP in which it's clear that the user's login session is
older than X seconds (they might know this because the OP tells them, or
because they sent the user off to the OP with a force_reauth request and
kept time).

Let's say Amazon decides that X=30 seconds. If Amazon really believes the
statement above with X=30 seconds, then there is no need for them to ask for
reauthentication in every case. They should only ask for reauthentication if
the session is older than 30 seconds. In other words, the only sensible
thing for Amazon to send to the OP is max_auth_age=30, not max_auth_age=0,
or some new special PAPE policy.

Now, what should the OP return? The OP abides by Amazon's wishes and
re-authenticates the user if the user's session is older than 30 seconds.
But then the user gets distracted or whatnot, so when the user actually
returns to Amazon, the login session at this point is 2 minutes old. Amazon
needs to know this because their policy is to only allow sessions that are
no more than 30 seconds old. So the OP actually needs to tell the RP the age
of the user's login session.

To summarize, knowing that the OP met the RP's policy (reauthenticated the
user) _doesn't_ buy the RP anything (the user session could still be too old
by the time the user returns to the OP). On the other hand, knowing the
auth_time _does_ buy the RP something (the RP can make an educated decision
on whether to allow the user to go ahead with, say, the Amazon purchase). So
it's just the opposite of what Dick was saying :-)

Dirk.



> 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
>
>
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20090630/e4e64523/attachment.htm>