From: Kazuki Tsuzuku <ktsuzuku@yahoo-corp.jp>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Downgrade attacks on PKCE
Thread-Index: AQHWOWp55OcPG6IcEUS6ob+YhLP7N6jGfOLD
Date: Wed, 3 Jun 2020 07:30:56 +0000
Message-ID: <TY2PR01MB4700C38A9557DA97E025421595880@TY2PR01MB4700.jpnprd01.prod.outlook.com>
References: <TY2PR01MB4700B388769E725EC2A7D8A095880@TY2PR01MB4700.jpnprd01.prod.outlook.com>
In-Reply-To: <TY2PR01MB4700B388769E725EC2A7D8A095880@TY2PR01MB4700.jpnprd01.prod.outlook.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
Content-Type: multipart/alternative;
 boundary="_000_TY2PR01MB4700C38A9557DA97E025421595880TY2PR01MB4700jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6fddb812-4922-4920-4113-08d807900e10
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2020 07:30:56.5286 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a208d369-cd4e-4f87-b119-98eaf31df2c3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OENxltm+THx/wqYraEHEXF3VmRXMMxbTkQL5jow2M92GB8/hxESEg59PFXwcGlvk7p0q/UI7jZJN0F7kAgF8xg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2954
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/DGR4b6kJ2hwX8mhvLpPg7sVKUAs>
Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>,
 <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>,
 <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 07:31:05 -0000

--_000_TY2PR01MB4700C38A9557DA97E025421595880TY2PR01MB4700jpnp_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

We(Yahoo! JAPAN) agree with option 2.

Option 1 is not realistic for us as an IdP with thousands of clients becaus=
e it will force them to change implementations.
Also, we already implemented 2 and it was not complicated.

Kazuki Tsuzuku

> On 30 May 2020, at 08:58, Daniel Fett <fett@danielfett.de> wrote:
>
> Hi all,
>
> Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE =
[1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the conclusio=
n that we have two options:
>
> 1. "Static" Solution
>
> For every client_id that is registered with an AS, the AS MUST either alw=
ays enforce the use of PKCE or always enforce the use of nonce. Whether PKC=
E or nonce is enforced can be part of the client registration or configured=
 in other ways.
>
> In other words: A single client is not allowed to switch between using PK=
CE and using nonce.
>
> Note that the client is allowed to use the respective other mechanism on =
top of the enforced one.
>
> Properties:
> Easy to understand mitigation.
> Implementation is mainly a new data field and a check in the authorizatio=
n request.
> Not compatible to deployments where clients sometimes use nonce and somet=
imes use PKCE with the same client_id.
> 2. "Dynamic" Solution
>
> Each AS that supports PKCE MUST check whether a code challenge is contain=
ed in the authorization request. This information MUST be bound to the code=
 that is issued.
>
> When a code arrives at the token endpoint, the AS MUST do the following c=
heck:
>
> If there was a code_challenge in the authorization request for which this=
 code was issued, there must be a code_verifier in the token request and it=
 must be verified according to RFC7636. (This is no change from the current=
 behavior in RFC7636.)
> If there was no code_challenge in the authorization request, any request =
to the token endpoint containing a code_verifier MUST be rejected.
> Properties:
>
> No change in behavior needed for properly implemented clients. Backwards =
compatible for all existing deployments.
> Implementation is mainly some logic for the authorization endpoint, token=
 endpoint, and a new data field in the authorization session maintained by =
the AS.
> Slightly more complex to implement for the AS, maybe.
> We would like to hear the feedback from the working group on these two so=
lutions before proceeding to propose wording for the affected documents.
>
> [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ <ht=
tps://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/>
>
> -Daniel
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--_000_TY2PR01MB4700C38A9557DA97E025421595880TY2PR01MB4700jpnp_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-2022-=
jp">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
We(Yahoo! JAPAN) agree with option 2.<br>
</div>
<div>
<div style=3D"font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12p=
t; color:rgb(0,0,0)">
<span><br>
</span>
<div>Option 1 is not realistic for us as an IdP with thousands of clients b=
ecause it will force them to change implementations.<br>
</div>
<span>Also, we already implemented 2 and it was not complicated.</span><br>
</div>
<div style=3D"font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12p=
t; color:rgb(0,0,0)">
<span><br>
</span></div>
<div style=3D"font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12p=
t; color:rgb(0,0,0)">
<span>Kazuki Tsuzuku</span></div>
<div style=3D"font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12p=
t; color:rgb(0,0,0)">
<span><br>
</span></div>
<div style=3D"font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12p=
t; color:rgb(0,0,0)">
<span>&gt; On 30 May 2020, at 08:58, Daniel Fett &lt;fett@danielfett.de&gt;=
 wrote:<br>
</span>
<div>&gt; <br>
</div>
<div>&gt; Hi all,<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; Aaron, Dick, Torsten and I today discussed the downgrade attacks =
on PKCE [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the c=
onclusion that we have two options:<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; 1. &quot;Static&quot; Solution<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; For every client_id that is registered with an AS, the AS MUST ei=
ther always enforce the use of PKCE or always enforce the use of nonce. Whe=
ther PKCE or nonce is enforced can be part of the client registration or co=
nfigured in other ways.<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; In other words: A single client is not allowed to switch between =
using PKCE and using nonce.<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; Note that the client is allowed to use the respective other mecha=
nism on top of the enforced one.<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; Properties:<br>
</div>
<div>&gt; Easy to understand mitigation.<br>
</div>
<div>&gt; Implementation is mainly a new data field and a check in the auth=
orization request.<br>
</div>
<div>&gt; Not compatible to deployments where clients sometimes use nonce a=
nd sometimes use PKCE with the same client_id.
<br>
</div>
<div>&gt; 2. &quot;Dynamic&quot; Solution<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; Each AS that supports PKCE MUST check whether a code challenge is=
 contained in the authorization request. This information MUST be bound to =
the code that is issued.<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; When a code arrives at the token endpoint, the AS MUST do the fol=
lowing check:<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; If there was a code_challenge in the authorization request for wh=
ich this code was issued, there must be a code_verifier in the token reques=
t and it must be verified according to RFC7636. (This is no change from the=
 current behavior in RFC7636.)<br>
</div>
<div>&gt; If there was no code_challenge in the authorization request, any =
request to the token endpoint containing a code_verifier MUST be rejected.<=
br>
</div>
<div>&gt; Properties:<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; No change in behavior needed for properly implemented clients. Ba=
ckwards compatible for all existing deployments.<br>
</div>
<div>&gt; Implementation is mainly some logic for the authorization endpoin=
t, token endpoint, and a new data field in the authorization session mainta=
ined by the AS.<br>
</div>
<div>&gt; Slightly more complex to implement for the AS, maybe.<br>
</div>
<div>&gt; We would like to hear the feedback from the working group on thes=
e two solutions before proceeding to propose wording for the affected docum=
ents.<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-=
not/ &lt;https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/&=
gt;<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; -Daniel<br>
</div>
<div>&gt; <br>
</div>
<div>&gt; _______________________________________________<br>
</div>
<div>&gt; OAuth mailing list<br>
</div>
<div>&gt; OAuth@ietf.org<br>
</div>
<span>&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" id=3D"LP=
NoLP794378">https://www.ietf.org/mailman/listinfo/oauth</a></span><br>
</div>
<div>
<div id=3D"Signature">
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<p style=3D"margin-top: 0px; margin-bottom: 0px;margin-top:0px; margin-bott=
om:0px">
</p>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_TY2PR01MB4700C38A9557DA97E025421595880TY2PR01MB4700jpnp_--