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: >>> 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> >>>> 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 >>> https://www.ietf.org/mailman/listinfo/oauth >>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
