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

From: Aaron Parecki <[email-masked]>
Date: Fri, 24 Apr 2020 15:35:59 -0700

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 <[email-masked]> 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" <
> [email-masked] on behalf of [email-masked]> 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
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>