Re: [OAUTH-WG] First Draft of OAuth 2.1

Aaron Parecki <aaron@parecki.com> Fri, 24 April 2020 22:36 UTC

Return-Path: <aaron@parecki.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 B29843A0E58 for <oauth@ietfa.amsl.com>; Fri, 24 Apr 2020 15:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.655
X-Spam-Level:
X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, 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=parecki-com.20150623.gappssmtp.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 XoAhudvEieCm for <oauth@ietfa.amsl.com>; Fri, 24 Apr 2020 15:36:14 -0700 (PDT)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 E23AD3A0E51 for <oauth@ietf.org>; Fri, 24 Apr 2020 15:36:13 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id m5so2584481ilj.10 for <oauth@ietf.org>; Fri, 24 Apr 2020 15:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YH8TsPqHQOKE/P67OMzlpvHJJuWFaa+0xhRP2Nt8pRg=; b=SaomwN1ICdHzYBpzMSm+TZ+E9zVPcWXBlin6hQj/imbVDnUsFZgf0KeMQwLrgN8R9u YbDG5H1LojNzYF7huQHoI7ijFIoJXfbaXzv0nIr0MWgG8jLNJV5+VF07sWt4ooIz+inv RJvbp3Xx6yeeEk0dveaVHxzIXPYnM8lzu4oYfWawlDGj6rtETuCa6hS+/FKoJw8aBklO +vQY+1eZm3v4YMRhfFrWG/xBJx5xug81pI7lqaVzjMTnwo75WHbBngVwjd4XrKLzBbuW Za3ihML65lvSC9KhJq1xGOhlZXhxZwxqEobCOn/tc3t7vSCDI1uJDZD2ooVXaVkN5xA6 K4xw==
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=YH8TsPqHQOKE/P67OMzlpvHJJuWFaa+0xhRP2Nt8pRg=; b=Io9iO404Kr2M4Z/anC6QOykWHb1xDeRg8pCHcmbhXh5VbdrdneA9vZWVBjww5qL5xq J7SVqB951jk5pkrw/wnfw0vuu71R2hvp4s1AZ141QsnUO1SFpz6q+8JDRMJ99j0pT5ej XghdnwpQC4NqN+7hgtnbYVHakIGqFg+FVPnqWBHJRDFxRlZkOaSLw3yf0PtfMNYUAruP d1bCiSsrZK4i4sro8JupJMVhgSsUWP6YAvKCg0lxtQITR2jwzp+LvMO1x2l50tkvmfOI 5SmUugUeS2Th10Iv4If0A9yR4oslfHdfcBYa4VUW7wp2bFbBgZtunyxQmqjcPTmoKGpI ePVg==
X-Gm-Message-State: AGi0PuZhmFDLHswQDxBpaoN58+BasvCtupMmKc1rqCVH9VXMpar1NUkp Mc8GPJQ7qwNCF4fo7wR19K8Qts3BREI=
X-Google-Smtp-Source: APiQypIO7ILazaSsLdY4yRVc5qdVKtXAEYgJ3FZtnv2aW06eXWCD06gc5upkwrHTCKyVQY7UCGLtMQ==
X-Received: by 2002:a92:1b91:: with SMTP id f17mr10895320ill.142.1587767772329; Fri, 24 Apr 2020 15:36:12 -0700 (PDT)
Received: from mail-il1-f171.google.com (mail-il1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id k11sm2268990iom.43.2020.04.24.15.36.11 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Apr 2020 15:36:11 -0700 (PDT)
Received: by mail-il1-f171.google.com with SMTP id u189so10847466ilc.4 for <oauth@ietf.org>; Fri, 24 Apr 2020 15:36:11 -0700 (PDT)
X-Received: by 2002:a92:ddca:: with SMTP id d10mr4277456ilr.166.1587767770826; Fri, 24 Apr 2020 15:36:10 -0700 (PDT)
MIME-Version: 1.0
References: <355609CC-D224-4437-9735-E8B603A4FE3A@mitre.org>
In-Reply-To: <355609CC-D224-4437-9735-E8B603A4FE3A@mitre.org>
From: Aaron Parecki <aaron@parecki.com>
Date: Fri, 24 Apr 2020 15:35:59 -0700
X-Gmail-Original-Message-ID: <CAGBSGjqY5PmScp+J4e25NmFE5eMbfgde77KpDrwxMPF-x7xD8w@mail.gmail.com>
Message-ID: <CAGBSGjqY5PmScp+J4e25NmFE5eMbfgde77KpDrwxMPF-x7xD8w@mail.gmail.com>
To: "Peck, Michael A" <mpeck@mitre.org>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f74e5105a410fd5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gdpNmbTMEq8OxW880KYMJuxqeL4>
Subject: Re: [OAUTH-WG] First Draft of OAuth 2.1
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: Fri, 24 Apr 2020 22:36:20 -0000

Thanks for the review, Mike. I've fixed the minor typos. Some other notes
below.

Section 3.1.2.1 currently retains this language from RFC 6749: “The
> redirection endpoint SHOULD require the use of TLS… This specification does
> not mandate the use of TLS because at the time of this writing, requiring
> clients to deploy TLS is a significant hurdle…”
> I suggest updating this text to mandate TLS, and/or a blanket statement
> should be made that TLS is required for all protocol interactions (rather
> than or in addition to the statements throughout the draft). I don't think
> "requiring clients to deploy TLS is a significant hurdle" is an accurate
> statement at the present time.


For now I've removed the "significant hurdle" sentence, since it's only a
minor hurdle these days. Whether we should/can require TLS on redirect URLs
is an interesting question and warrants some discussion. I'll bring this up
at the next meeting.

Section 1.7:
> Consider incorporating new guidance on HTTP redirects as specified in
> draft-ietf-oauth-security-topics section 4.10.


Thank you, good catch. I've updated the sentence in 1.7 to match the
security BCP disallowing HTTP 307, and added the details from section 4.10
later in the document.

Section 2.1:
> “Authorization servers SHOULD consider the level of confidence in a
> client’s identity when deciding whether they allow such a client access to
> more critical functions, such as the client credentials grant type.”
> The client credentials example possibly conflicts with the section 4.2
> statement “The client credentials grant MUST only be used by confidential
> clients” and the statement earlier in section 2.1 “Clients requiring a
> higher level of confidence…use credentials to authenticate with the
> authorization server.”


Others can correct me if I'm wrong, but I feel like this text is okay,
since the use of a client secret doesn't necessarily correlate with
confidence in client identity. For example if a client uses dynamic client
registration to get a client ID and secret, the AS doesn't really have any
assurance of that client's identity if the registration request was made
without authentication itself.

Section 2.3.1:
> (This text is in RFC 6749 too)
> client_secret – “REQUIRED…The client MAY omit the parameter if the client
> secret is an empty string.”
> Since this section describes authentication using a password by
> confidential clients, it doesn’t make sense that the client secret would be
> an empty string?


I agree this doesn't make much sense, I will take out "The client MAY omit
the parameter if the client secret is an empty string." unless there are
any objections.

Section 2.3.2:
> “MAY support any suitable HTTP authentication scheme” – should the word
> “HTTP” be removed as being too specific? I don’t think methods such as mTLS
> and private_key_jwt are HTTP authentication schemes?


Agreed, removing "HTTP" sounds better.

Section 3.1.2.2:
> “The authorization server SHOULD require the client to provide the
> complete redirection URI” -
> Given the section 3.1.2 requirement to compare redirect URIs using “simple
> string comparison”, should that instead be a MUST?


Yes, thanks, with the requirement of exact redirect URI matching this is
required.

Section 3.1.2.3:
> Consider removing the second paragraph, it looks redundant given the new
> section 3.1.2 requirement for “simple string comparison”.


Agreed, it looks like this section refers to things that would only be
possible with partial redirect URI registration/matching.

Section 3.2.1:
> “an unauthenticated client MUST sent its “client_id”…[t]his protects the
> client from substitution of the authentication code.”:
> “authentication code” should be “authorization code” (typo also present in
> RFC 6749), also I don’t think this is true anymore with the requirement to
> use PKCE? However it’s probably still a good requirement, since explicitly
> identifying the client may make it easier for the AS to look up whether the
> authorization code is valid?


We don't want to change the behavior from OAuth 2.0 here, so whether the
client_id parameter is required shouldn't change, but I can remove the
language about authorization code substitution because PKCE is a better
solution. In fact, this whole paragraph is redundant, since the access
token request already requires public clients send the client_id parameter
and PKCE protects against authorization code substitution.

Section 4.1:
> “The client includes its … requested scope, local state …” Consider
> indicating that requested scope and local state are optional?


Sure, thanks.

Section 4.1.1.1:
> (I guess this is more of an RFC 7636 question since the text comes from
> there.)
> Why is the entropy requirement for the PKCE code verifier only SHOULD /
> RECOMMENDED rather than MUST?


Good question. Is this worth bringing up in the context of the Security BCP
as well?


----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>



On Thu, Mar 12, 2020 at 7:00 AM Peck, Michael A <mpeck@mitre.org> wrote:

> This looks like a great initial draft, and I hope to see it move forward.
>
> Some comments so far:
>
> Section 1.6:
> “At the time of this writing” is duplicated.
>
> Section 3.1.2.1 (and possibly other sections such as 1.6 / 2.3.1 / 3.1 /
> 3.2 that mandate TLS):
> Section 3.1.2.1 currently retains this language from RFC 6749: “The
> redirection endpoint SHOULD require the use of TLS… This specification does
> not mandate the use of TLS because at the time of this writing, requiring
> clients to deploy TLS is a significant hurdle…”
> I suggest updating this text to mandate TLS, and/or a blanket statement
> should be made that TLS is required for all protocol interactions (rather
> than or in addition to the statements throughout the draft). I don't think
> "requiring clients to deploy TLS is a significant hurdle" is an accurate
> statement at the present time.
>
> Section 1.7:
> Consider incorporating new guidance on HTTP redirects as specified in
> draft-ietf-oauth-security-topics section 4.10.
>
> Section 1.8 / 2 / 3.1 / 3.2:
> Consider including informative references to RFC 7591 (Dynamic Client
> Registration) and RFC 8414 (OAuth 2.0 Authorization Server Metadata) as
> optional methods that may be useful for client registration, determining AS
> capabilities, and endpoint discovery.
>
> Section 2.1:
> “Authorization servers SHOULD consider the level of confidence in a
> client’s identity when deciding whether they allow such a client access to
> more critical functions, such as the client credentials grant type.”
> The client credentials example possibly conflicts with the section 4.2
> statement “The client credentials grant MUST only be used by confidential
> clients” and the statement earlier in section 2.1 “Clients requiring a
> higher level of confidence…use credentials to authenticate with the
> authorization server.”
>
> Section 2.3.1:
> (This text is in RFC 6749 too)
> client_secret – “REQUIRED…The client MAY omit the parameter if the client
> secret is an empty string.”
> Since this section describes authentication using a password by
> confidential clients, it doesn’t make sense that the client secret would be
> an empty string?
> (Certainly there may be situations where a client_id but not a
> client_secret would be sent – e.g. public clients, or if the client
> authenticates another way --  but that’d be out of scope of what section
> 2.3.1 is describing?)
>
> Section 2.3.2:
> “MAY support any suitable HTTP authentication scheme” – should the word
> “HTTP” be removed as being too specific? I don’t think methods such as mTLS
> and private_key_jwt are HTTP authentication schemes?
>
> Section 3.1.2.2:
> “The authorization server SHOULD require the client to provide the
> complete redirection URI” -
> Given the section 3.1.2 requirement to compare redirect URIs using “simple
> string comparison”, should that instead be a MUST?
>
> Section 3.1.2.3:
> Consider removing the second paragraph, it looks redundant given the new
> section 3.1.2 requirement for “simple string comparison”.
>
> Section 3.2.1:
> “an unauthenticated client MUST sent its “client_id”…[t]his protects the
> client from substitution of the authentication code.”:
>
> “authentication code” should be “authorization code” (typo also present in
> RFC 6749), also I don’t think this is true anymore with the requirement to
> use PKCE? However it’s probably still a good requirement, since explicitly
> identifying the client may make it easier for the AS to look up whether the
> authorization code is valid?
>
> Section 4.1:
> “The client includes its … requested scope, local state …” Consider
> indicating that requested scope and local state are optional?
>
> Section 4.1.1.1:
> (I guess this is more of an RFC 7636 question since the text comes from
> there.)
> Why is the entropy requirement for the PKCE code verifier only SHOULD /
> RECOMMENDED rather than MUST?
>
> Section 9.7:
> (Already pointed out by Pieter this morning.)
> Typo: RFC8418 should be RFC8414.
>
> Thanks,
> Mike
>
> On 3/11/20, 8:29 PM, "OAuth on behalf of Aaron Parecki" <
> oauth-bounces@ietf.org on behalf of aaron@parecki.com> wrote:
>
>     I'm happy to share that Dick and Torsten and I have published a first
>     draft of OAuth 2.1. We've taken the feedback from the discussions on
>     the list and incorporated that into the draft.
>
>     https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
>
>     A summary of the differences between this draft and OAuth 2.0 can be
>     found in section 12, and I've copied them here below.
>
>     > This draft consolidates the functionality in OAuth 2.0 (RFC6749),
>     > OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
>     > (RFC7636), OAuth 2.0 for Browser-Based Apps
>     > (I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
>     > Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
>     > (RFC6750).
>     >
>     >   Where a later draft updates or obsoletes functionality found in the
>     >   original [RFC6749], that functionality in this draft is updated
> with
>     >   the normative changes described in a later draft, or removed
>     >   entirely.
>     >
>     >   A non-normative list of changes from OAuth 2.0 is listed below:
>     >
>     >   *  The authorization code grant is extended with the functionality
>     >      from PKCE ([RFC7636]) such that the only method of using the
>     >      authorization code grant according to this specification
> requires
>     >      the addition of the PKCE mechanism
>     >
>     >   *  Redirect URIs must be compared using exact string matching as
> per
>     >      Section 4.1.3 of [I-D.ietf-oauth-security-topics]
>     >
>     >   *  The Implicit grant ("response_type=token") is omitted from this
>     >      specification as per Section 2.1.2 of
>     >      [I-D.ietf-oauth-security-topics]
>     >
>     >   *  The Resource Owner Password Credentials grant is omitted from
> this
>     >      specification as per Section 2.4 of
>     >      [I-D.ietf-oauth-security-topics]
>     >
>     >   *  Bearer token usage omits the use of bearer tokens in the query
>     >      string of URIs as per Section 4.3.2 of
>     >      [I-D.ietf-oauth-security-topics]
>     >
>     >   *  Refresh tokens must either be sender-constrained or one-time use
>     >      as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]
>
>     https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
>
>     I'm excited for the direction this is taking, and it has been a
>     pleasure working with Dick and Torsten on this so far. My hope is that
>     this first draft can serve as a good starting point for our future
>     discussions!
>
>     ----
>     Aaron Parecki
>     aaronparecki.com
>     @aaronpk
>
>     P.S. This notice was also posted at
>     https://aaronparecki.com/2020/03/11/14/oauth-2-1
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>