I agree with Daniel.
Also, while we've talked about server requirements, I think it's equally
important that we retain this client requirement:
The client MUST NOT use the authorization code more than once.
-- Mike
From: OAuth <[email protected]> On Behalf Of Daniel Fett
Sent: Friday, October 15, 2021 8:13 AM
To: [email protected]
Subject: Re: [OAUTH-WG] Re: Authorization code reuse and OAuth 2.1
I don't think that a MAY is appropriate here.
I wasn't in the call yesterday, so I hope I don't miss anything here, but...
Even with PKCE, the one-time use requirement of the code is still important.
First and foremost, if we allow unlimited re-use of the same code, even just as
an option, we change the semantics of this artifact. I guess there are many
examples where this causes issues, but one would be DPoP. It assumes that there
is only one (successful) token request and in that request, the token is bound
to a specific key. If there can be more than one successful token request, all
it takes is code_challenge and the code sitting around somewhere in accessible
memory and an XSS attacker can exfiltrate them and use them on his own device,
binding the resulting token to an attacker-controlled key. This is the attack
outcome against which we introduced the nonce in DPoP. (Probably we should add
this thought as a security consideration to DPoP, but that is a different
topic.) I guess we can come up with many other mechanisms and mitigations that
depend on code being one-time use.
The attack described also shows nicely that code replay protection and PKCE
serve similar purposes, but are not the same thing.
The Security BCP introduces a second layer of defense at pretty much all the
critical places in the protocol, because practice shows that a single defense
can break too easily. For example, an attacker with read-only access to the
token request would be pretty bad without code replay protections in place.
Such attackers are considered in FAPI. (Somebody capable of reading system logs
at the client or server, proxy logs at the client or server, browser logs, etc.)
Therefore, in my opinion, the code MUST be short-lived and at least SHOULD,
better MUST be one-time use.
And ideally, the code SHOULD also be invalidated if the PKCE verifier does not
match, not sure if that is in the current text or not.
-Daniel
Am 15.10.21 um 11:04 schrieb Pieter Kasselman:
SHOULD is more likely to cause the right conversations to take place for
implementors as they weigh the risks. Reducing it to MAY risks diluting it too
much.
From: OAuth <[email protected]><mailto:[email protected]> On Behalf
Of Warren Parad
Sent: Friday 15 October 2021 09:25
To: Pieter Kasselman
<[email protected]><mailto:[email protected]>
Cc: IETF oauth WG <[email protected]><mailto:[email protected]>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1
I wouldn't be against lowering it to MAY but only if we stipulate a SHOULD on
an expected lifetime of an authorization code. I think sending the message that
these should be one time use except in exceptional circumstances.
[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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154740432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6rSI2UvnakrWNh3qtBEgIMbRO8L9oXu8zGj4Fd128B8%3D&reserved=0>.
On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman
<[email protected]<mailto:[email protected]>>
wrote:
Any weakening of the requirement should include a clear outline of the risks to
help implementors make informed decisions.
From: OAuth <[email protected]<mailto:[email protected]>> On Behalf
Of Ash Narayanan
Sent: Friday 15 October 2021 01:51
To: Aaron Parecki <[email protected]<mailto:[email protected]>>
Cc: IETF oauth WG <[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1
You don't often get email from
[email protected]<mailto:[email protected]>. Learn why this is
important<http://aka.ms/LearnAboutSenderIdentification>
Yes, as I said before, authorization servers are free to enforce one-time use
of the authorization code even if there isn't a requirement to. The proposal is
just to remove the *requirement* of authorization servers enforcing it.
I agree, and therefore I think what it really ought to be is "MAY".
Annabelle said:
There are legitimate use cases for a client to replay an authorization code.
Connection failures happen. Servers fall over before completing requests. Users
hit browser refresh buttons. Permitting replay of authorization codes (assuming
valid PKCE, client creds, etc.) allows clients to handle these failure modes
simply and gracefully via retries.
Couldn't agree more. Having experienced these exact use-cases, I can honestly
say that denying users a smooth experience just to be compliant with the spec,
which offers no additional security if PKCE is also being used, makes no sense.
It is also more effort (from a repository layer perspective) to implement
one-time use than do PKCE verification.
What is the practical reason for allowing "plain" PKCE in OAuth 2.1? Are there
really use cases out there where SHA-256 is a deal breaker?
I'd be interested in these use-cases as well (I can't think of any).
On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki
<[email protected]<mailto:[email protected]>> wrote:
Yes, as I said before, authorization servers are free to enforce one-time use
of the authorization code even if there isn't a requirement to. The proposal is
just to remove the *requirement* of authorization servers enforcing it.
I am okay with Mike's suggestion of changing the language to "SHOULD" to
continue to point out the possibility of enforcing one-time authorization codes
if desired.
On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman
<[email protected]<mailto:[email protected]>> wrote:
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 <[email protected]<mailto:[email protected]>> On Behalf
Of Sascha Preibisch
Sent: Wednesday 13 October 2021 22:06
To: Aaron Parecki <[email protected]<mailto:[email protected]>>
Cc: IETF oauth WG <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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?
[Image removed by
sender.]
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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154750385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y86Gy8RiRIbIAW3So8hr4PxYsta1VWX1X7l%2FHzVbcvI%3D&reserved=0>.
On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> On Behalf
Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad
<[email protected]<mailto:[email protected]>>
Cc: Mike Jones
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>> 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"?
[Image removed by
sender.]
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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lbb9cJl0VUcfBD9IwzKF4BeB5nnggZxLB1TwlZYdNK4%3D&reserved=0>.
On Wed, Oct 13, 2021 at 7:17 PM Mike Jones
<[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u3yNDEeIsFvqGwu3x8%2F22D25o3bVO9PkrBEA2IEKSzY%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
--
https://danielfett.de
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
