Subject: Re: [OAUTH-WG] Review of Token Revocation draft

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 25 Dec 2012 14:11:05 +0100

Hi Amanda,

thank you for reviewing the draft. Comments inline.

Am 30.11.2012 22:28, schrieb Anganes, Amanda L:
> Here is my review of the Toke Revocation draft 
> (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>
> Section 1. Introduction
> First paragraph has the following definition in it: "A token is the 
> external representation of an access grant issued by a resource owner 
> to a particular client." This seems a bit odd to me. The OAuth2 spec 
> [1] defines "access token" as "An access token is a string 
> representing an authorization issued to the client." (section 1.4) and 
> "refresh token" as "credentials used to obtain access tokens (section 
> 1.5). Should this spec borrow similar language to be more consistent?
>

What about this:

"A token is a string representing an authorization issued by the 
resource owner to the client. A revocation request will invalidate the 
actual token and, if applicable, other tokens based on the same 
authorization and the authorization itself."

> Paragraph 2 "From an end-user's perception" should be "From an 
> end-user's perspective".

changed it.

>
> Section 2. Token Revocation
> What is the reason for requiring the service provider to detect the 
> token type automatically? For our implementation, Access Tokens, 
> Refresh Tokens, and ID Tokens are all structured tokens (with unique 
> structures across the three types), and as such are stored in 3 
> separate database tables. In order to "detect" the token type, we 
> would need to run a get-by-value query across all three tables, check 
> if any of those queries returned anything, and then proceed to revoke 
> the token (if one was found). This does not seem ideal to me.

As pointed out by Justin, there was such a parameter in an early 
revision of the draft. WG feedback caused me to remove it. I would like 
to stick with auto detection if not otherwise decided by the working 
group. I explicitely asked for feedback on the other thread.

>
> The spec says that "The authorization server first validates the 
> client credentials (in case of a confidential client) and verifies 
> whether the client is authorized to revoke the particular token." What 
> does this verification entail? Does it just mean that 1) the client 
> credentials must validate and 2) the token must belong to the client 
> requesting the revocation? If so I think the text should be clarified 
> to reflect that. Or are you thinking of a case where a client might 
> not be allowed to revoke its own tokens, via some kind of scoping?

It's 1+2

What about this text

"The authorization server first validates the client credentials (in 
case of a confidential client) and then verifies whether the client is 
authorized to revoke the token. A client may only revoke a token if the 
validation of the client identity succeeds and the particular token had 
been issued to this client."

>
> 2.1 Cross Origin Support
> Formatting looks a little off here, otherwise this section looks fine.

What specifically to you mean?

>
> 5. Security Considerations
> Paragraph 3 (Malicious clients...): "Appropriate countermeasures, 
> which should be in place for the token endpoint as well, MUST be 
> applied to the revocation endpoint." These countermeasures should be 
> referenced to the proper section(s) of the OAuth core spec or Threat 
> Model document.

Added reference to section 4.4.1.11 of threat model documemt

>
> Paragraph 4 reads a bit oddly. Suggest following rewording:
> "A malicious client may attempt to guess valid tokens on this endpoint 
> by making revocation requests against potential token strings. 
> 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. The token being 
> revoked must also belong to the requesting client. If an attacker is 
> able to successfully guess a public client's client_id and one of 
> their tokens, 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 and will need to prompt the user 
> again. No further damage is done and the guessed token is now worthless."
>

Adopted your text.

best regards,
Torsten.
> References:
> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>
> -- 
> Amanda Anganes
> Info Sys Engineer, G061
> The MITRE Corporation
> 781-271-3103
> [email-masked]
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Amanda Anganes <[email-masked]>
Date: Thu, 27 Dec 2012 09:22:36 -0500

Hi Torsten,

Responses inline in blue.

On 12/25/2012 08:11 AM, Torsten Lodderstedt wrote:
>> representing an authorization issued to the client." (section 1.4) 
>> and "refresh token" as "credentials used to obtain access tokens 
>> (section 1.5). Should this spec borrow similar language to be more 
>> consistent?
>>
>
> What about this:
>
Yes, that sounds more consistent.
> revision of the draft. WG feedback caused me to remove it. I would 
> like to stick with auto detection if not otherwise decided by the 
> working group. I explicitely asked for feedback on the other thread.
>
>>
>> whether the client is authorized to revoke the particular token." 
>> What does this verification entail? Does it just mean that 1) the 
>> client credentials must validate and 2) the token must belong to the 
>> client requesting the revocation? If so I think the text should be 
>> clarified to reflect that. Or are you thinking of a case where a 
>> client might not be allowed to revoke its own tokens, via some kind 
>> of scoping?
>
> It's 1+2
>
> What about this text
>
> authorized to revoke the token. A client may only revoke a token if 
> the validation of the client identity succeeds and the particular 
> token had been issued to this client."
>
The confusing phrase here is "authorized to revoke the token". If a 
client just needs to be the owner of the token in order to revoke it, I 
would say that:

"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."

Otherwise, the "authorized to revoke the token" language sounds like 
there might be some way to *give* authorization to a particular client, 
as opposed to authorization simply requiring authentication and ownership.
> What specifically to you mean?
The indentation looks strange. Should the example request, successful 
response, and error response be indented? The example request in the 
previous section is indented. Also, should the definition of the 
"callback" parameter say "OPTIONAL." before the definition, or is that 
redundant because the paragraph before indicates "MAY support"? I am not 
sure of the IETF standards for these things; the section just didn't 
look quite right to me.
>> "A malicious client may attempt to guess valid tokens on this 
>> endpoint by making revocation requests against potential token 
>> strings. 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. The token 
>> being revoked must also belong to the requesting client. If an 
>> attacker is able to successfully guess a public client's client_id 
>> and one of their tokens, 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 and will need to prompt 
>> the user again. No further damage is done and the guessed token is 
>> now worthless."
>>
>
> Adopted your text.
>
> best regards,
> Torsten.
>> References:
Thanks,

--Amanda

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 27 Dec 2012 19:28:41 +0100

Hi Amanda,

I incoporated your comments. I'm waiting for feedback on the other 
threads before I will post another revision.

http://www.ietf.org/mail-archive/web/oauth/current/msg10334.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10331.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10335.html

best regards,
Torsten.

Am 27.12.2012 15:22, schrieb Amanda Anganes:
>>> external representation of an access grant issued by a resource 
>>> owner to a particular client." This seems a bit odd to me. The 
>>> OAuth2 spec [1] defines "access token" as "An access token is a 
>>> string representing an authorization issued to the client." (section 
>>> 1.4) and "refresh token" as "credentials used to obtain access 
>>> tokens (section 1.5). Should this spec borrow similar language to be 
>>> more consistent?
>>>
>>
>> What about this:
>>
>> resource owner to the client. A revocation request will invalidate 
>> the actual token and, if applicable, other tokens based on the same 
>>> would need to run a get-by-value query across all three tables, 
>>> check if any of those queries returned anything, and then proceed to 
>>> revoke the token (if one was found). This does not seem ideal to me.
>>
>> case of a confidential client) and then verifies whether the client 
>> is authorized to revoke the token. A client may only revoke a token 
>> if the validation of the client identity succeeds and the particular 
> client just needs to be the owner of the token in order to revoke it, 
> I would say that:
>
> there might be some way to *give* authorization to a particular 
> client, as opposed to authorization simply requiring authentication 
> and ownership.
>>>
>>> 2.1 Cross Origin Support
> redundant because the paragraph before indicates "MAY support"? I am 
> not sure of the IETF standards for these things; the section just 
> didn't look quite right to me.
>>
>>>
>>> and one of their tokens, 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 and will need to 
>>> prompt the user again. No further damage is done and the guessed 
>>> token is now worthless."
>>>
>>
>> Adopted your text.
>>
>> best regards,
>> Torsten.
>>> References: