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

Dick Hardt dick.hardt at gmail.com
Wed Jul 1 16:49:51 UTC 2009


On 30-Jun-09, at 11:08 PM, Dirk Balfanz wrote:
> 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.

Actually it was me that used the Amazon example. :-)

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

I'm not sure why you think you are taking an opposite view.

The RP says the max_auth_age that it wants for the user, and the OP  
sends back the same value *if* the OP has conformed with the policy,

max_auth_age of zero is an interesting case since nothing is instant.

My comment around Amazon was to look at what best practices are out  
there. Amazon wants a "fresh" authentication. We should look to see  
how "fresh" is implemented in the wild rather then making up our own  
view of "fresh".

-- Dick



More information about the security mailing list