So if I'm understanding this correctly, it sounds like the AS needs to reject a token request with code_verifier if the authorization code was issued in response to a request that did not contain a code_challenge. This to me sounds like it would be simpler to just say the code_challenge and code_verifier are always required.
That said, I do understand the previously discussed concerns around existing OpenID Connect clients. I believe the text that Daniel proposed is the best of both worlds, and I support making this change in both OAuth 2.1 and the Security BCP. Aaron Parecki On Tue, May 19, 2020 at 9:29 AM Nov Matake <mat...@gmail.com> wrote: > Yes. > > The root problem isn’t the mix-use of PKCE and nonce, it’s PKCE > implementation bug. > Yeah, all PKCE implementation MUST reject such requests, regardless it’s > OAuth 2.1 or 2.0. > > (and it’s probably because of PKCE spec’s ambiguity..) > > 2020/05/20 1:13、Mike Jones <michael.jo...@microsoft.com>のメール: > > So it sounds me like the fix is to have servers reject PKCE requests with > incomplete parameter sets: requests that only contains one of > code_challenge and code_verified. Will that eliminate the attack, Nov? > > -- Mike > > *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of *Nov Matake > *Sent:* Monday, May 18, 2020 11:50 PM > *To:* Daniel Fett <f...@danielfett.de> > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1 > > Sure, feel free to add the senario to your post. > > FYI: > my OAuth2 server ruby gem rejects such token requests, > > https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/extension/pkce.rb#L28 > and Google also does the same. > https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046 > > So I'm guessing such behavior is relatively rare-case, hopefully. > > iPadから送信 > > > 2020/05/19 15:43、Daniel Fett <f...@danielfett.de>のメール: > > > Hi, > > Am 19.05.20 um 04:55 schrieb Nov Matake: > > I thought the server MUST reject such token requests, but I couldn’t find > such definition in RFC7636... > > > The client will send the code, along with a (now not matching) > code_verifier to the server. The server will ignore the code_verifier (as > it was not expected) and send back an access token and ID token to the > client. > > https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkce-sidestep-attack > > If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack” > would be possible. > > I *think* that there is nothing preventing servers from sometimes using > PKCE and sometimes using Nonce. I assume that this is out of the scope of > the existing specifications. > > I would be interested to hear how actual implementations handle this in > practice. > > > Plus, with such AS behavior, CSRF protection using PKCE can also be > bypassed as below. > 1. The attacker removes code_challenge from his/her own AuthZ > Req, receives a non-code_challenge-bound code, and sends it to the victim.. > 2. The client receives the attacker’s code from the victim, and sends it > to the AS w/ the valid code_verifier bound to the victim’s browser session. > 3. The AS ignores the code_verifier and returns tokens. > > If that’s the case, current OAuth 2.0 PKCE implementation can be weaker > than expected.. > > Excellent point! > > Would it be okay if I add that attack to the original post (with credits, > of course)? > > -Daniel > > > nov > > > 2020/05/19 1:54、Daniel Fett <f...@danielfett.de>のメール: > > Hi all, > > Talking to Torsten, we realized that providing a generic extension point > here is probably not a good idea. It is really hard to tell what protects > you from code injection and what does not, and people might come up with > all sorts of non-standard and potentially insecure solutions. > > Even just for PKCE vs. Nonce, it is not obvious if they provide the same > level of protection. In an attempt to answer this question, I tried to come > up with a more systematic analysis of "PKCE vs Nonce". I wrote up my > results here: > https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ > > Although this is not a formal analysis, I hope that I have covered all > interesting cases. Please review the text and let me know if I have missed > something or if there are any mistakes. > > The main results are: > > 1. In terms of protection against CSRF and code misuse, PKCE and Nonce > provide similar levels of security, with a slight advantage for PKCE. > 2. In practice, a circumvention of both mechanisms, however, is > possible if an AS allows a client to choose between PKCE and Nonce and the > client makes use of this freedom. I propose to call this attack the > Nonce/PKCE Sidestep Attack. → Please review the attack description in the > analysis. > 3. To avoid the Nonce/PKCE Sidestep Attack, clients must not switch > between using only PKCE and only Nonce (but may use both in parallel, or > switch between using only PKCE and PKCE+Nonce). Authorization servers must > enforce PKCE unless they know that the client uses Nonce for all of its > flows (and checks the Nonce value). The presence of a nonce parameter in > the authorization request is not sufficient to determine if a client > actually checks the nonce claim in the ID token. > > As you can see, already having two more-or-less well-understood mechanisms > is hard enough to wrap your head around from a security standpoint. We > should therefore make PKCE the default and Nonce an option for backwards > compatibility. > To this end, I would like to propose the follwing strawman, based on > Torsten's and Aaron's suggestions: > An AS MUST reject requests without a code_challenge from public > clients, and MUST reject such requests from other clients unless there > is reasonable assurance that the client mitigates authorization code > injection using the OpenID Connect Nonce mechanism and that this > mitigation is used for all interactions with the client. See section > 9.7 for details. > > Section 9.7: > > Clients MUST prevent injection (replay) of authorization codes into > the authorization response by attackers. The use of the > `code_challenge` parameter is RECOMMENDED to this end. For > confidential clients, the OpenID Connect `nonce` parameter and ID > Token Claim {{OpenID}} MAY be used instead of or in addition to the > `code_challenge` parameter for this purpose. The `code_challenge` or > OpenID Connect `nonce` value MUST be transaction-specific and securely > bound to the client and the user agent in which the transaction was > started. > > If the OpenID Connect `nonce` is used to mitigate authorization code > injection instead of `code_challenge`, client and authorization server > MUST ensure that the mitigation is applied to every interaction with > the client and that the client cannot switch between `code_challenge` > and `nonce`. For example, the presence of a `nonce` parameter in the > authorization request is not sufficient to determine that the > `code_verifier` check can be skipped. > > Of course, we need to adapt the wording in the Security BCP accordingly. > -Daniel > > > Am 15.05.20 um 01:01 schrieb Mike Jones: > > I agree with Nov that obscuring the language in 9.7 would be a disservice to > developers. > > > > The Security BCP, which has already going the WGLC, explicitly calls out the > use of nonce as part of the best practices. OAuth 2.1 should do no less. > > > > The 9.7 language that Aaron proposed was the result of many people's > contributions and a vigorous discussion. Let's publish the next version of > 2.1 with that language intact, as I believe it represents at least a local > point of hard-won consensus. Let's get that language into the record of > drafts. > > > > There's always time to debate it and change it later in subsequent drafts, > but let's not now lose what it took a lot of effort to achieve. > > > > Thanks, > > -- Mike > > > > -----Original Message----- > > From: Nov Matake <mat...@gmail.com> <mat...@gmail.com> > > Sent: Thursday, May 14, 2020 3:18 AM > > To: Torsten Lodderstedt <tors...@lodderstedt.net> <tors...@lodderstedt.net> > > Cc: OAuth WG <oauth@ietf.org> <oauth@ietf.org>; Mike Jones > <michael.jo...@microsoft.com> <michael.jo...@microsoft.com> > > Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1 > > > > There is no specific mechanism right now. > > But future developers won’t be able to read the reason why the extension > point is given only for confidential clients. > > > > On May 14, 2020, at 18:32, Torsten Lodderstedt <tors...@lodderstedt.net> > <tors...@lodderstedt.net> wrote: > > > > Are you aware of any suitable mechanism? I’m asking since from my perspective > this clause is mainly intended to allow existing OpenID Connect deployments > to use nonce instead of PKCE in combination with OAuth 2.1. It’s a > compromise. I think we should not encourage others to invent their own OAuth > security mechanisms. > > > > On 14. May 2020, at 09:37, Nov Matake <mat...@gmail.com> <mat...@gmail.com> > wrote: > > > > Hi, > > > > Why not allowing public clients use "other suitable mechanisms” then? > > OAuth WG can allow both type of clients do so, then OIDF will define nonce as > the alternative only for confidential clients. > > > > 2020/05/14 15:56、Torsten Lodderstedt > <torsten=40lodderstedt....@dmarc.ietf.org> > <torsten=40lodderstedt....@dmarc.ietf.org>のメール: > > > > Hi all, > > > > I would also like to thank everybody for the substantial discussion. > > > > The proposed change for Section 4.1.2.1 works for me (as already stated). I’m > not fully comfortable with the proposed change for Section 9.7 for the > following reasons: > > > > - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE > instead of requiring it (with a well-defined exception). > > - Given the latest findings re nonce I don’t feel comfortable with > recommending any mechanism that this WG is not responsible for and thus did > not conduct the security threat analysis for. I think the better way for us > as WG is to define the extension point for other mechanisms. The OpenID > Foundation (or any other body) can then fill in and issue a statement that > nonce (or another suitable mechanism) fulfils the requirements of the > extension point. > > > > Based on this considerations, I propose the following text for Section 9.7: > > > > Clients MUST prevent injection (replay) of authorization codes into > > the authorization response by attackers. Public clients MUST use the > > "code_challenge” with a transaction-specific value that is securely > > bound to the client and the user agent in which the transaction was > > started. Confidential clients MUST use the “code_challenge” in the > > same way or other suitable mechanisms to mitigate authorization code > > injection. > > > > This text follows the logic in Section 4.1.2.1 and allows use of the nonce > for confidential clients. > > > > best regards, > > Torsten. > > > > On 12. May 2020, at 02:21, Mike Jones > <Michael.Jones=40microsoft....@dmarc.ietf.org> > <Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: > > > > That works for me. Thanks all for the useful back-and-forth that got us to > this point of clarity. I suspect many of us learned things along the way; I > know that I did! > > > > Cheers, > > -- Mike > > > > From: Aaron Parecki <aa...@parecki.com> <aa...@parecki.com> > > Sent: Monday, May 11, 2020 4:55 PM > > To: OAuth WG <oauth@ietf.org> <oauth@ietf.org> > > Cc: Neil Madden <neil.mad...@forgerock.com> <neil.mad...@forgerock.com>; Mike > Jones > > <michael.jo...@microsoft.com> <michael.jo...@microsoft.com> > > Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1 > > > > Thank you Neil. > > > > To address Mike's concerns in the previous threads, I would like to also > update section 9.7 with the following text: > > > > Clients MUST prevent injection (replay) of authorization codes into > > the authorization response by attackers. The use of the > > `code_challenge` parameter is RECOMMENDED to this end. For > > confidential clients, the OpenID Connect `nonce` parameter and ID > > Token Claim {{OpenID}} MAY be used instead of or in addition to the > > `code_challenge` parameter for this purpose. The `code_challenge` > > or OpenID Connect `nonce` value MUST be transaction-specific and > > securely bound to the client and the user agent in which the transaction was > started. > > > > This change better clarifies the specific circumstances under which the > "nonce" parameter is sufficient to protect against authorization code > injection. > > > > Aaron Parecki > > > > On Mon, May 11, 2020 at 11:55 AM Neil Madden <neil.mad...@forgerock.com> > <neil.mad...@forgerock.com> wrote: > > I am happy with this proposed wording. Thanks for updating it. > > > > — Neil > > > > > > On 11 May 2020, at 19:52, Aaron Parecki <aa...@parecki.com> > <aa...@parecki.com> wrote: > > > > Thanks for the lively discussion around PKCE in OAuth 2.1 everyone! > > > > We would like to propose the following text, which is a slight variation from > the text Neil proposed. This would replace the paragraph in 4.1.2.1 > (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) > that begins with "If the client does not send the "code_challenge" in the > request..." > > > > "An AS MUST reject requests without a code_challenge from public clients, and > MUST reject such requests from other clients unless there is reasonable > assurance that the client mitigates authorization code injection in other > ways.. See section 9.7 for details." > > > > Section 9.7 is where the nuances of PKCE vs nonce are described. > > > > As Neil described, we believe this will allow ASs to support both OAuth 2..0 > and 2.1 clients simultaneously. The change from Neil's text is the > clarification of which threats, and changing to MUST instead of SHOULD. The > "MUST...unless" is more specific than "SHOULD", and since we are already > describing the explicit exception to the rule, it's more clear as a MUST here. > > > > Aaron Parecki > > > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
