Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?

Neil Madden <neil.madden@forgerock.com> Mon, 11 May 2020 07:34 UTC

Return-Path: <neil.madden@forgerock.com>
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 9FF513A08B7 for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 00:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=forgerock.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 3Wds1qEiPQEJ for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 00:34:08 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 6414D3A08BE for <oauth@ietf.org>; Mon, 11 May 2020 00:34:08 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id k12so16852220wmj.3 for <oauth@ietf.org>; Mon, 11 May 2020 00:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=8ny3cbRld1CNIj9MXG2R6eKEF42+1B5PUlFKRbZ6c28=; b=dcppsa0YwuE8LldoEYl1P1adVu4UnDkoqvPJybLloiFJj3tXpz/fgagPB20m0m6zzn 4XZF1PW7Pua89kjfc9q/MJ8vpeAwAOkoCPK76biRzt3Si0XwOL9ouThgKV6/qlBsNROq jFVmFKI9CyUaGC8u9INFlwkv3V3hBxXjQ0sHs=
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:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=8ny3cbRld1CNIj9MXG2R6eKEF42+1B5PUlFKRbZ6c28=; b=UQyVmwqKdXJxNcMJ+WkHEHU1jYN7jWfB0XeRbP6kJzEOA4hOyNvXDIHx6L6isSPcIX frZ+AJj16GqSkHwyYxZxEoDpTL+ypC2D2tUOANPK6WRl+gTNDOm87rKM5nV3NE76fYy/ 7Aka2jdTaDSxImv+o0ZO0Mp/KC6LPaCzWbzHKurS4ofTo69QlW+USa8ui+kuLTNgkVSo F73GMKys8OMAvtJfq53nqq4u8Ij+wOsWsn5tio2N3G8Im7NvJeuj/BghkLuJ7N7bae/m LL7G/mx9XVuShRm1qCiAYXwbSfla2Qz9GmNiwcVOv1pcU5Jo5Fx6Qnoj7LbcSkVteGja Sb3Q==
X-Gm-Message-State: AGi0PuboQgDntfo4KYy4/49Cxubu9fUYJhvR1I7hxkeFq2mT9nVxK/88 OjEwcZG2WtylwO4fQzeAMcGimsm6nZ/37kHDo8v9R2/yufUK9SD0duaoMNeLswExHqwHKWD649d TBoWKR4DEb2m8unSnTDcRyEUTjkeP0k0PTEMtYfV2Bzyq365GE4ZcicIbdKMZFoA=
X-Google-Smtp-Source: APiQypJzZn+svWh7Xa+8NyVWjz7FACmhYfynkSNOIQtCIaWKfN/gweFg5hFopcgv8msIkSehNgwdkQ==
X-Received: by 2002:a1c:b60b:: with SMTP id g11mr1939389wmf.49.1589182446014; Mon, 11 May 2020 00:34:06 -0700 (PDT)
Received: from [10.0.0.3] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id f5sm16132614wrp.70.2020.05.11.00.34.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 00:34:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 11 May 2020 08:34:04 +0100
Message-Id: <C67BAADA-5037-4AB2-998A-D86237DB83B1@forgerock.com>
References: <D2736980-D345-451C-89E9-2FFA5B5512F4@lodderstedt.net>
Cc: Dick Hardt <dick.hardt@gmail.com>, Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>
In-Reply-To: <D2736980-D345-451C-89E9-2FFA5B5512F4@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (17E262)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/e3nJHO_7FGU51xcJ2HmDhbqNp_A>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require 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: Mon, 11 May 2020 07:34:13 -0000


> On 11 May 2020, at 08:05, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> 
> 
> 
>>> On 11. May 2020, at 08:47, Neil Madden <neil.madden@forgerock.com> wrote:
>>> 
>>> 
>>> 
>>>> On 11 May 2020, at 07:41, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>> 
>>>> On 11. May 2020, at 07:38, Neil Madden <neil.madden@forgerock.com> wrote:
>>>> 
>>>> There is no attack that this prevents so your claim of improving security is unsubstantiated. I can’t see how we can ship a 2.1-compliant-by-default AS while this requirement remains so I don’t support it. 
>>> 
>>> Are you saying PKCE does not prevent any attack?
>> 
>> No, but servers and clients are already free to support PKCE. I’m saying that rejecting requests from non-PKCE clients doesn’t prevent any attack. It just denies service to legitimate clients. 
> 
> There are two aspects to this topic:
> 
> 1) Do all ASs support PKCE? Requiring PKCE support fosters interoperability and security. Security since the client can be sure the AS supports PKCE. Today, if the AS does not support PKCE, the client will never learn since a compliant AS will just ignore additional request parameters.

But just saying that a 2.1 AS MUST support PKCE is enough for this. Rejecting requests just to support feature discovery is a sledgehammer to crack a nut. 

> 
> 2) Do ASs enforce PKCE? This fosters security since it forces clients to implement a means against code replay and CSRF.
> 

Again, just saying that 2.1 clients MUST support PKCE achieves this aim. Rejecting non-PKCE requests doesn’t add anything to security. 

And as has been pointed out elsewhere in this thread there are clients that don’t benefit from PKCE such as confidential OIDC clients. Indeed for most confidential clients the gains of PKCE are relatively minor - code injection attacks are already pretty hard to pull off in practice against such clients. 

Neil