Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234D33A0896 for ; Wed, 20 May 2020 15:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx38byCpGLCJ for ; Wed, 20 May 2020 15:48:34 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796653A088C for ; Wed, 20 May 2020 15:48:34 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id f3so5248307ioj.1 for ; Wed, 20 May 2020 15:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KKJFxMrFvJaMFRjLn1wxWQLV7Tur58hRPE46tt3iv0A=; b=EJNw2Z3nU/D+2Wanw4XB23IMHC0EH/GGm3W6Zj67N370nNF5NB7lpUCg0YnSMvM8jH QMR/kF0i1Jo4Sva1tBV5UhNDTrDUoPD16OoZC1UCZ7F5zx7XGigMMgPZXcWddC7xg+Y0 UzuhrPlPM1V3nsd+UON5wnnnLXJ7qjbh6qsxkAqJG9iq41ZAeP+WGDLRjVIg/+m+9OY8 tmfRCnqrDooMxXSfS6w9D/9Yk3PtXFPfBHVo9tiy6gGfRBl27isLtfNLnjUURhs+wS/R 8Pz4GBOIqHDFi1h0Ps4hOPNBlBINQOz7bVIxo2C9/dnZm5QmAWy55GUXhiIO5KfqxTRO 8PjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KKJFxMrFvJaMFRjLn1wxWQLV7Tur58hRPE46tt3iv0A=; b=YRJvv9SdtGuZMB2XanTlOsGUZkEiTohN8DcGuO5qpvt2wDOYhCRBXrtbqQSX/Jz00j zXZtOhzIJclb1fR7um/pwI5EEUu2HpIQMMpo57tAYm7P+5zq7to9RG+q6yv95GgUYia5 tCEQ4/PRSwU1MDzuw7i+3bEe9C2Gcu8erB//RezuYG6PfY6qun8zrCAhOI1ZuR3d5xTu 1INkz7WDpHUoRtBR44VpiCvYFzvIY33NNSYGBdx6cbA2cBP80qZHDP6YnlTk+tKdkxuk 2KqQml+/Jzwtq7+cvjBQmpTabIP8pwccejaZMlFHhfwsDboFJeFlnr0g2IjqVDKyI/B/ Gy1Q== X-Gm-Message-State: AOAM530vaMTtkzfEKUTaZpNK7UGvbzsXmMmOkJ2QhbvPladh1+HTje7Z ZHNxK8rkdaG63l+FG1BQGkJyFq0NJe4= X-Google-Smtp-Source: ABdhPJxB6s9IFEO+tez7O3WR0EzgzAVNxq6+5uBZipdTBE0L23L6SpTkPnZn2rDiKfnBF5+MGJ2fmQ== X-Received: by 2002:a6b:14c9:: with SMTP id 192mr2924412iou.174.1590014912795; Wed, 20 May 2020 15:48:32 -0700 (PDT) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com. [209.85.166.49]) by smtp.gmail.com with ESMTPSA id u2sm1645583ion.50.2020.05.20.15.48.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2020 15:48:31 -0700 (PDT) Received: by mail-io1-f49.google.com with SMTP id j8so5152662iog.13 for ; Wed, 20 May 2020 15:48:31 -0700 (PDT) X-Received: by 2002:a6b:d219:: with SMTP id q25mr5415759iob.202.1590014911186; Wed, 20 May 2020 15:48:31 -0700 (PDT) MIME-Version: 1.0 References: <67F643A9-47E5-4339-B6B0-E39C7B959EF7@gmail.com> In-Reply-To: <67F643A9-47E5-4339-B6B0-E39C7B959EF7@gmail.com> From: Aaron Parecki Date: Wed, 20 May 2020 15:48:20 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Nov Matake Cc: Mike Jones , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f80ca305a61c3129" Archived-At: Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 22:48:40 -0000 --000000000000f80ca305a61c3129 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Yes. > > The root problem isn=E2=80=99t the mix-use of PKCE and nonce, it=E2=80=99= s PKCE > implementation bug. > Yeah, all PKCE implementation MUST reject such requests, regardless it=E2= =80=99s > OAuth 2.1 or 2.0. > > (and it=E2=80=99s probably because of PKCE spec=E2=80=99s ambiguity..) > > 2020/05/20 1:13=E3=80=81Mike Jones =E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB: > > 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 *On Behalf Of *Nov Matake > *Sent:* Monday, May 18, 2020 11:50 PM > *To:* Daniel Fett > *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/ext= ension/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=E3=81=8B=E3=82=89=E9=80=81=E4=BF=A1 > > > 2020/05/19 15:43=E3=80=81Daniel Fett =E3=81=AE=E3=83= =A1=E3=83=BC=E3=83=AB: > > =EF=BB=BF > Hi, > > Am 19.05.20 um 04:55 schrieb Nov Matake: > > I thought the server MUST reject such token requests, but I couldn=E2=80= =99t 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/#noncepk= ce-sidestep-attack > > If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack=E2= =80=9D > 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=E2=80=99s code from the victim, and s= ends it > to the AS w/ the valid code_verifier bound to the victim=E2=80=99s browse= r session. > 3. The AS ignores the code_verifier and returns tokens. > > If that=E2=80=99s 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=E3=80=81Daniel Fett =E3=81=AE=E3=83= =A1=E3=83=BC=E3=83=AB: > > 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 co= me > 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 misse= d > 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. =E2=86=92 Please review the attack descrip= tion 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 it= s > 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 mechanism= s > 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 les= s. > > > > The 9.7 language that Aaron proposed was the result of many people's cont= ributions 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 poi= nt of hard-won consensus. Let's get that language into the record of draft= s. > > > > 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 > > Sent: Thursday, May 14, 2020 3:18 AM > > To: Torsten Lodderstedt > > Cc: OAuth WG ; Mike Jones > > Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1 > > > > There is no specific mechanism right now. > > But future developers won=E2=80=99t be able to read the reason why the ex= tension point is given only for confidential clients. > > > > On May 14, 2020, at 18:32, Torsten Lodderstedt = wrote: > > > > Are you aware of any suitable mechanism? I=E2=80=99m asking since from my= perspective this clause is mainly intended to allow existing OpenID Connec= t deployments to use nonce instead of PKCE in combination with OAuth 2.1. I= t=E2=80=99s 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 wrote: > > > > Hi, > > > > Why not allowing public clients use "other suitable mechanisms=E2=80=9D t= hen? > > OAuth WG can allow both type of clients do so, then OIDF will define nonc= e as the alternative only for confidential clients. > > > > 2020/05/14 15:56=E3=80=81Torsten Lodderstedt =E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB: > > > > 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=E2=80=99m 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=E2=80=99t feel comfortable wit= h recommending any mechanism that this WG is not responsible for and thus d= id 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 exte= nsion 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=E2=80=9D with a transaction-specific value that is secure= ly > > bound to the client and the user agent in which the transaction was > > started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80= =9D 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 nonc= e for confidential clients. > > > > best regards, > > Torsten. > > > > On 12. May 2020, at 02:21, Mike Jones 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 wa= y; I know that I did! > > > > Cheers, > > -- Mike > > > > From: Aaron Parecki > > Sent: Monday, May 11, 2020 4:55 PM > > To: OAuth WG > > Cc: Neil Madden ; = Mike Jones > > > > 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 inject= ion. > > > > Aaron Parecki > > > > On Mon, May 11, 2020 at 11:55 AM Neil Madden = wrote: > > I am happy with this proposed wording. Thanks for updating it. > > > > =E2=80=94 Neil > > > > > > On 11 May 2020, at 19:52, Aaron Parecki 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 (h= ttps://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) tha= t begins with "If the client does not send the "code_challenge" in the requ= est..." > > > > "An AS MUST reject requests without a code_challenge from public clients,= and MUST reject such requests from other clients unless there is reasonabl= e 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 clari= fication of which threats, and changing to MUST instead of SHOULD. The "MUS= T...unless" is more specific than "SHOULD", and since we are already descri= bing 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 > --000000000000f80ca305a61c3129 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So if I'm understanding this correctly, it sounds like= the AS needs to reject a token request with code_verifier if the authoriza= tion code was issued in response to a request that did not contain a code_c= hallenge. This to me sounds like it would be simpler to just say the code_c= hallenge and code_verifier are always required.

That sai= d, I do understand the previously discussed concerns around existing OpenID= Connect clients.

I believe the text that Daniel p= roposed is the best of both worlds, and I support making this change in bot= h OAuth 2.1 and the Security BCP.

Aaron Parecki



<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 19, 2020 at 9:29 AM Nov Ma= take <matake@gmail.com> wrote= :
Yes.

The root problem isn=E2=80=99= t the mix-use of PKCE and nonce, it=E2=80=99s PKCE implementation bug.
Yeah, all PKCE implementation MUST r= eject such requests, regardless it=E2=80=99s OAuth 2.1 or 2.0.
=

(and it=E2=80=99s=C2=A0probably=C2=A0because of = PKCE spec=E2=80=99s ambiguity..)

2020/05/20 1:13=E3=80=81Mike Jones <Michael.Jones@microsoft.com= >=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

So it sounds me like the fix= is to have servers reject PKCE requests with incomplete parameter sets: re= quests that only contains one of code_challenge and code_verified.=C2=A0 Wi= ll that eliminate the attack, Nov?
=C2=A0
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=
=C2= =A0
From:=C2=A0OAuth <oauth-bounces@ietf.org>=C2=A0On Behalf Of= =C2=A0Nov Matake
Sent:=C2=A0Monday, May 1= 8, 2020 11:50 PM
To:=C2=A0Daniel Fett <fett@danielfett.de>
Cc:=C2=A0oauth@ietf.org
Subject:=C2=A0= Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
=C2=A0
Sure= , feel free to add the senario to your post.
=
=C2=A0
FYI:
my OAuth2 server ruby gem rejects such token requests,=
=C2=A0
Am 19.05.20 um 04:55 schrieb Nov Matake:
=
I thought the server MUST reject such token requests, but I could= n=E2=80=99t find such definition in RFC7636...
=C2=A0
>=C2=A0Th= e 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 expe= cted) and send back an access token and ID token to the client.
=C2=A0
If the behavior is acceptable by RFC7636, "Nonce/PKCE Sides= tep Attack=E2=80=9D would be possible.

I *think* that there is nothing preventing servers f= rom sometimes using PKCE and sometimes using Nonce. I assume that this is o= ut of the scope of the existing specifications.

I would= be interested to hear how actual implementations handle this in practice.<= u>

=C2=A0
Plus, = with such AS behavior, CSRF protection using PKCE can also be bypassed as b= elow.
1. The attacker removes code_= challenge from his/her own AuthZ Req,=C2=A0receives=C2=A0a non-code_challen= ge-bound code, and sends it to the victim.
2. The client receives the attacker=E2=80=99s code from the victim,= and sends it to the AS w/ the valid code_verifier bound to the victim=E2= =80=99s browser session.
3. The AS = ignores the code_verifier and returns tokens.
=C2=A0
If that=E2=80=99s= the case, current OAuth 2.0 PKCE implementation can be weaker than expecte= d..

Excellent point!

Would it be okay if I add that attack to the original po= st (with credits, of course)?

-Daniel

=
=C2=A0
nov
=


2020/05/19 1:54=E3=80=81Daniel Fett <fett@danielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
=C2=A0
Hi all,
=C2=A0<= /div>
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 peopl= e might come up with all sorts of non-standard and potentially insecure sol= utions.=C2=A0
= =C2=A0
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 o= f "PKCE vs Nonce". I wrote up my results here:

Although this is not a for= mal analysis, I hope that I have covered all interesting cases. Please revi= ew 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 N= once and the client makes use of this freedom. I propose to call this attac= k the Nonce/PKCE Sidestep Attack. =E2=86=92 Please review the attack descri= ption in the analysis.
  2. To av= oid the Nonce/PKCE Sidestep Attack, clients must not switch between using o= nly PKCE and only Nonce (but may use both in parallel, or switch between us= ing only PKCE and PKCE+Nonce). Authorization servers must enforce PKCE unle= ss they know that the client uses Nonce for all of its flows (and checks th= e Nonce value). The presence of a nonce parameter in the authorization requ= est is not sufficient to determine if a client actually checks the nonce cl= aim in the ID token.
As you can see, alrea= dy having two more-or-less well-understood mechanisms is hard enough to wra= p your head around from a security standpoint. We should therefore make PKC= E 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 publ= ic
clients, and MU= ST reject such requests from other clients unless there
is reasonable assurance that the c= lient mitigates authorization code
injection using the OpenID Connect Nonce mechanism and th= at this
mitigatio= n is used for all interactions with the client. See section
9.7 for details.
=
Section 9.7:

<= span style=3D"font-size:10pt">Clients MUST prevent injection (replay) of au= thorization codes into
the authorization response by attackers. The use of the
`code_challenge` parameter is R= ECOMMENDED to this end. For
confidential clients, the OpenID Connect `nonce` parameter and I= D
Token Claim {{O= penID}} MAY be used instead of or in addition to the
`code_challenge` parameter for this pur= pose. 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 u= sed to mitigate authorization code
injection instead of `code_challenge`, client and authori= zation server
MUS= T ensure that the mitigation is applied to every interaction with
<= tt style=3D"font-family:"Courier New"">the client and that the cl= ient cannot switch between `code_challenge`
and `nonce`. For example, the presence of a `non= ce` parameter in the
authorization request is not sufficient to determine that the
<= tt style=3D"font-family:"Courier New"">`code_verifier` check can = be skipped.
=C2=A0
Of course, we need to adapt the wording in the Security BCP a= ccordingly.
-Daniel
=C2=A0
=C2=A0
Am 15.05.20 um 01:01 schrieb Mike Jones:
=C2=A0
The Security BCP, which has already going the WGLC, explici=
tly calls out the use of nonce as part of the best practices.=C2=A0 OAuth 2=
.1 should do no less.
=C2=A0
The 9.7 language that Aaron proposed was the result o=
f many people's contributions and a vigorous discussion.=C2=A0 Let'=
s publish the next version of 2.1 with that language intact, as I believe i=
t represents at least a local point of hard-won consensus.=C2=A0 Let's =
get that language into the record of drafts.
=C2=A0
There's always time to de=
bate it and change it later in subsequent drafts, but let's not now los=
e what it took a lot of effort to achieve.
    Thanks,
<=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Couri=
er New"">    -- Mike
=C2=A0
-----Original Message-----
From: Nov Matake <matake@gmail.com= > 
Sent: Thursday, May 14, 2020 3:=
18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: OAuth WG <oauth@ietf.org>=
;; Mike Jones <Michael.Jones@mi=
crosoft.com>
Subject: Re: [OAUTH-W=
G] proposed resolution for PKCE in OAuth 2.1
=C2=A0
There is no specific mechanis=
m right now.
But future developers won=E2=
=80=99t be able to read the reason why the extension point is given only fo=
r confidential clients.
=C2=A0<=
/u>
On May 14, 2020, at 18:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
<=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Couri=
er New"">=C2=A0
Are you aware of any=
 suitable mechanism? I=E2=80=99m asking since from my perspective this clau=
se is mainly intended to allow existing OpenID Connect deployments to use n=
once instead of PKCE in combination with OAuth 2.1. It=E2=80=99s a compromi=
se. I think we should not encourage others to invent their own OAuth securi=
ty mechanisms. 
=C2=A0
On 1=
4. May 2020, at 09:37, Nov Matake <matake@gmai=
l.com> wrote:
=C2=A0=

Hi,
=C2=A0=

Why not allowing public clients use "other su=
itable mechanisms=E2=80=9D then?
OAuth WG=
 can allow both type of clients do so, then OIDF will define nonce as the a=
lternative only for confidential clients.
=C2=A0
2020/05/14 15:56=E3=80=81Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org&g=
t;=E3=81=AE=E3=83=A1=
=E3=83=BC=E3=83=AB:
=C2=A0<=
u>
Hi all,
=C2=A0
I would also like to thank everybody for=
 the substantial discussion.=C2=A0 
=C2=A0
The proposed change for Section 4.1.2.1=
 works for me (as already stated). I=E2=80=99m not fully comfortable with t=
he proposed change for Section 9.7 for the following reasons:=

=C2=A0
- The text is=
 weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE instead of req=
uiring it (with a well-defined exception).
=C2=A0
<=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Couri=
er New"">Based on this considerations, I propose the following text fo=
r Section 9.7:
=C2=A0
= 
Clients MUST prevent injection (replay) of authorization cod=
es into 
the authorization response by at=
tackers. Public clients MUST use the 
&qu=
ot;code_challenge=E2=80=9D with a transaction-specific value that is secure=
ly 
bound to the client and the user agen=
t in which the transaction was 
started. =
Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=9D in the <=
u>
same way or other suitable mechanisms to =
mitigate authorization code 
injection.
=C2=A0
T=
his text follows the logic in Section 4.1.2.1 and allows use of the nonce f=
or confidential clients.
=C2=A0=

best regards,
To=
rsten. 
=C2=A0
On 12. May 2=
020, at 02:21, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:=

=C2=A0
Th=
at works for me.=C2=A0 Thanks all for the useful back-and-forth that got us=
 to this point of clarity.=C2=A0 I suspect many of us learned things along =
the way; I know that I did!
=C2=A0=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Cheers,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 -- Mike
=C2=A0=

From: Aaron Parecki <aar=
on@parecki.com>
Sent: Monday, May =
11, 2020 4:55 PM
To: OAuth WG <oauth@ietf.org>
C=
c: Neil Madden <neil.madden@forgerock=
.com>; Mike Jones 
<Michael.Jones@microsoft.com>=

Subject: Re: [OAUTH-WG] proposed resolution for PKCE i=
n OAuth 2.1
=C2=A0
Thank you Neil.
=C2=A0=

To address Mike's concerns in the previous =
threads, I would like to also update section 9.7 with the following text:
=C2=A0
C=
lients MUST prevent injection (replay) of authorization codes into <=
u>
the authorization response by attackers. The use=
 of the 
`code_challenge` parameter is RE=
COMMENDED to this end. For 
confidential =
clients, the OpenID Connect `nonce` parameter and ID
Token Claim {{OpenID}} MAY be used instead of or in addition t= o the 
`code_challenge` parameter for thi=
s purpose. The `code_challenge` 
or OpenI=
D Connect `nonce` value MUST be transaction-specific and 
securely bound to the client and the user agent in which t=
he transaction was started.
=C2=A0=

This change better clarifies the specific circu=
mstances under which the "nonce" parameter is sufficient to prote=
ct against authorization code injection.
=
=C2=A0
Aaron Parecki
<=
pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Couri=
er New"">=C2=A0
On Mon, May 11, 2020=
 at 11:55 AM Neil Madden <neil.madden=
@forgerock.com> wrote:
I am happy =
with this proposed wording. Thanks for updating it.
=C2=A0
=E2=80=94 Neil
=C2=A0
=
=C2=A0
On 11 May 2020, at 19:52, Aaron Parecki <=
a href=3D"mailto:aaron@parecki.com" style=3D"color:blue;text-decoration:und=
erline" target=3D"_blank"><aaron@parecki.com> wrote:
=C2=A0
Thanks for t=
he lively discussion around PKCE in OAuth 2.1 everyone! 
=C2=A0
We would like to p=
ropose the following text, which is a slight variation from the text Neil p=
roposed. 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 &qu=
ot;If the client does not send the "code_challenge" in the reques=
t..."
=C2=A0
"An AS MUST reject requests without a code_challenge from p=
ublic clients, and MUST reject such requests from other clients unless ther=
e is reasonable assurance that the client mitigates authorization code inje=
ction in other ways.. See section 9.7 for details."
=C2=A0
Section 9.7 is whe=
re the nuances of PKCE vs nonce are described.
=C2=A0
As Neil described, we believ=
e this will allow ASs to support both OAuth 2.0 and 2.1 clients simultaneou=
sly. The change from Neil's text is the clarification of which threats,=
 and changing to MUST instead of SHOULD. The "MUST...unless" is m=
ore specific than "SHOULD", and since we are already describing t=
he explicit exception to the rule, it's more clear as a MUST here.
=C2=A0
Aaro=
n Parecki
=C2=A0
=C2=A0
=C2=A0
=C2=A0
_________________=
______________________________
OAuth mail=
ing list
OAuth@ie=
tf.org
https://www.ietf.org/mailman/listinfo/oauth
=C2=A0
___________=
____________________________________
OAut=
h mailing list
OA=
uth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_________________________________=
______________
OAuth mailing list<=
u>
OAuth@ietf.org
=
https://www.ietf.org/mailman/listinfo/oauth
_____________________________=
__________________
OAuth mailing list<=
/u>
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=C2=A0
______________= _________________________________
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
--000000000000f80ca305a61c3129--