Hi Ash, my understanding of a errata is when there is something technically wrong with the document. Your point is clear: requiring the client id on the revocation endpoint for public clients does not protect the endpoint is valid. You might say that is a point less to require it and might cause people to assume that the endpoint is protected. but I don't think we can say that is an error as I guess that was already in mind when the spec was created.
On Tue, Aug 31, 2021 at 7:13 AM Ash Narayanan <[email protected]> wrote: > 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 < > [email protected]> wrote: > >> Hi Ash, >> >> Am 31.08.2021 um 02:42 schrieb Ash Narayanan <[email protected]>: >> >> 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 < >> [email protected]> >> >wrote: >> > >> >> On Tue, Aug 24, 2021 at 12:14 PM Warren Parad <[email protected]> >> 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 < >> >>> [email protected]> wrote: >> >>> >> >>>> On Mon, Aug 23, 2021 at 9:42 PM Justin Richer <[email protected]> >> 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 < >> >>>>> [email protected]> 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 <[email protected]> >> >>>>> > >> >>>>> > 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 >> >>>>> > [email protected] >> >>>>> > 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 >> >>>>> [email protected] >> >>>>> 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 >> >>>> [email protected] >> >>>> 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 >> >> [email protected] >> >> 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 >> [email protected] >> >> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1630975362000000&usg=AOvVaw0SBRIZ3JVu9V2FyhP0VRFL >> >> >> _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
