Hi, 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 <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. 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.. 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/ > <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: > In terms of protection against CSRF and code misuse, PKCE and Nonce provide > similar levels of security, with a slight advantage for PKCE. > 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. > 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> <mailto:mat...@gmail.com> >> Sent: Thursday, May 14, 2020 3:18 AM >> To: Torsten Lodderstedt <tors...@lodderstedt.net> >> <mailto:tors...@lodderstedt.net> >> Cc: OAuth WG <oauth@ietf.org> <mailto:oauth@ietf.org>; Mike Jones >> <michael.jo...@microsoft.com> <mailto: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> >>> <mailto: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> >>>> <mailto: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> >>>>> <mailto: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> >>>>>> <mailto: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> <mailto:aa...@parecki.com> >>>>>> Sent: Monday, May 11, 2020 4:55 PM >>>>>> To: OAuth WG <oauth@ietf.org> <mailto:oauth@ietf.org> >>>>>> Cc: Neil Madden <neil.mad...@forgerock.com> >>>>>> <mailto:neil.mad...@forgerock.com>; Mike Jones >>>>>> <michael.jo...@microsoft.com> <mailto: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> >>>>>> <mailto: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> >>>>>> <mailto: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 >>>>>> <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 <mailto:OAuth@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <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
