Are we saying that network connections have got significantly worse over the last decade that we need to drop a security feature? I have so far never heard anyone complain about the one-time use nature of authorization codes. (I hear it about refresh tokens, but not auth codes). I don’t think that OAuth 2.1 is an appropriate place to be relaxing any security conditions.
— Neil > On 16 Oct 2021, at 03:01, Vittorio Bertocci > <[email protected]> wrote: > > > I see the formal reasoning behind the suggestion, and I agree it would be the > safest behavior, but I don’t think it’s a realistic expectation. The end user > experience necessary for obtaining a new authorization code (with possible > future complications if browsers start to see excess redirects toward a > domain as evidence of tracking and strip parameters out) and the complexity > of moving execution back from code to front channel as error management IMO > makes it very unlikely that developers would pursue that approach (which I > have never seen implemented in the wild). > >> On Fri, Oct 15, 2021 at 16:42 Mike Jones >> <[email protected]> wrote: >> As I see it, the retry in case of network failures should happen by >> performing a new authorization request – not by trying to reuse an >> authorization code – which is indistinguishable from an attack. >> >> >> >> Let’s not use OAuth 2.1 as an opportunity to sanction behaviors that we >> can’t distinguish from attacks. >> >> >> >> The prohibition on clients reusing an authorization code needs to remain. >> >> >> >> -- Mike >> >> >> >> From: Vittorio Bertocci <[email protected]> >> Sent: Friday, October 15, 2021 4:19 PM >> To: Richard Backman, Annabelle <[email protected]> >> Cc: Mike Jones <[email protected]>; [email protected] >> Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1 >> >> >> >> 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 >> <[email protected]> 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: >> >> >> >> 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?) >> 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) >> >> [email protected] >> >> >> >> >> >> >> >> >> On Oct 15, 2021, at 8:27 AM, Mike Jones >> <[email protected]> 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 <[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]> On Behalf Of Warren Parad >> Sent: Friday 15 October 2021 09:25 >> To: Pieter Kasselman <[email protected]> >> Cc: IETF oauth WG <[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. >> >> >> >> >> >> Warren Parad >> >> Founder, CTO >> >> Secure your user data with IAM authorization as a service. Implement >> Authress. >> >> >> >> >> >> On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman >> <[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]> On Behalf Of Ash Narayanan >> Sent: Friday 15 October 2021 01:51 >> To: Aaron Parecki <[email protected]> >> Cc: IETF oauth WG <[email protected]> >> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1 >> >> >> >> You don't often get email from [email protected]. Learn why this is >> important >> >> 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]> 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]> 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]> On Behalf Of Sascha Preibisch >> Sent: Wednesday 13 October 2021 22:06 >> To: Aaron Parecki <[email protected]> >> Cc: IETF oauth WG <[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]> 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]> >> 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]> 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]> 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. >> >> >> >> >> >> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki <[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]> 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]> On Behalf Of Aaron Parecki >> Sent: Wednesday 13 October 2021 18:40 >> To: Warren Parad <[email protected]> >> Cc: Mike Jones <[email protected]>; [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]> 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. >> >> >> >> >> >> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones >> <[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] >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> -- >> https://danielfett.de >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
