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

Neil Madden <neil.madden@forgerock.com> Mon, 11 May 2020 08:59 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 2C20D3A09F0 for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 01:59:51 -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=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 GVm2z0dxUOvv for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 01:59:49 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 E8B813A09BC for <oauth@ietf.org>; Mon, 11 May 2020 01:59:43 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id w7so9876929wre.13 for <oauth@ietf.org>; Mon, 11 May 2020 01:59:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lcbHpT6uQQhfYlIkzQ04panXYyynu/hsQWoD/ihWMtM=; b=hmXoTI7g94JYoyniP48dyViJUHoaw1E2PPUsCWRJtSH/xV4qIhiuefUazo0WmIKSpq KLQyOIf3X7ZxCg209x9cJpGodYDue4rAChI+yFssXaJwzxkwTGLrkwS9y8d1qqp0kW2V 8A4DjOGEenDC4z0vCsE8JczQOoiU2XQq6lz6U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lcbHpT6uQQhfYlIkzQ04panXYyynu/hsQWoD/ihWMtM=; b=lBxVnnmAYrJS8ufz8TKjmrrtAPa1Cs9Br8c6/xN41vVfF8YftPucgzL8Hdz1qbL+61 2z/4TnMLlrj1o2QVVDWKo2Ey/DylZPiz4MEkNxvSltfK2JHkaN+yfqimy6cPHGSUtIlS cUYqPfZ3eHDFuWmvpG0MJDzY2099pfTknnlHRmJxBaY5qCZRNCUNgNr3Mb7VMx/ThV3I /cQRMI3unPidcUgo4f+OVTAtDVwVkr6JgqntnM3u/489Hy3f0xfKtLkbiB/cjVE+7xIH OJ9HDXvsfVMLLFVHN9BRoVybOYGr3sOhcae3jW4PC3AseTrRZyZnCyvApM0iXz+N/5oV 3Udw==
X-Gm-Message-State: AGi0PubklRc2GjeQ6Tbg+n2FpeXCFDWZ9hrHymfemhocgSNd/iv4u4W9 mwmzdsmiXLhyjJ3QThsyrOba8w==
X-Google-Smtp-Source: APiQypIjVk8R62MeeLK/x9dJOF6Sqm+2ZTTu99NrEe//YJ1ZfCO7tqDdGtuot6WwUIoEKySDYz9r7Q==
X-Received: by 2002:adf:fa44:: with SMTP id y4mr4923331wrr.135.1589187582147; Mon, 11 May 2020 01:59:42 -0700 (PDT)
Received: from [10.0.0.2] (181.58.93.209.dyn.plus.net. [209.93.58.181]) by smtp.gmail.com with ESMTPSA id 128sm19381045wme.39.2020.05.11.01.59.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 01:59:41 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <02581F0B-F4BC-4EBD-860C-3DAFA631BA40@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C63A8535-4D6E-4D21-8F83-0001088A9B6B"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 11 May 2020 09:59:40 +0100
In-Reply-To: <8EAF68CC-0094-4BAA-BA47-2A69CD2D3D8A@lodderstedt.net>
Cc: Dick Hardt <dick.hardt@gmail.com>, Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
References: <D2736980-D345-451C-89E9-2FFA5B5512F4@lodderstedt.net> <C67BAADA-5037-4AB2-998A-D86237DB83B1@forgerock.com> <8EAF68CC-0094-4BAA-BA47-2A69CD2D3D8A@lodderstedt.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ntHs_p-9jIQDsQA3m_yfmvzBUJM>
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 08:59:56 -0000


> On 11 May 2020, at 08:53, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> 
> 
> 
>> On 11. May 2020, at 09:34, Neil Madden <neil.madden@forgerock.com> wrote:
>> 
>> 
>> 
>>> 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. 
> 
> I agree, but I wouldn’t say they don’t benefit at all. 
> 
> 1) The nonce check happens after the OP had issued the ID Token. This means even if the transaction is being evaluated to be fraudulent afterwards, the OP releases PII to the RP. Depending on the way the OP obtained this data, this might have already caused unneglectable cost (e.g. for an external commercial claims provider).
> 
> That’s not the case with PKCE.

We’re talking about confidential clients. If the ID Token is not meant for this client then client authentication will fail, or else the auth code was meant for this client (but not this session) in which case the user already consented to release of PII to that RP.

If you are talking about a hybrid flow then PKCE doesn’t protect that either. I’d like to see encrypted ID tokens become mandatory in hybrid flows, but that’s not for this WG.

> 
> 2) The whole check relies on the client. I would rather rely on the OP/AS to enforce this security check since clients have a less promising track record of implementing security checks. 
> 
> 3) In mixed OAuth/OIDC scenarios, switching back and force between nonce and PKCE does not make developers live simpler. 

Maybe, but I don’t think either of these rise to the level of mandating that ASes reject non-PKCE requests.

In the interests of building consensus, maybe something along the lines of: “An AS MUST reject requests without a code_challenge from public clients, and SHOULD reject such requests from other clients unless there is reasonable assurance that the client mitigates these threats in other ways”?

— Neil