Re: [OAUTH-WG] Downgrade attacks on PKCE

Kazuki Tsuzuku <ktsuzuku@yahoo-corp.jp> Wed, 03 June 2020 07:31 UTC

Return-Path: <ktsuzuku@yahoo-corp.jp>
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 3FA8C3A0CB7 for <oauth@ietfa.amsl.com>; Wed, 3 Jun 2020 00:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 (1024-bit key) header.d=yahoo-corp.jp header.b=AKdqzv3t; dkim=pass (1024-bit key) header.d=yjcorp.onmicrosoft.com header.b=S2xU/CrS
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 Yyu0WmINK2em for <oauth@ietfa.amsl.com>; Wed, 3 Jun 2020 00:31:02 -0700 (PDT)
Received: from obrelay01.is.bbt.yahoo.co.jp (obrelay01.is.bbt.yahoo.co.jp [182.22.8.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5883A0CB4 for <oauth@ietf.org>; Wed, 3 Jun 2020 00:31:01 -0700 (PDT)
Received: from corp-ob06.is.ssk.ynwp.yahoo.co.jp (corp-ob06.is.ssk.ynwp.yahoo.co.jp [182.22.89.23]) by obrelay01.is.bbt.yahoo.co.jp (Mailer-Daemon) with ESMTP id 0537Uxa1018531 for <oauth@ietf.org>; Wed, 3 Jun 2020 16:30:59 +0900
Received: from yjwex2drcas02.yjoffice.local (yjwex2casdr02.is.kks.yahoo.co.jp [172.22.63.28]) by corp-ob06.is.ssk.ynwp.yahoo.co.jp (Postfix) with ESMTP id 14EF9120067 for <oauth@ietf.org>; Wed, 3 Jun 2020 16:30:59 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-corp.jp; s=default; t=1591169459; bh=nLBql/djBtu/gEmo1qXKNiMuEmaTiqVU8Q+B2YPh1Zw=; h=From:To:Subject:Date:References:In-Reply-To; b=AKdqzv3tTvRDyl8Gx4P5MVORVvoLYuy+LGv/yCm9B0CbHglbRUVFY3PzBkcTSBIGa XATyqi8WAqLmyQ6b7ari2Gx+/G97hX1V19zHlHNsuU16SkEWMK5o7FjL2NMiAi5F2G EE6C/g9waMab4ZjgmspQur/vjiB0vBhqkpWguH+8=
Received: from yjwex2drmbx01.yjoffice.local (172.22.63.31) by yjwex2drcas02.yjoffice.local (172.22.63.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jun 2020 16:30:58 +0900
Received: from yjwex2drcas01.yjoffice.local (172.22.63.27) by yjwex2drmbx01.yjoffice.local (172.22.63.31) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jun 2020 16:30:58 +0900
Received: from yjwex2edge02.yjoffice.local (103.2.245.142) by yjwex2drcas01.yjoffice.local (172.22.63.26) with Microsoft SMTP Server id 15.0.1473.3 via Frontend Transport; Wed, 3 Jun 2020 16:30:58 +0900
Received: from APC01-HK2-obe.outbound.protection.outlook.com (104.47.124.52) by yjwex2edge02.yahoo-corp.jp (103.2.245.142) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jun 2020 16:29:22 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EmV3kK/oFLo90YJCxXys/gKi+UqDaU9hJFjk9f9v3ka53MQheeHin0cJDu6mZb87EicKp/u7OLJ2UxebQI7wkAS/aeGWbMy+w7Yr6PCgcH2yXcUNH7CC/q4DcfropFrlit9rVt53KlgY+h3LkEaobgonUPyiSXB3QiddRcUKwCXp0yBD1c1qf6/FyjJeoKk6fHN+snwln+dQgGBJBRrbUi1SrB/L/AtiOVd165Sjp1qqM52yL4MbQyESmG+tCt1mtdQBZweHIxlGQgVHHqxwadkEOGa0+2ULI2t+UK4qFzTBv5Fkk8TbpV9RPaxj6JVuK1GTMhagNdpacU8wTNmDWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nLBql/djBtu/gEmo1qXKNiMuEmaTiqVU8Q+B2YPh1Zw=; b=oeqY/hoPuPgLkzUGIBrKnaug9GLTxsS67G19BSCH3ptTiyBQkynIxC3E6ZLCTymQ6eh2lWDHeTlhSP5nfpV5Oow/i1ErnlK1sXUmV03+mG2AaxFewXfh+rQInpbUsDTEeIgmNI8SdMl5LMXG2HTT4TFyNnue1iDpxQqfvnzceapgf6vy7Oter+VznkkBNQBhqfol8BXg9HWvXal5RuZ2nP66ZCHHWJZQNjnC0OhyNgmO5kl9GUXHl5B/1uTQrz54F2/pz8d6tmCqFanCbHrJMo0yh0ephKefDfwIU5pSZYKlfJyEZFbAyIio684L317ovF0k1bHdHb7ikXZ0gW80WA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=yahoo-corp.jp; dmarc=pass action=none header.from=yahoo-corp.jp; dkim=pass header.d=yahoo-corp.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yjcorp.onmicrosoft.com; s=selector1-yjcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nLBql/djBtu/gEmo1qXKNiMuEmaTiqVU8Q+B2YPh1Zw=; b=S2xU/CrS9KeDsILnoWqjP6WIemeJ52Y5h1h+/npHxhUR3sndT7Dyv1Mdi0+venESJB4/Uwxn+j2tJ/i+MUbPFHP111UDlK0crhl5mBlVv27kqtlPz3swWfusHq2qvPTZEzIwRpUHaST5hPbXVhSvilvHjV7etAj2YQkfUmjjdao=
Received: from TY2PR01MB4700.jpnprd01.prod.outlook.com (2603:1096:404:10c::13) by TY2PR01MB2954.jpnprd01.prod.outlook.com (2603:1096:404:74::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.18; Wed, 3 Jun 2020 07:30:56 +0000
Received: from TY2PR01MB4700.jpnprd01.prod.outlook.com ([fe80::fd94:5815:78a0:b1f9]) by TY2PR01MB4700.jpnprd01.prod.outlook.com ([fe80::fd94:5815:78a0:b1f9%6]) with mapi id 15.20.3066.018; Wed, 3 Jun 2020 07:30:56 +0000
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=yahoo-corp.jp;
x-originating-ip: [211.14.29.147]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6fddb812-4922-4920-4113-08d807900e10
x-ms-traffictypediagnostic: TY2PR01MB2954:
x-microsoft-antispam-prvs: <TY2PR01MB2954B9A7117F796105ED0CC495880@TY2PR01MB2954.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04238CD941
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hiVX+yvLrashU0K2q+wTekF0tL7O+IViwVwlqwY0tEX2WAnE3n11THHPQeq93nhFd5Xry9seqCarm3SmtLD7It0GqYAaiZgMvFVA2oUGKKKLbXD6oZhrYMppk9VfMgWsloK+8qG8D8JzpS0VDrFBztxXDiUjQgTFnWx0d40IBhnR0ONlRQeqEENKX4QfjH/Eu7d9Q8v3eBcJs4qeWL6T97jIxnWWDDvHbDw4zWUd5mFdGNNkrWTu5QQoYPcXpfmbymgIRVRkt8cUZWl+G3wWoTEmDTrBG5kbEH9h9cmx1n+yrlSZ4wroCDYIdXarP9SsK6yWWMmlaERxLtU++3/9i7VqbT8S6f1zNGLa3Aj+D+bBzYBTATilCQv7IDnnO97jEio9oYiU/iNEFjsWXlvHWw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TY2PR01MB4700.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(186003)(86362001)(2940100002)(8936002)(55016002)(26005)(966005)(6916009)(316002)(19627405001)(6506007)(7696005)(8676002)(9686003)(53546011)(85182001)(478600001)(66476007)(66556008)(166002)(66446008)(66946007)(71200400001)(33656002)(76116006)(52536014)(83380400001)(64756008)(5660300002)(83080400001)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: CXdC3D18fLjIOGkGXL/HmhhTQcYIE0jobEUIWKb3/C0zfR7o4f8RC6fO7Ns7waCir32CC0UsmhiWX0uMK7+phYjMIGaQgT7xG6d+8cqsbujRDyVrQ5C4HJtGByxmo+SpDfac/oP+z0Hd+k6FOMFd0svG5NJBOQ8TxUpkSV9SLoeLTcGp0fIU6AR4V6it8+UZOMB0WKO9jTQJRRfdhvIIaengWowSwfEcXawogUD1qT4AMK6y+aKv1Re3y3+Fa/fbSDASukRAQBQxBtEFDPQYVesaM/Nt3TH1iRiSAjWheB1pmm5vr2w33Ch7c/ufOEI7rh3Y5a4p60o1H14HUe+y7wGeYzA1nDFpY2AmjFY0FXCCoX7PfU0Y5mX/+i8pEwtWqXSDJS4iQ1JKxHt7ptfDhP4Rf9ySPDfSRPlPqEkTuyTUtEz7+QGaL4UZzT/hS6HIHSGN+lJ3WqhwbjY0BZ7E/T4zKEwizM9IcI3bDnFUmTg=
x-ms-exchange-transport-forked: True
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

We(Yahoo! JAPAN) agree with option 2.

Option 1 is not realistic for us as an IdP with thousands of clients because 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 conclusion that we have two options:
>
> 1. "Static" Solution
>
> For every client_id that is registered with an AS, the AS MUST either always enforce the use of PKCE or always enforce the use of nonce. Whether PKCE 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 PKCE 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 authorization request.
> Not compatible to deployments where clients sometimes use nonce and sometimes use PKCE with the same client_id.
> 2. "Dynamic" Solution
>
> 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.
>
> When a code arrives at the token endpoint, the AS MUST do the following check:
>
> 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 solutions before proceeding to propose wording for the affected documents.
>
> [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ <https://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