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

Reply via email to