Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

From: Thomas Broyer <[email-masked]>
Date: Wed, 1 Sep 2021 15:58:11 +0200

I agree with you Justin.

While there probably is a need for an errata to this RFC wrt public
clients, it wouldn't be the one proposed here.

Wrt public clients, section 5 states:

   According to this specification, a client's request must contain a
   valid client_id, in the case of a public client, or valid client
   credentials, in the case of a confidential client.

but actually nowhere in the specification is defined how a public client
would pass its client_id in the request.

As an errata, this section should probably be reworded to remove any
mention of public clients.
And then the RFC should possibly be obsoleted with a new one properly
supporting the public clients' use case (and then I would argue just adding
a client_id parameter alongside token and token_type_hint)

As far as the currently proposed change is concerned, there's no point in
accepting as authorization the same access token that would be revoked, as
this would be exactly the same, security-wise, as not having authentication
at all.

On Mon, Aug 23, 2021 at 9:42 PM Justin Richer <[email-masked]> wrote:

> I personally don’t agree with this errata. Token Revocation was never
> meant to act as a protected resource, but rather as a function of the AS.
> The client is known to the AS and so authentication is expected here.
>
>  — Justin
>
> > On Aug 22, 2021, at 5:14 AM, RFC Errata System <
> [email-masked]> wrote:
> >
> > The following errata report has been submitted for RFC7009,
> > "OAuth 2.0 Token Revocation".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6663
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Ashvin Narayanan <[email-masked]>
> >
> > Section: 2.1
> >
> > Original Text
> > -------------
> > The client constructs the request by including the following
> >   parameters using the "application/x-www-form-urlencoded" format in
> >   the HTTP request entity-body:
> >
> >   token   REQUIRED.  The token that the client wants to get revoked.
> >
> >   token_type_hint  OPTIONAL.  A hint about the type of the token
> >           submitted for revocation.  Clients MAY pass this parameter in
> >           order to help the authorization server to optimize the token
> >           lookup.  If the server is unable to locate the token using
> >           the given hint, it MUST extend its search across all of its
> >           supported token types.  An authorization server MAY ignore
> >           this parameter, particularly if it is able to detect the
> >           token type automatically.  This specification defines two
> >           such values:
> >
> >           * access_token: An access token as defined in [RFC6749],
> >             Section 1.4
> >
> >           * refresh_token: A refresh token as defined in [RFC6749],
> >             Section 1.5
> >
> >           Specific implementations, profiles, and extensions of this
> >           specification MAY define other values for this parameter
> >           using the registry defined in Section 4.1.2.
> >
> >   The client also includes its authentication credentials as described
> >   in Section 2.3. of [RFC6749].
> >
> >   For example, a client may request the revocation of a refresh token
> >   with the following request:
> >
> >     POST /revoke HTTP/1.1
> >     Host: server.example.com
> >     Content-Type: application/x-www-form-urlencoded
> >     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
> >
> >     token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token
> >
> >   The authorization server first validates the client credentials (in
> >   case of a confidential client) and then verifies whether the token
> >   was issued to the client making the revocation request.  If this
> >   validation fails, the request is refused and the client is informed
> >   of the error by the authorization server as described below.
> >
> > Corrected Text
> > --------------
> > The client calls the revocation endpoint using an HTTP
> >   POST [RFC7231] request with the following parameters sent as
> >   "application/x-www-form-urlencoded" data in the request body:
> >
> >   token   REQUIRED.  The token that the client wants to get revoked.
> >
> >   token_type_hint  OPTIONAL.  A hint about the type of the token
> >           submitted for revocation.  Clients MAY pass this parameter in
> >           order to help the authorization server to optimize the token
> >           lookup.  If the server is unable to locate the token using
> >           the given hint, it MUST extend its search across all of its
> >           supported token types.  An authorization server MAY ignore
> >           this parameter, particularly if it is able to detect the
> >           token type automatically.  This specification defines two
> >           such values:
> >
> >           * access_token: An access token as defined in [RFC6749],
> >             Section 1.4
> >
> >           * refresh_token: A refresh token as defined in [RFC6749],
> >             Section 1.5
> >
> >           Specific implementations, profiles, and extensions of this
> >           specification MAY define other values for this parameter
> >           using the registry defined in Section 4.1.2.
> >
> >   The client MUST also include in the request, the access token it
> received
> >   from the authorization server. It must do so in the same way as it
> would
> >   when accessing a protected resource, as describe in [RFC6749], Section
> 7.
> >
> >   The following is a non-normative example request in which the client
> uses
> >   its access token to revoke the associated refresh token:
> >
> >     POST /revoke HTTP/1.1
> >     Host: server.example.com
> >     Content-Type: application/x-www-form-urlencoded
> >     Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW
> >
> >     token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token
> >
> >   The following is a non-normative example request in which the client
> uses
> >   its access token to revoke the same access token:
> >
> >     POST /revoke HTTP/1.1
> >     Host: server.example.com
> >     Content-Type: application/x-www-form-urlencoded
> >     Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW
> >
> >     token=czZCaGRSa3F0MzpnWDFmQmF0M2JW&token_type_hint=access_token
> >
> >   The authorization server MUST validate the access token used by the
>
> >   client to authorize its call to the revocation endpoint, including
> >   ensuring that it is not expired or revoked.
> >   Additionally, the authorization server MUST also validate whether the
> >   access token used for authorization is part of the same grant  as the
> >   token being revoked. If validation fails, the request is  refused and
> >   the client is informed of the error by the authorization server.
> >   In the case of a bearer token, the authorization server SHOULD
> respond
> >   with an HTTP 401 code as described in OAuth 2.0 Bearer Token Usage
> >   [RFC6750], Section 3.
> >   Errors based on other types of tokens are beyond the scope of this
> >   specification.
> >
> >
> > Notes
> > -----
> > It appears as though the authors of RFC7009 have failed to consider that
> requests to revoke are likely to come from non-confidential clients and
> such, would lack authentication credentials. Regardless of the type of
> client however, authentication should not be required. The OAuth 2.0
> specification (RFC6749) does not specify verifying that the access token
> belongs to the client accessing protected resources, of which revocation is
> one. It is the role of the access token alone to signify authorization
> required to make requests to protected resources. If this is an issue for
> revocation, then it is an issue for all protected resources and counter
> measures may be proposed in a separate RFC rather than broadening the scope
> of this particular RFC. As per the original text itself, "This
> specification in general does not intend to provide countermeasures against
> token theft and abuse." Additionally, "If an attacker is able to
> successfully guess a public client's client_id and one of their tok
> > ens, or a private client's credentials and one of their tokens, they
> could do much worse damage by using the token elsewhere than by revoking
> it.  If they chose to revoke the token, the legitimate client will lose its
> authorization grant and will need to prompt the user again.  No further
> damage is done and the guessed token is now worthless."
> > Note that the client_id is not meant to be private information to begin
> with, so relying on an attacker "guessing" it should not be seen as a
> security countermeasure. This section of RFC7009 will be referenced in a
> subsequent errata.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC7009 (draft-ietf-oauth-revocation-11)
> > --------------------------------------
> > Title               : OAuth 2.0 Token Revocation
> > Publication Date    : August 2013
> > Author(s)           : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu
> > Category            : PROPOSED STANDARD
> > Source              : Web Authorization Protocol
> > Area                : Security
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

---

From: Ash Narayanan <[email-masked]>
Date: Thu, 2 Sep 2021 09:08:57 +1000

Hi Thomas,

The approach you've suggested sounds good. Passing just the client_id along
with the token and type (regardless of client type) would be consistent
with how refresh_token requests are structured. As long as the new RFC
obsoletes this one.

Ash

---

From: Warren Parad <[email-masked]>
Date: Thu, 2 Sep 2021 08:41:46 +0200

What's the point in passing arbitrary other information that is already
known by the AS and does not provide the level of security necessary to
prevent abuse of the revocation endpoint?

On Thu, Sep 2, 2021, 01:12 Ash Narayanan <[email-masked]> wrote:

> Hi Thomas,
>
> The approach you've suggested sounds good. Passing just the client_id
> along with the token and type (regardless of client type) would be
> consistent with how refresh_token requests are structured. As long as the
> new RFC obsoletes this one.
>
> Ash

---

From: Ash Narayanan <[email-masked]>
Date: Thu, 2 Sep 2021 16:52:22 +1000

Hi Warren,

If you are referring to the client_id as arbitrary information, then the
same would also be true for refresh requests to the token endpoint from
public clients.  As per 6749, you need to pass the client_id along with the
refresh token. The client_id adds no additional security.

But really, the whole point I've been trying to make from the start is that
the token itself should be the only form of 'security' needed...as that's
the point of OAuth.

Regardless, 7009 needs to be made obsolete by a newer RFC.

Ash

---

From: Warren Parad <[email-masked]>
Date: Thu, 2 Sep 2021 09:16:26 +0200

Great, then let's fix 6749 not this one. The client_id isn't necessary.

And then wouldn't 7009 not need to be changed because it already says you
don't need to pass any authorization for public clients?

For credentialled client issued grants, refresh tokens, and access tokens,
these must not be able to be revoked without client credentials, so using
the refresh token or access token only for all other client types must not
be supported.

On Thu, Sep 2, 2021, 08:52 Ash Narayanan <[email-masked]> wrote:

> But really, the whole point I've been trying to make from the start is
> that the token itself should be the only form of 'security' needed...as
> that's the point of OAuth.
>

---

From: Ash Narayanan <[email-masked]>
Date: Thu, 2 Sep 2021 18:21:31 +1000

Hey Warren,

7009 states that you need to pass just the client_id for public clients, so
if:

> The client_id isn't necessary.
>

Then obviously something about 7009 needs to change.

Whichever angle you look at, 7009 needs to change.

---

From: Warren Parad <[email-masked]>
Date: Thu, 2 Sep 2021 10:22:25 +0200

Can you point out where it says that, I think I must of missed it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan <[email-masked]>
wrote:

> Hey Warren,
>
> 7009 states that you need to pass just the client_id for public clients,
> so if:
>
>> For credentialled client issued grants, refresh tokens, and access
>> tokens, these must not be able to be revoked without client credentials, so
>> using the refresh token or access token only for all other client types
>> must not be supported.
>>

---

From: Ash Narayanan <[email-masked]>
Date: Thu, 2 Sep 2021 18:25:01 +1000

On Thu, Sep 2, 2021 at 6:22 PM Warren Parad <[email-masked]> wrote:

>>> And then wouldn't 7009 not need to be changed because it already says
>>> you don't need to pass any authorization for public clients?
>>>
>>>> If you are referring to the client_id as arbitrary information, then
>>>> the same would also be true for refresh requests to the token endpoint from
>>>>> What's the point in passing arbitrary other information that is
>>>>> already known by the AS and does not provide the level of security
>>>>> necessary to prevent abuse of the revocation endpoint?
>>>>>

---

From: Warren Parad <[email-masked]>
Date: Thu, 2 Sep 2021 10:32:36 +0200

Ah in 5. Security Considerations 👍

Warren Parad

Founder, CTO

On Thu, Sep 2, 2021 at 10:25 AM Ash Narayanan <[email-masked]>
wrote:

>>>>>>> The approach you've suggested sounds good. Passing just the
>>>>>>> client_id along with the token and type (regardless of client type) would
>>>>>>> be consistent with how refresh_token requests are structured. As long as
>>>>>>> the new RFC obsoletes this one.
>>>>>>>
>>>>>>> Ash