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 0B2D73A1258 for ; Mon, 18 May 2020 23:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=gmail.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 D5g9blqoDMaP for ; Mon, 18 May 2020 23:50:19 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 77E9E3A125B for ; Mon, 18 May 2020 23:50:19 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id u35so5944293pgk.6 for ; Mon, 18 May 2020 23:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=cawxnkT5+UdXaPEybh2K3nzq1o1gvSP1oCPVZgDB+0s=; b=OrLCISVeLIqsLGchkbpCcDTJW1ljRyRkUiRvr8mI/0ZO6EHcQP3kRtLj6grmd+BAoM trCe1NECyavPDoN22rSkt2ooxwtSM+auVIWuIJ4fH2BBg0Y4OlyD/fOvPGYH/6Jb/NRT nArp1gmhDs937Fs6QMbNTZ0+CImupbPfM4KuYlGt0nnzyZILSFRcAD4cJFFjUjdQUsuz ctJKiw8+JgesYblqr1id09TYU1HvEmtYaCTtyzR+dSsCCSOe77mpMGFlgGfd8+fUMUag sJ17okqfOJI1eNRROeZTFrmO4Ikqop13RRw328MGIcZtTIjWNBxHrpz1kadQ4LVuz25k pmTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=cawxnkT5+UdXaPEybh2K3nzq1o1gvSP1oCPVZgDB+0s=; b=S8EARgxAaQPDGpH0dnj+sl8aVKsBlEtLyggJTm9RWptV/pw/dK+l7hXp4jVGr1eVAR DlUE1IHO996Np5QEruOzH5kc/vDl7VXJqBNAJC5An4DpwH8CIc37d4mCfeCBWa5dAf5Z sif/q8r92sXEHAHjmhqrTN5JqVKfyKq9ln26hjYFEKkSP0k0KgWeYNVF9g6Eg89uiDSf gPAAyxaebE8Y2L67qasmo3hwlxZN9h4ToyPmKdOvC3CgSUmkjzUuiuAyhw1U5AvimrMm jLpxKdzPmtCvdrzhgu3M4IL+spPD2m10U6iAWKb8PcONqFHiky7Rb0EY6UNQ9C7pVNNt hqTg== X-Gm-Message-State: AOAM531UWyInEXZJTJGT/hxPZRnInqYpUtx5IvTvBHcK8Ha0Xex8/GpZ +gXU2LirGAY8Eo0dt99yyX/IcHh5rlI= X-Google-Smtp-Source: ABdhPJz9pvmq1M0uhMsUkAn1aHTkzu6c+8z0RPXgl1iwuPD5YayN3H//Zu3D1JFGahLRZzCQnY9ayw== X-Received: by 2002:a63:d954:: with SMTP id e20mr18198287pgj.360.1589871018396; Mon, 18 May 2020 23:50:18 -0700 (PDT) Received: from [172.16.80.56] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id e26sm3324135pgl.27.2020.05.18.23.50.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 23:50:17 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9FB001C3-9474-4336-A965-9A1976FD4F56 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Nov Matake In-Reply-To: <14646700-07c4-6a1b-0414-a6a9a52db903@danielfett.de> Cc: "oauth@ietf.org" Date: Tue, 19 May 2020 15:50:16 +0900 Message-Id: <9B54DA4A-ED50-432B-8B32-D0602BB9D2FA@gmail.com> References: <14646700-07c4-6a1b-0414-a6a9a52db903@danielfett.de> To: Daniel Fett X-Mailer: iPad Mail (17E262) 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: Tue, 19 May 2020 06:50:23 -0000 --Apple-Mail-9FB001C3-9474-4336-A965-9A1976FD4F56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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/extens= ion/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, >=20 > Am 19.05.20 um 04:55 schrieb Nov Matake: >> I thought the server MUST reject such token requests, but I couldn=E2=80=99= t find such definition in RFC7636... >>=20 >> > The client will send the code, along with a (now not matching) code_ver= ifier 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 >>=20 >> 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 PK= CE and sometimes using Nonce. I assume that this is out of the scope of the e= xisting specifications.=20 >=20 > I would be interested to hear how actual implementations handle this in pr= actice. >=20 >>=20 >> Plus, with such AS behavior, CSRF protection using PKCE can also be bypas= sed as below. >> 1. The attacker removes code_challenge from his/her own AuthZ Req, receiv= es 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 b= rowser session. >> 3. The AS ignores the code_verifier and returns tokens. >>=20 >> If that=E2=80=99s the case, current OAuth 2.0 PKCE implementation can be w= eaker than expected.. > Excellent point! >=20 > Would it be okay if I add that attack to the original post (with credits, o= f course)? >=20 > -Daniel >=20 >>=20 >> nov >>=20 >>> 2020/05/19 1:54=E3=80=81Daniel Fett =E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: >>>=20 >>> Hi all, >>>=20 >>> 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 y= ou from code injection and what does not, and people might come up with all s= orts of non-standard and potentially insecure solutions.=20 >>>=20 >>> 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 result= s here:=20 >>> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ >>>=20 >>> Although this is not a formal analysis, I hope that I have covered all i= nteresting cases. Please review the text and let me know if I have missed so= mething or if there are any mistakes. >>>=20 >>> The main results are: >>> In terms of protection against CSRF and code misuse, PKCE and Nonce prov= ide 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 A= ttack. =E2=86=92 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 bet= ween using only PKCE and PKCE+Nonce). Authorization servers must enforce PKC= E unless they know that the client uses Nonce for all of its flows (and chec= ks the Nonce value). The presence of a nonce parameter in the authorization r= equest is not sufficient to determine if a client actually checks the nonce c= laim in the ID token. >>> As you can see, already having two more-or-less well-understood mechanis= ms is hard enough to wrap your head around from a security standpoint. We sh= ould therefore make PKCE the default and Nonce an option for backwards compa= tibility. >>>=20 >>> To this end, I would like to propose the follwing strawman, based on Tor= sten's and Aaron's suggestions: >>>=20 >>> 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. >>>=20 >>> Section 9.7: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> Of course, we need to adapt the wording in the Security BCP accordingly.= >>>=20 >>> -Daniel >>>=20 >>>=20 >>>=20 >>>=20 >>> Am 15.05.20 um 01:01 schrieb Mike Jones: >>>> I agree with Nov that obscuring the language in 9.7 would be a disservi= ce to developers. >>>>=20 >>>> The Security BCP, which has already going the WGLC, explicitly calls ou= t the use of nonce as part of the best practices. OAuth 2.1 should do no le= ss. >>>>=20 >>>> The 9.7 language that Aaron proposed was the result of many people's co= ntributions 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 drafts= . >>>>=20 >>>> There's always time to debate it and change it later in subsequent draf= ts, but let's not now lose what it took a lot of effort to achieve. >>>>=20 >>>> Thanks, >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: Nov Matake =20 >>>> 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 >>>>=20 >>>> There is no specific mechanism right now. >>>> But future developers won=E2=80=99t be able to read the reason why the e= xtension point is given only for confidential clients. >>>>=20 >>>>>>> On May 14, 2020, at 18:32, Torsten Lodderstedt wrote: >>>>>>>=20 >>>>>>> Are you aware of any suitable mechanism? I=E2=80=99m asking since fr= om my perspective this clause is mainly intended to allow existing OpenID Co= nnect deployments to use nonce instead of PKCE in combination with OAuth 2.1= . It=E2=80=99s a compromise. I think we should not encourage others to inven= t their own OAuth security mechanisms.=20 >>>>>>>=20 >>>>>>>> On 14. May 2020, at 09:37, Nov Matake wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> Why not allowing public clients use "other suitable mechanisms=E2=80= =9D then? >>>>>>>> OAuth WG can allow both type of clients do so, then OIDF will defin= e nonce as the alternative only for confidential clients. >>>>>>>>=20 >>>>>>>> 2020/05/14 15:56=E3=80=81Torsten Lodderstedt =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> I would also like to thank everybody for the substantial discussion= . =20 >>>>>>>>=20 >>>>>>>> The proposed change for Section 4.1.2.1 works for me (as already st= ated). I=E2=80=99m not fully comfortable with the proposed change for Sectio= n 9.7 for the following reasons: >>>>>>>>=20 >>>>>>>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use o= f PKCE instead of requiring it (with a well-defined exception). >>>>>>>> - Given the latest findings re nonce I don=E2=80=99t feel comfortab= le with recommending any mechanism that this WG is not responsible for and t= hus 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 Ope= nID Foundation (or any other body) can then fill in and issue a statement th= at nonce (or another suitable mechanism) fulfils the requirements of the ext= ension point.=20 >>>>>>>>=20 >>>>>>>> Based on this considerations, I propose the following text for Sect= ion 9.7: >>>>>>>>=20 >>>>>>>> Clients MUST prevent injection (replay) of authorization codes into= =20 >>>>>>>> the authorization response by attackers. Public clients MUST use th= e=20 >>>>>>>> "code_challenge=E2=80=9D with a transaction-specific value that is s= ecurely=20 >>>>>>>> bound to the client and the user agent in which the transaction was= =20 >>>>>>>> started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2= =80=9D in the=20 >>>>>>>> same way or other suitable mechanisms to mitigate authorization cod= e=20 >>>>>>>> injection. >>>>>>>>=20 >>>>>>>> This text follows the logic in Section 4.1.2.1 and allows use of th= e nonce for confidential clients. >>>>>>>>=20 >>>>>>>> best regards, >>>>>>>> Torsten.=20 >>>>>>>>=20 >>>>>>>> On 12. May 2020, at 02:21, Mike Jones wrote: >>>>>>>>=20 >>>>>>>> That works for me. Thanks all for the useful back-and-forth that g= ot us to this point of clarity. I suspect many of us learned things along t= he way; I know that I did! >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>> From: Aaron Parecki >>>>>>>> Sent: Monday, May 11, 2020 4:55 PM >>>>>>>> To: OAuth WG >>>>>>>> Cc: Neil Madden ; Mike Jones=20 >>>>>>>> >>>>>>>> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1 >>>>>>>>=20 >>>>>>>> Thank you Neil. >>>>>>>>=20 >>>>>>>> To address Mike's concerns in the previous threads, I would like to= also update section 9.7 with the following text: >>>>>>>>=20 >>>>>>>> Clients MUST prevent injection (replay) of authorization codes into= =20 >>>>>>>> the authorization response by attackers. The use of the=20 >>>>>>>> `code_challenge` parameter is RECOMMENDED to this end. For=20 >>>>>>>> confidential clients, the OpenID Connect `nonce` parameter and ID=20= >>>>>>>> Token Claim {{OpenID}} MAY be used instead of or in addition to the= =20 >>>>>>>> `code_challenge` parameter for this purpose. The `code_challenge`=20= >>>>>>>> or OpenID Connect `nonce` value MUST be transaction-specific and=20= >>>>>>>> securely bound to the client and the user agent in which the transa= ction was started. >>>>>>>>=20 >>>>>>>> This change better clarifies the specific circumstances under which= the "nonce" parameter is sufficient to protect against authorization code i= njection. >>>>>>>>=20 >>>>>>>> Aaron Parecki >>>>>>>>=20 >>>>>>>> On Mon, May 11, 2020 at 11:55 AM Neil Madden wrote: >>>>>>>> I am happy with this proposed wording. Thanks for updating it. >>>>>>>>=20 >>>>>>>> =E2=80=94 Neil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 11 May 2020, at 19:52, Aaron Parecki wrote: >>>>>>>>=20 >>>>>>>> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!= =20 >>>>>>>>=20 >>>>>>>> We would like to propose the following text, which is a slight vari= ation 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 r= equest..." >>>>>>>>=20 >>>>>>>> "An AS MUST reject requests without a code_challenge from public cl= ients, and MUST reject such requests from other clients unless there is reas= onable assurance that the client mitigates authorization code injection in o= ther ways. See section 9.7 for details." >>>>>>>>=20 >>>>>>>> Section 9.7 is where the nuances of PKCE vs nonce are described. >>>>>>>>=20 >>>>>>>> As Neil described, we believe this will allow ASs to support both O= Auth 2.0 and 2.1 clients simultaneously. The change from Neil's text is the c= larification of which threats, and changing to MUST instead of SHOULD. The "= MUST...unless" is more specific than "SHOULD", and since we are already desc= ribing the explicit exception to the rule, it's more clear as a MUST here. >>>>>>>>=20 >>>>>>>> Aaron Parecki >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail-9FB001C3-9474-4336-A965-9A1976FD4F56 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sure, feel free to add the= senario to your post.

FYI:=
my OAuth2 server ruby gem rejects such token requests,
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 <fett@danielfett.de>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:

=EF= =BB=BF =20 =20 =20
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 wit= h 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-n= ot/#noncepkce-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-b= ound 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.

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 <fett@d= anielfett.de>=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 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-n= once-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. =E2=86=92 Please review the attack descripti= on 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<= br class=3D""> 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 No=
v 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 contrib=
utions and a vigorous discussion.  Let's publish the next version of 2.1 wit=
h 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, b=
ut let's not now lose what it took a lot of effort to achieve.

				Thanks,
				-- Mike

-----Original Message-----
From: Nov Matake <matake@gmail.com>=20
Sent: Thursday, May 14, 2020 3:18 AM
To: Torsten Lodderstedt <torsten@lodderstedt.net&=
gt;
Cc: OAuth WG <oauth@ietf.org>; Mike Jones <Michael.Jones@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=E2=80=99t be able to read the reason why the exten=
sion point is given only for confidential clients.


On May 14, 20=
20, at 18:32, Torsten Lodderstedt <torsten@lodder=
stedt.net> wrote:

Are you aware of any suitable mechanism? I=E2=80=99m asking since from my pe=
rspective this clause is mainly intended to allow existing OpenID Connect de=
ployments to use nonce instead of PKCE in combination with OAuth 2.1. It=E2=80=
=99s a compromise. I think we should not encourage others to invent their ow=
n OAuth security mechanisms.=20


On 14. May 2=
020, at 09:37, Nov Matake <matake@gmail.com> wrot=
e:

Hi,

Why not allowing public clients use "other suitable mechanisms=E2=80=9D then=
?
OAuth WG can allow both type of clients do so, then OIDF will define nonce a=
s the alternative only for confidential clients.


2020/05/1=
4 15:56=E3=80=81Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>=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. =20

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 t=
he following reasons:

- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE in=
stead of requiring it (with a well-defined exception).
- Given the latest findings re nonce I don=E2=80=99t feel comfortable with r=
ecommending any mechanism that this WG is not responsible for and thus did n=
ot conduct the security threat analysis for. I think the better way for us a=
s WG is to define the extension point for other mechanisms. The OpenID Found=
ation (or any other body) can then fill in and issue a statement that nonce (=
or another suitable mechanism) fulfils the requirements of the extension poi=
nt.=20

Based on this considerations, I propose the following text for Section 9.7:

Clients MUST prevent injection (replay) of authorization codes into=20
the authorization response by attackers. Public clients MUST use the=20
"code_challenge=E2=80=9D with a transaction-specific value that is securely=20=

bound to the client and the user agent in which the transaction was=20
started. Confidential clients MUST use the =E2=80=9Ccode_challenge=E2=80=9D i=
n the=20
same way or other suitable mechanisms to mitigate authorization code=20
injection.

This text follows the logic in Section 4.1.2.1 and allows use of the nonce f=
or confidential clients.

best regards,
Torsten.=20


On 12. M=
ay 2020, at 02:21, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

That works for me.  Thanks all for the useful back-and-forth that got us to t=
his point of clarity.  I suspect many of us learned things along the way; I k=
now that I did!

                                                    Cheers,
                                                    -- Mike

From: Aaron Parecki <aaron@parecki.com>
Sent: Monday, May 11, 2020 4:55 PM
To: OAuth WG <oauth@ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com><=
/a>; Mike Jones=20
<Michael.Jones@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 upd=
ate section 9.7 with the following text:

Clients MUST prevent injection (replay) of authorization codes into=20
the authorization response by attackers. The use of the=20
`code_challenge` parameter is RECOMMENDED to this end. For=20
confidential clients, the OpenID Connect `nonce` parameter and ID=20
Token Claim {{OpenID}} MAY be used instead of or in addition to the=20
`code_challenge` parameter for this purpose. The `code_challenge`=20
or OpenID Connect `nonce` value MUST be transaction-specific and=20
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 "non=
ce" parameter is sufficient to protect against authorization code injection.=


Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden <n=
eil.madden@forgerock.com> 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 <aaron@parecki.=
com> wrote:

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!=20

We would like to propose the following text, which is a slight variation fro=
m the text Neil proposed. This would replace the paragraph in 4.1.2.1 (https://tools.ie=
tf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that begins wit=
h "If the client does not send the "code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from public clients, an=
d MUST reject such requests from other clients unless there is reasonable as=
surance 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 a=
nd 2.1 clients simultaneously. The change from Neil's text is the clarificat=
ion of which threats, and changing to MUST instead of SHOULD. The "MUST...un=
less" is more specific than "SHOULD", and since we are already describing th=
e 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/o=
auth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o=
auth

_________=
______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o=
auth

_______________=
________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o=
auth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


=20
= --Apple-Mail-9FB001C3-9474-4336-A965-9A1976FD4F56--