I am a fan of this approach. It feels pretty empty to cast people out of compliance just because they are handling a realistic circumstance, such as network failures, that we know about beforehand. In addition, this gives us a chance to provide guidance on how to handle the situation, instead of leaving AS implementers to their own device.
On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle <richanna= 40amazon....@dmarc.ietf.org> wrote: > The client MUST NOT use the authorization code more than once. > > > This language makes it impossible to build a fault tolerant, spec > compliant client, as it prohibits retries. We could discuss whether a retry > really constitutes a separate "use", but ultimately it doesn't matter; > multiple presentations of the same code look the same to the AS, whether > they are the result of retries, the client attempting to get multiple sets > of tokens, or an unauthorized party trying to replay the code. > > I think we can have a fault tolerant, replay-proof implementation, but it > takes some effort: > > > 1. The AS can prevent the authorized client from using one code to get > a bunch of independent refresh and access token pairs by either re-issuing > the same token (effectively making the token request idempotent) or > invalidating previously issued tokens for that code. (Almost but not quite > idempotent…idempotent-adjacent?) > > 2. The AS can prevent unauthorized parties from replaying snooped > codes+PKCE by requiring stronger client authentication: implement dynamic > client registration and require a replay-resistant client authentication > method like `jwt-bearer`. The AS can enforce one-time use of the client > credential token without breaking fault tolerance, as the client can easily > mint a new one for each retry to the token endpoint. > > > Yes, I know, this is way more complex than just a credential-less public > client doing PKCE. Perhaps we can have our cake and eat it too with > language like: > > The client MUST NOT use the authorization code more than once, unless > retrying a token request that failed for reasons beyond the scope of this > protocol. (e.g., network interruption, server outage) Refer to [Fault > Tolerant Replay Prevention] for guidance. > > > …where Fault Tolerant Replay Prevention is a subsection under Security > Considerations. I don't think this wording is quite right, as the guidance > is really going to be for the AS, not the client, but hopefully it's enough > to get the idea across. > > — > Annabelle Backman (she/her) > richa...@amazon.com > > > > > On Oct 15, 2021, at 8:27 AM, Mike Jones < > Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: > > *CAUTION*: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > 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 <oauth-boun...@ietf.org> *On Behalf Of *Daniel Fett > *Sent:* Friday, October 15, 2021 8:13 AM > *To:* oauth@ietf.org > *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 <oauth-boun...@ietf.org> <oauth-boun...@ietf.org> *On > Behalf Of *Warren Parad > *Sent:* Friday 15 October 2021 09:25 > *To:* Pieter Kasselman <pieter.kasselman=40microsoft....@dmarc.ietf.org> > <pieter.kasselman=40microsoft....@dmarc.ietf.org> > *Cc:* IETF oauth WG <oauth@ietf.org> <oauth@ietf.org> > *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. > > *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 <pieter.kasselman= > 40microsoft....@dmarc.ietf.org> wrote: > > Any weakening of the requirement should include a clear outline of the > risks to help implementors make informed decisions. > > *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of *Ash Narayanan > *Sent:* Friday 15 October 2021 01:51 > *To:* Aaron Parecki <aa...@parecki.com> > *Cc:* IETF oauth WG <oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and > OAuth 2.1 > > You don't often get email from ashvinnaraya...@gmail.com. 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 <aa...@parecki.com> 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 < > pieter.kassel...@microsoft.com> 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 <oauth-boun...@ietf.org> *On Behalf Of *Sascha Preibisch > *Sent:* Wednesday 13 October 2021 22:06 > *To:* Aaron Parecki <aa...@parecki.com> > *Cc:* IETF oauth WG <oauth@ietf.org> > *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 <aa...@parecki.com> 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 < > saschapreibi...@gmail.com> 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 <aa...@parecki.com> 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 <wpa...@rhosys.ch> 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? > > <image001.jpg> > *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 <aa...@parecki.com> 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 < > pieter.kassel...@microsoft.com> 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 <oauth-boun...@ietf.org> *On Behalf Of *Aaron Parecki > *Sent:* Wednesday 13 October 2021 18:40 > *To:* Warren Parad <wparad=40rhosys...@dmarc.ietf.org> > *Cc:* Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org>; > oauth@ietf.org > *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= > 40rhosys...@dmarc.ietf.org> 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"? > > <image001.jpg> > *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 <Michael.Jones= > 40microsoft....@dmarc.ietf.org> 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 > OAuth@ietf.org > 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 > OAuth@ietf.org > 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 > OAuth@ietf.org > 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 > OAuth@ietf.org > 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 > OAuth@ietf.org > 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > https://danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
