Subject: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 23 May 2013 20:57:34 +0000

Hi,

Section 2.2 (Revocation Response) of draft-ietf-oauth-revocation-09 states:

The authorization server responds with HTTP status code 200 if the
   token has been revoked sucessfully or if the client submitted an
   invalid token.  The content of the response body does not matter as
   all information is conveyed in the response code.

Am I just missing it, or does the draft not define the response code(s)?

Also, it seems a bit strange to return a 200 in response to an invalid token.  200 implies that the request has succeeded, which should not be the case in an error condition (invalid token).

Also (small typo) ... there should be two c's in successfully.

adam

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 24 May 2013 11:07:34 +0100

Hi
On 23/05/13 21:57, Lewis Adam-CAL022 wrote:
> Also, it seems a bit strange to return a 200 in response to an invalid
> token.  200 implies that the request has succeeded, which should not be
> the case in an error condition (invalid token).
>
As far as I recall it was done to prevent the rogue clients from 
figuring out where did they fail; I asked was it something that now 
should apply to other similar cases, but did not get any feedback.

Cheers, Sergey

> Also (small typo) … there should be two c’s in successfully.
>
> adam
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 24 May 2013 13:02:37 +0000

Sergey has the correct interpretation -- it's to prevent a class of oracle attacks. Think of it this way, if you go to revoke a token, and the token wasn't there in the first place, the end result is the same: the token's not there when you're done. So it's a 200 because the result is what you wanted even if the state going in was wrong.

 -- Justin

On May 24, 2013, at 6:07 AM, Sergey Beryozkin <[email-masked]> wrote:

> As far as I recall it was done to prevent the rogue clients from figuring out where did they fail; I asked was it something that now should apply to other similar cases, but did not get any feedback.
> 
> Cheers, Sergey
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 24 May 2013 12:13:04 -0400

> Sergey has the correct interpretation -- it's to prevent a class of oracle attacks.
> Think of it this way, if you go to revoke a token, and the token wasn't there in the
> first place, the end result is the same: the token's not there when you're done. So
> it's a 200 because the result is what you wanted even if the state going in was wrong.

This highlights my point in my AD review:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/

...that this is *not* revocation.  It's invalidation or surrender
(requested by the bearer of the token) -- revocation would be an
action by another party to invalidate a token without the bearer's
involvement.

The usual defense against the sorts of attacks you're talking about is
to make the failure conditions indistinguishable -- not to make
success indistinguishable from failure.  That is, you have two
responses, success and failure, but the failure response doesn't say
why.

What, specifically, is the attack you're trying to defend against
here, any why is this the best approach to that attack?  I can't see
how a "please invalidate this token" request can in any way take
advantage of a "no" response to mount an attack.  It's possible that
there really is a threat here and that this is the right way to handle
it, but I'd like to see that explained.

Barry, Applications AD

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 24 May 2013 16:21:37 +0000

As I recall, the argument was that without this, someone could just keep fishing at the token revocation endpoint for valid tokens. Though thinking about it now, even if you did get a "token was valid" response, the token wouldn't be valid anymore and it wouldn't do you much good. 

It's possible that "invalidation" is a better term for this, but is there an established semantic precedent for this distinction? 

 -- Justin

---

From: Barry Leiba <[email-masked]>
Date: Fri, 24 May 2013 14:07:51 -0400

> As I recall, the argument was that without this, someone could just keep fishing at the
> token revocation endpoint for valid tokens. Though thinking about it now, even if you
> did get a "token was valid" response, the token wouldn't be valid anymore and it wouldn't
> do you much good.

Right, exactly.

> precedent for this distinction?

In English, yes (I don't know about in Computer):

If I walk down to the motor vehicle office, hand them my driver's
license, and say, "Here, take this and destroy it, please.  I don't
need it any more," then I will no longer have a valid driver's
license... but *no one* would say that my license had been "revoked".

If I'm caught driving drunk one too many times, and a judge says,
"Take the bus from now on," and orders my driver's license revoked,
that's a real English-language "revocation".  Note the connotation
that it's imposed on me by another party, not done at my request.

This isn't a huge point, which is why I didn't mark it as a DISCUSS
point, and I won't block the document if it's not changed.  But I
think it *should* be changed, and might cause confusion if it's not,
especially if we ever do set up a true revocation protocol.

Barry