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

[John Bradley]

Allen,

There is nothing in the PAPE spec about the OP verifying that auth_age  
< max_auth_age before  returning the assertion.

That could lead to a deadlock situation.

You and others may see a value in that but that is not the intent of  
the PAPE spec.

If the time since the last interactive login when the OP receives the  
request is > max_auth_time then the OP must immediately re-prompt for  
authentication (not using a long lived cookie to authenticate the user.)

Perhaps it would have been clearer if we had stated that the OP must  
immediately reauth  the user but we never imagined that the OP would  
take the user through some other flow.

Part of the reason for this feature was Yahoo who drove a number of  
additions to the PAPE spec , such as NIST level 0 to say the user was  
authenticated with a long-lived cookie.

Given that Yahoo users may have authenticated up to 14 days  
previously,  that drove the need for max_auth_age to give a RP some  
control over how old an interactive authentication they were willing  
to accept.

The spec is worded that if max_auth_age is more than > than the  
auth_age the OP can still elect to re-authenticate the user.   If the  
OP sets there own max_auth_age upper limit of a couple of hours I  
think this covers the privacy concerns.

auth_age MUST be returned if max_auth_age is requested.
It is the time in seconds between the last interactive authentication  
and the manufacture of the return assertion.

It is up to the RP to decide what to do based on this.

We don't wan't to take flexibility away from the RP if the auth_age in  
the return is 2h then the RP has to decide if they get sent back to  
the OP again.

PAPE is about giving some control over the login back to the RP.  In  
the normal openID flow the OP has complete control over the  
authentication.

I am not sure why people think max_auth_age=0 is special it is just  
0.  Unless you are trying to read in the fancy auth_age < max_auth_age  
behavior that was never intended.

There may be a better way to achieve the desired behavior with authn  
URI to say things like the user must do a password reset (I think  
Facebook was looking for that)  or other things.

Some RP's are concerned about silent logins after the user has  
"Remembered" the RP in there OP config.

This potentially allows for cross site request forgeries against the RP.

I could also see a lighter flow where the RP requests that the user  
must consent to logging in but doesn't need to re-authenticate.

Those could be defined as auth methods potentially.

I am concerned that id OPs start creatively interpreting the PAPE spec  
it will loose a lot of its value.

We have some of that creative interpretation problem now with AX.

I am glad people are starting to show an interest in implementing and  
using PAPE.

John B.
On 1-Jul-09, at 1:32 AM, Allen Tom wrote:

> Hi Nate -
>
> Consider the scenario where the RP specified max_auth_age=1minute in  
> the request, and after being redirected to the OP, the user enters  
> their password, then sees the OP's approval screen and decides to  
> take a 10 minute break before clicking the "continue" button.
>
> Should the OP should re-prompt the user for the password again  
> before returning the assertion to the RP because the RP requested  
> that the password be verified within 1 minute of returning the  
> assertion?
>
> I believe that you said that the OP should re-verify the user's  
> password in this case, which makes plenty of sense.
>
> Now getting back to the original case, where the RP used the magic  
> max_auth_age=0 value. Unless there is zero network latency, and the  
> OP does not have a separate approval screen, it is impossible for  
> the OP to satisfy this requirement.
>
> That's why I was suggesting that we just define max_auth_age=0 as a  
> special case, and clearly define what is expected for this case.
>
> 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.
>
> _______________________________________________
> specs-pape mailing list
> specs-pape at openid.net
> http://openid.net/mailman/listinfo/specs-pape