Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Pieter Kasselman <[e-mail]>]

Log files can exist in lots of place (clients, servers, data lakes). The question is whether it is a valid assumption that an attacker cannot obtain an Authorization Code and a Code Verifier and present it a second time round. Limiting the validity period is one layer of defence, PKCE is another layer, one time use enforcement is another. Assuming breach and designing from a defence in depth perspective is a good practice, so why not give implementors options (and guidance) to add additional layers of defence to match their risk profiles?


From: OAuth <[e-mail]> On Behalf Of Sascha Preibisch
Sent: Wednesday 13 October 2021 22:06
To: Aaron Parecki <[e-mail]>
Cc: IETF oauth WG <[e-mail]>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Ok, if the goal is to avoid unnecessary requirements I am suggesting to point out why MUST was changed to SHOULD. Otherwise developers will start to mix and match OAuth 2.0 and OAuth 2.1 requirements as they see them fit their needs.
In regards to encrypted values in PKCE, Aaron, I can also not confirm that as the general implementation.

On Wed, 13 Oct 2021 at 13:56, Aaron Parecki <[e-mail]<mailto:[e-mail]>> wrote:
The PKCE spec actually says "Typically, the "code_challenge" and "code_challenge_method" values are stored in encrypted form in the "code" itself" which I feel like might be a stretch to say that's typical, but this scenario was clearly thought of ahead of time. Doing that would enable an AS to avoid storing server-side state.

On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <[e-mail]<mailto:[e-mail]>> wrote:
If the challenge is based on distributed authorization server configurations, how would they handle PKCE? I imagine that managing the state for PKCE is not less challenging than managing authorization codes on the server side, preventing reuse of them.
With that in mind I am not sure if I follow the given argument. I would prefer to keep MUST as it is today.


On Wed, 13 Oct 2021 at 13:37, Aaron Parecki <[e-mail]<mailto:[e-mail]>> wrote:
HTTPS, because if that's broken then the rest of OAuth falls apart too.

On Wed, Oct 13, 2021 at 1:36 PM Warren Parad <[e-mail]<mailto:[e-mail]>> wrote:
I feel like I'm missing something, what stops just plain old network sniffing and replying the whole encrypted payload to the AS and getting back a valid token?


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293904430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vwcfj%2FVB8a84yDoAmqkXraWyqjOfWGrV08XdtZLWMXw%3D&reserved=0>.


On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki <[e-mail]<mailto:[e-mail]>> wrote:
Aside from the "plain" method, the PKCE code verifier never leaves the client until it's sent along with the authorization code in the POST request to the token endpoint. The only place it can leak at that point is if the authorization server itself leaks it. If you have things leaking from the authorization server log, you likely have much bigger problems than authorization code replays.

Keep in mind that even with the proposed change to drop the requirement of authorization codes being one time use, authorization servers are free to enforce this still if they want. Authorization code lifetimes are still expected to be short lived as well.

Aaron


On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <[e-mail]<mailto:[e-mail]>> wrote:
Aaron, I was curious what prevents an attacker from presenting an Authorization Code and a PKCE Code Verifier for a second time if the one time use requirement is removed. Is there another countermeasure in  PKCE that would prevent it? For example, an attacker may obtain the Authorization Code and the Code Verifier from a log and replay it.

Cheers

Pieter

From: OAuth <[e-mail]<mailto:[e-mail]>> On Behalf Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad <wparad=[e-mail]<mailto:[e-mail]>>
Cc: Mike Jones <Michael.Jones=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Warren, I didn't see you on the interim call, so you might be missing some context.

The issue that was discussed is that using PKCE already provides all the security benefit that is gained by enforcing single-use authorization codes. Therefore, requiring that they are single-use isn't necessary as it doesn't provide any additional benefit.

If anyone can think of a possible attack by allowing authorization codes to be reused *even with a valid PKCE code verifier* then that would warrant keeping this requirement.

---
Aaron Parecki


On Wed, Oct 13, 2021 at 10:27 AM Warren Parad <wparad=[e-mail]<mailto:[e-mail]>> wrote:
Isn't it better for it to be worded as we want it to be, with the implication being that of course it might be difficult to do that, but that AS devs will think long and hard about sometimes not denying the request? Even with MUST, some AS will still allow reuse of auth codes. Isn't that better than flat out saying: sure, there's a valid reason

In other words, how do we think about RFCs? Do they exist to be followed to the letter or not at all? Or do they exist to stipulate this is the way, but acknowledge that not everyone will build a solution that holds them as law.

Let's look at SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

I think recommended here is not sufficient nor are there valid reasons. "It's too hard" isn't really a valid reason. Isn't it better in this case for an AS to not be compliant with the RFC, than it is to relax this to SHOULD and have lots of AS thinking reusing auth codes is a viable solution, "because they are a special snowflake where SHOULD should apply".

Are we setting the standard or instead attempting to sustain a number of "AS that are in compliance with the RFC"?


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9LtSUyb7WjZQqY%2FBnFy47HxchMNGZG6Qx82hj%2Bd9X04%3D&reserved=0>.


On Wed, Oct 13, 2021 at 7:17 PM Mike Jones <Michael.Jones=[e-mail]<mailto:[e-mail]>> wrote:
During today's call, it was asked whether we should drop the OAuth 2.0 language that:
         The client MUST NOT use the authorization code
         more than once.  If an authorization code is used more than
         once, the authorization server MUST deny the request and SHOULD
         revoke (when possible) all tokens previously issued based on
         that authorization code."

The rationale given was that enforcing one-time use is impractical in distributed authorization server deployments.

Thinking about this some more, at most, we should relax this to:
         The client MUST NOT use the authorization code
         more than once.  If an authorization code is used more than
         once, the authorization server SHOULD deny the request and SHOULD
         revoke (when possible) all tokens previously issued based on
         that authorization code."

In short, it should remain illegal for the client to try to reuse the authorization code.  We can relax the MUST to SHOULD in the server requirements in recognition of the difficulty of enforcing the MUST.

Code reuse is part of some attack scenarios.  We must not sanction it.

                                                          -- Mike

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293914390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gWX04yAEt3IP7lWFDS0zBzyJN8nvNfEf6Eq7i6qU7fM%3D&reserved=0>
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%3D&reserved=0>
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293924344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yk%2FjfwfllrczSKVwzH4Bt7GTr9TV8fSda2oZhV0ejyA%3D&reserved=0>