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 >> <mailto: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> >>> Sent: Thursday, May 14, 2020 3:18 AM >>> To: Torsten Lodderstedt <tors...@lodderstedt.net> >>> Cc: OAuth WG <oauth@ietf.org>; Mike Jones <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> >>>> 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> 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>のメール: >>>>>> >>>>>> 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> 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> >>>>>>> Sent: Monday, May 11, 2020 4:55 PM >>>>>>> To: OAuth WG <oauth@ietf.org> >>>>>>> Cc: Neil Madden <neil.mad...@forgerock.com>; Mike Jones >>>>>>> <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> 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> 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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
