Hi Torsten, Thanks for clarifying. The errata system allows for two types of errata, editorial and technical. I selected technical when I submitted this particular one. Things like typos and ambiguities sound like editorial to me, unless I'm mistaken.
I'd be fine with submitting a new RFC so as to not change the security assumptions of this spec, though I'm not sure what then would be the purpose of a technical errata? Cheers, Ash On Tue, Aug 31, 2021 at 5:29 PM Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Hi Ash, > > Am 31.08.2021 um 02:42 schrieb Ash Narayanan <ashvinnaraya...@gmail.com>: > > Hi Dick, > > >The access token represents the authorization to access the resource(s) -- > >it does not represent the authorization to manipulate tokens. > > Anything for which the client must have an access token to access is a > protected resource. In order to revoke a token, the client must have the > associated access token to begin with, hence a protected resource. If not a > protected resource, it is implied anyone can access it, and the OAuth spec > makes no assertions about where a protected resource must be located so > there's no reason it can't be on the AS as well. > > Emond describes it quite neatly: > >> I see it like returning a key when you no longer need access to a > building. > >> The fact that you hold the key should be enough for you to be able to > return it. > > So you shouldn't be returning a key you never had. > > Anything for which you *may* use a client_secret if you have one or not > if you don't is generally a red flag. In RFC 7009 as I've pointed out, the > client_id is being used as a security measure as it's part of the > authentication header. Furthermore, it also mentions an attacker > *guessing* it (in addition to the token). The client_id is by no means a > secure item on a non-confidential client such as an SPA. > > Also you say: > > Changing the spec would change the security assumptions that existing > deployments have made. > > Isn't that the nature of the business? Or are you implying that no > deployment should ever change even if improvements are found? > > > Certainly not. However, an errata is not supposed to change the security > assumptions of a spec. It is supposed to fix typos and clarify ambiguities. > Changing the security assumptions or applying other normative changes is > subject to new RFCs replacing the older ones. > > So from my perspective, your inquiry exceeds the scope of an errata. > > best regards, > Torsten. > > > Ash > > > >Hey Emond > > > >The access token represents the authorization to access the resource(s) -- > >it does not represent the authorization to manipulate tokens. The client > >credentials are used for token management. While your implementation may > be > >ok with using the access token to revoke itself, it is not the security > >model represented by the specification. Changing the spec would change the > >security assumptions that existing deployments have made. > > > >As noted in your response, the CLI has access to the client credentials to > >revoke. Besides convenience, it is not clear to me why you would not want > >to require the client credentials -- but it is your implementation -- you > >can make your own decisions where and if you want to be compliant. > > > >Warren: an interesting idea to provide more context on this in OAuth 2.1. > > > >/Dick > >ᐧ > > > >On Tue, Aug 24, 2021 at 8:10 AM Emond Papegaaij < > emond.papega...@gmail.com> > >wrote: > > > >> On Tue, Aug 24, 2021 at 12:14 PM Warren Parad <wpa...@rhosys.ch> wrote: > >> > >>> I think it is worth pointing out, if we were to agree with the errata, > >>> that this particular use case probably isn't relevant: > >>> > >>> Our client in this case was a command line tool, which only requests > the > >>>> client credentials on login. It then fetches an access token and > stores > >>>> this locally. The client credentials are not stored by default. > >>> > >>> > >>> Unless I misunderstand, I'll take "client credentials" to mean client > Id > >>> and client credentials via a client credentials grant. And therefore, > is > >>> not the correct flow to be used in a command line tool. Client > credentials > >>> are used in private when there are many user agents that could connect > >>> through it, I would not recommend this as the solution here, and even > if it > >>> were, you would indeed have access to the client id and secret, so it > would > >>> not be a problem to use them to revoke the token. > >>> > >> > >> The CLI-tool actually supports both a 3-legged (via the device > >> authorization grant) and a 2-legged flow (via the client credentials > >> grant). It depends on the use case which one is appropriate. In the > case of > >> a user logging in to access the application via the CLI, it clearly is > the > >> 3-legged flow, however when the CLI is used in a script that runs > without > >> user interaction, it's the 2-legged flow. In this later case, the script > >> often fetches the credentials from some store, uses them to acquire an > >> access token, does it job, and revokes the token. Naturally, it can > fetch > >> the credentials a second time to revoke the token, but I really don't > see > >> the point in this case. The client merely indicates it is done with the > >> token and it can now be revoked. It is good practice to discard any > >> credentials when you are done with them to minimize the chance of abuse. > >> However, requiring the client authentication to revoke the token, really > >> complicates this case and will probably lead to scripts not revoking the > >> token. > >> > >> > >>> However, I believe there is something fundamentally broke here, because > >>> there are two use cases which are in conflict with each other: > >>> > >>> - I as a user, at any time want to revoke one of, access token, > >>> refresh token, or granted scopes associated with my identity by > directly > >>> communicating with an AS. I never want to make this request through > a > >>> client, and more specifically, I never want a client to determine > whether > >>> or not I'm allowed to revoke these. > >>> - I as a user, at no time want to allow a client, for whom I did not > >>> give permission to revoke my refresh token nor revoke granted > scopes. It > >>> should not be the case that one client sharing the token with > another > >>> client (either intentionally or accidentally) would be allowed to > change > >>> the requested scopes nor make decisions about the validity of my > current > >>> access token or delegated refresh token. > >>> > >>> Given the latter we see that it must be the case that refresh tokens, > >>> access tokens, and associated grants MUST NOT be allowed to be revoked > >>> without client authentication. This means that the original RFC is > indeed > >>> correct, and that the errata is not. But, this does not enable the > former > >>> case nor encourage a solution that works in scope of retaining control > over > >>> resources that the user agent owns. However, it is worth mentioning > that it > >>> doesn't prevent, as it still allows an AS to implement additional > >>> mechanisms for direct user revocation, if desired. > >>> > >>> That being said I would be in favor of enumerating a *flow* to safely > >>> instruct the AS to revoke directly by the user, but it cannot be done > by > >>> amending the revocation endpoint. > >>> > >> > >> I don't fully understand your statement here. As far as I understand the > >> token revocation endpoint, it is an endpoint specifically for the > client to > >> be used when it no longer needs the token. The client can simply discard > >> the tokens, but it is cleaner to inform the AS about this fact and allow > >> the AS to cleanup its resources as well. It is in no way an endpoint to > be > >> used by the resource owner to revoke access for certain clients. I see > it > >> like returning a key when you no longer need access to a building. The > fact > >> that you hold the key should be enough for you to be able to return it. > >> > >> I do want to point out that the spec for bearer tokens states: "A > security > >> token with the property that any party in possession of the token (a > >> "bearer") can use the token in any way that any other party in > possession > >> of it can." Clients should IMHO not be exchanging tokens with another > party > >> unless they really trust this other party, in which case they should > also > >> trust this party not to revoke the tokens when not agreed upon. If any > >> malicious party would get hold of my tokens, I wish they would only use > >> them to revoke them. A leaked token should be revoked anyway. One could > >> even argue that the grant for the original client should also be > revoked in > >> this case as well, because it is clearly broken. > >> > >> Best regards, > >> Emond Papegaaij > >> > >> > >> > >>> On Tue, Aug 24, 2021 at 9:44 AM Emond Papegaaij < > >>> emond.papega...@gmail.com> wrote: > >>> > >>>> On Mon, Aug 23, 2021 at 9:42 PM Justin Richer <jric...@mit.edu> > 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. > >>>>> > >>>> > >>>> We ran into this very issue some time ago. Our client in this case > was a > >>>> command line tool, which only requests the client credentials on > login. It > >>>> then fetches an access token and stores this locally. The client > >>>> credentials are not stored by default. The current spec required us to > >>>> request the client credentials to revoke the access token on logout. > >>>> Personally, I see no point in requiring the the client to > authenticate, it > >>>> already possesses an access token, which it can use for whatever it > wants > >>>> to and the possession of the token should be enough evidence that the > >>>> client previously authenticated. Revoking the token seems to be the > least > >>>> harmful one can do with a token. > >>>> > >>>> For more information see: > >>>> > https://mailarchive.ietf.org/arch/msg/oauth/7qxGcptE-uzA5WQaxnzGMdSqb2I/ > <https://www.google.com/url?q=https://mailarchive.ietf.org/arch/msg/oauth/7qxGcptE-uzA5WQaxnzGMdSqb2I/&source=gmail-imap&ust=1630975362000000&usg=AOvVaw16H5lxg6EQsUfPTAc_WbWD> > >>>> > >>>> Best regards, > >>>> Emond Papegaaij > >>>> > >>>> > >>>> > >>>>> > On Aug 22, 2021, at 5:14 AM, RFC Errata System < > >>>>> rfc-edi...@rfc-editor.org> 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 > <https://www.google.com/url?q=https://www.rfc-editor.org/errata/eid6663&source=gmail-imap&ust=1630975362000000&usg=AOvVaw3k2vU0wQT8A7wxoLn6lN2Z> > >>>>> > > >>>>> > -------------------------------------- > >>>>> > Type: Technical > >>>>> > Reported by: Ashvin Narayanan <ashvinnaraya...@gmail.com> > >>>>> > > >>>>> > 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 > <https://www.google.com/url?q=http://server.example.com&source=gmail-imap&ust=1630975362000000&usg=AOvVaw0ZzTvU9XBQl1k5eZmHIoYL> > >>>>> > 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 > <https://www.google.com/url?q=http://server.example.com&source=gmail-imap&ust=1630975362000000&usg=AOvVaw0ZzTvU9XBQl1k5eZmHIoYL> > >>>>> > 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 > <https://www.google.com/url?q=http://server.example.com&source=gmail-imap&ust=1630975362000000&usg=AOvVaw0ZzTvU9XBQl1k5eZmHIoYL> > >>>>> > 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 > >>>>> > OAuth@ietf.org > >>>>> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1630975362000000&usg=AOvVaw0SBRIZ3JVu9V2FyhP0VRFL> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1630975362000000&usg=AOvVaw0SBRIZ3JVu9V2FyhP0VRFL> > >>>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1630975362000000&usg=AOvVaw0SBRIZ3JVu9V2FyhP0VRFL> > >>>> > >>> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1630975362000000&usg=AOvVaw0SBRIZ3JVu9V2FyhP0VRFL> > >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1630975362000000&usg=AOvVaw0SBRIZ3JVu9V2FyhP0VRFL > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
