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

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 10 May 2020 10:17 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 D8AA33A0876 for <oauth@ietfa.amsl.com>; Sun, 10 May 2020 03:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_FONT_LOW_CONTRAST=0.001, 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 (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 n0d0BZlUoUsx for <oauth@ietfa.amsl.com>; Sun, 10 May 2020 03:17:26 -0700 (PDT)
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 752543A0872 for <oauth@ietf.org>; Sun, 10 May 2020 03:17:25 -0700 (PDT)
Received: by mail-ua1-x932.google.com with SMTP id r2so2314848uam.7 for <oauth@ietf.org>; Sun, 10 May 2020 03:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3TOqKFn0vPZIRA1iCkBbD8DhGVOSJjLRbmNVi/WC88E=; b=NGV7Exu8YVyvjD2ZV2Ym9vIhFENQjwAWOPp7vbTCD8SAuZIB787cAZtvw+nSfkm+zD F13Dut4p/wz1LTjuHE2GLYQZyrH8OLkvHDLIFNHgrI6E7yf99iq2b3KTgufNu+tr44nu fPEuit9DL6fcHGxnBqg7hUE8GhTM+049I/8wt6Kq7VBPJoW1iyQvNXfYTNgwobaFKxo7 kDqri9GLRi6MLtSLU5H41K9+4PnnxkuB11PCX0mlJrnaxcJhf4tkdTlmNBqNHz0WqXCy bMGXEBp95+67jmu25kq/+CHNXu8BKPGhOAizL8jYbsciPDABb5ZmCq1jABKXuceCZv0f JhuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3TOqKFn0vPZIRA1iCkBbD8DhGVOSJjLRbmNVi/WC88E=; b=V0Vvnjclyh8sSSAIi0NE+iwTCr1y5k6REICHK6Z/yaMEVwtW5gRNBkU0VLxK4wtnVN Enq2vYjpgWLcwUEm/V6jPBmPgUSISm6TcvovknY94Dlg3M5nszJ8uZlrnJ+Lq011Fn8H /DMqK1GCOrcQbJhQhFYlJqVf/h1QSKMQx0/VHwBB1OSJFxqxGaq8I/4py2uhQoncOknH ha3hqM33WArtP9R1rwJFpmkcKDd8HvH5No137bqJIxp8TkC6velb/DmzNL1ZMFH+WU4v j1f0ZabXNOV1bFWQlWCHDDt3PFMncn5FhYRhM9qewgQn0/c5GMumML8vU9yooHM0N82s 2tTA==
X-Gm-Message-State: AGi0Puac4aOxLvo8mwhK0WuH0UPHtfrghFR5qswpzKweF130SF2OcAoR Jwrdx1IyNqc9cKKviDCN22nlWunocJkXCkHef5BByQ==
X-Google-Smtp-Source: APiQypIOSJyLY0LXhNVOO4R4YGeAQjHIbasEGKWP5UkBgjGzYvxawACdyYP9MqoN3dRt8o5P0RjgdQZX4S6ccarIw2k=
X-Received: by 2002:ab0:7481:: with SMTP id n1mr7729927uap.89.1589105844295; Sun, 10 May 2020 03:17:24 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR00MB06824211CEC46217264F4F60F5A30@DM6PR00MB0682.namprd00.prod.outlook.com>
In-Reply-To: <DM6PR00MB06824211CEC46217264F4F60F5A30@DM6PR00MB0682.namprd00.prod.outlook.com>
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Sun, 10 May 2020 12:17:13 +0200
Message-ID: <CAHOkhHEdha=od9iZPbeZcM=5pM4toTRznQW0SRZyB4V12L9FeQ@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Aaron Parecki <aaron@parecki.com>, Dick Hardt <dick.hardt@gmail.com>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005c312b05a5488934"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zeMFuxEs7pINxN1gnQrUkXMpspM>
Subject: Re: [OAUTH-WG] 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: Sun, 10 May 2020 10:17:32 -0000

Mike Jones <Michael.Jones@microsoft.com> schrieb am Sa. 9. Mai 2020 um
20:46:

> There’s a huge ecosystem of successful, secure OAuth 2.0 and OpenID
> Connect deployments that we have the responsibility to be stewards of.
> This working group should be proud of what it’s accomplished.  Part of good
> stewardship is not unnecessarily bifurcating the ecosystem into
> non-interoperable segments.  OAuth 2.1 should facilitate the already secure
> OAuth 2.0 deployments remaining part of the interoperable OAuth 2.1 set of
> deployments – not intentionally doing the opposite.
>
>
>
> If it ain’t broke, don’t fix it!
>
Did I got it right that nonce does not protect public clients from code
theft/replay? I would consider this a security issue.

>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki <aaron@parecki.com>
> *Sent:* Friday, May 8, 2020 8:34 PM
> *To:* OAuth WG <oauth@ietf.org>
> *Cc:* Dick Hardt <dick.hardt@gmail.com>om>; Torsten Lodderstedt <
> torsten@lodderstedt.net>gt;; Mike Jones <Michael.Jones@microsoft.com>
> *Subject:* Re: OAuth 2.1 - require PKCE?
>
>
>
> Aaron, I believe you’re trying to optimize the wrong thing.  You’re
> concerned about “the amount of explanation this will take”.  That’s
> optimizing for spec simplicity – a goal that I do understand.  However, by
> writing these few sentences or paragraphs, we’ll make it clear to
> developers that hundreds or thousands of deployed OpenID Connect RPs won’t
> have to change their deployments.  That’s optimizing for interoperability
> and minimizing the burden on developers, which are far more important.
>
>
>
> I appreciate the concern about optimizing for spec simplicity. I also
> agree that spec simplicity should not necessarily be the driving goal.
>
>
>
> However, what you've described is the opposite of interoperability and
> minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without
> any exceptions, will optimize for interoperability between OAuth 2.1
> clients and servers. Without the requirement of PKCE, there will always be
> the question of "but does this OAuth 2.1 client work with this OAuth 2.1
> server or not?", which will only be able to be answered by investigating
> the docs to look for PKCE support, or by checking the AS metadata document
> if it publishes one (which it is not required to do).
>
>
>
> Optimizing for interoperability and minimizing the burden on developers is
> absolutely a good goal, and requiring PKCE is a great way to accomplish
> that. OAuth 2.0 and OpenID Connect implementations that don't support PKCE
> will continue to work as they currently do, they just won't be able to call
> themselves OAuth 2.1 compliant, just as is the case as if they don't follow
> the other recommendations that are in OAuth 2.1 and the Security BCP.
>
>
>
> Aaron
>
>
>
>
>
> On Thu, May 7, 2020 at 6:42 PM Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
> Aaron, I believe you’re trying to optimize the wrong thing.  You’re
> concerned about “the amount of explanation this will take”.  That’s
> optimizing for spec simplicity – a goal that I do understand.  However, by
> writing these few sentences or paragraphs, we’ll make it clear to
> developers that hundreds or thousands of deployed OpenID Connect RPs won’t
> have to change their deployments.  That’s optimizing for interoperability
> and minimizing the burden on developers, which are far more important.
>
>
>
> As Brian Campbell wrote, “They are not equivalent and have very different
> ramifications on interoperability”.
>
>
>
> Even if you’re optimizing for writing, taking a minimally invasive
> protocol change approach will optimize that, overall.  If we proceed as
> you’re suggesting, a huge amount of writing will occur on StackOverflow,
> Medium, SlashDot, blogs, and other developer forums, where confused
> developers will ask “Why do I have to change my deployed code?” with the
> answers being “Despite what the 2.1 spec says, there’s no need to change
> your deployed code.”
>
>
>
> I’d gladly write a few sentences in our new specs now to prevent ongoing
> confusion and interop problems that would otherwise result.  Let me know
> when you’re ready to incorporate them into the spec text.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Aaron Parecki <aaron@parecki.com>
> *Sent:* Thursday, May 7, 2020 4:39 PM
> *To:* Dick Hardt <dick.hardt@gmail.com>
> *Cc:* OAuth WG <oauth@ietf.org>rg>; Torsten Lodderstedt <
> torsten@lodderstedt.net>gt;; Mike Jones <Michael.Jones@microsoft.com>
> *Subject:* Re: OAuth 2.1 - require PKCE?
>
>
>
> Backing up a step or two, there's another point here that I think has been
> missed in these discussions.
>
>
>
> PKCE solves two problems: stolen authorization codes for public clients,
> and authorization code injection for all clients. We've only been talking
> about authorization code injection on the list so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE as
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP for
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> Hello!
>
>
>
> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best
> practice for OAuth 2.0. It is not common in OpenID Connect servers as the
> nonce solves some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence have
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifier
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> ᐧ
>
>