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

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 11 May 2020 07:53 UTC

Return-Path: <torsten@lodderstedt.net>
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 F34663A08DA for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 00:53:58 -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 (2048-bit key) header.d=lodderstedt.net
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 BZCtrlmp8sJD for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 00:53:57 -0700 (PDT)
Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 F1A053A08D7 for <oauth@ietf.org>; Mon, 11 May 2020 00:53:56 -0700 (PDT)
Received: by mail-wr1-x442.google.com with SMTP id x17so9641396wrt.5 for <oauth@ietf.org>; Mon, 11 May 2020 00:53:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JDGPMgk7vqZbTh+wc4dueEL8iKlktGFAomDjkiaRjTM=; b=S1c1DA1S8OtTTqOMeVKsL8NZw9mA6chwmCmwX55oDkjyyQhMGy56pd9Fczh4pyCdWy Zx9lEbrjzZqchZKVjGq7EoxByvB+qTHn1nEFJn1fEdeTmeaLTHka16u2fgIq47jtwrAm +2L31JfOQ4uO2brIvRuAdoYeQ/QOnPx1V+WVx1BDYLHobLnGrwsrj9izhwWtc9ohN/CU Fmswcuw1Dp8MX6OPk7/rM8Eo7mBGCpOnepqVb4kPr/VGT4sPCFNuZbjDlzYEhxd++hhG ANJz1gm2NB7Wm3fE16eijFH6PSz8ZQYleAS6vGXRyCppQPwLnrtOLiIPSschAsk7TT2M ZWfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JDGPMgk7vqZbTh+wc4dueEL8iKlktGFAomDjkiaRjTM=; b=ItKOf35A05IpSlAuUbrwu/Xv8X+Oe50+NKE6tBtnUnOIivxB1UBC4xnMl3P1c9cGUB EPuViFSQQejJve0RRKUsxrprWon0qKdWrBAkbz90Ncsano2lChzRA5Cd3kcFdpDcMfp5 Pt+yACesKOl4JTitweGVX2ONGFgOTSjIzUHJERKcYJUNS8xPHaUKQv8pG/H0Pr1c6yBM 0w1dazX+O7LhWK4IFYPfLq1HSrIPNM8Y4GXcslkZP+LA6760HkDnlhknyVf6IVcQh6oq rkNJNXhbWou+Xe4HKWrt9lCbIGkaFrZdxHe5gNVUSvvOYoXrAqzeDfJgEyGBa1m0EUv4 UDDg==
X-Gm-Message-State: AGi0PuaiXYTVBmaEa6upuX4RGAgBHK8yNhXKNThNYSCQOD2ZcY76FAd9 MPsmh5RZZ5kOWkQ0Mpx1gM1NKA==
X-Google-Smtp-Source: APiQypLX8LSkx0OkmG+3cLXOg+FO6qsQjJ21Txlv+kCI7RG/8TM+d3bY064xEqFLOLrXrNTlh23B3Q==
X-Received: by 2002:a5d:49ca:: with SMTP id t10mr9850168wrs.285.1589183635423; Mon, 11 May 2020 00:53:55 -0700 (PDT)
Received: from p200300eb8f301f67ddbc8b7d2a3ed8c7.dip0.t-ipconnect.de (p200300EB8F301F67DDBC8B7D2A3ED8C7.dip0.t-ipconnect.de. [2003:eb:8f30:1f67:ddbc:8b7d:2a3e:d8c7]) by smtp.gmail.com with ESMTPSA id w9sm17391178wrc.27.2020.05.11.00.53.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 00:53:54 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <C67BAADA-5037-4AB2-998A-D86237DB83B1@forgerock.com>
Date: Mon, 11 May 2020 09:53:53 +0200
Cc: Dick Hardt <dick.hardt@gmail.com>, Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8EAF68CC-0094-4BAA-BA47-2A69CD2D3D8A@lodderstedt.net>
References: <D2736980-D345-451C-89E9-2FFA5B5512F4@lodderstedt.net> <C67BAADA-5037-4AB2-998A-D86237DB83B1@forgerock.com>
To: Neil Madden <neil.madden@forgerock.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/eP-Cm_fE_yZNxq5C7fR4Ehh4TP8>
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:53:59 -0000


> 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.

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. 

> 
> Neil