Subject: [OAUTH-WG] Rate limiting in Dyn-Reg-Management

From: Justin Richer <[email-masked]>
Date: Fri, 3 Apr 2015 16:20:33 -0400

In the current draft of Dyn-Reg-Management (https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12 <https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12>) there’s a clause that’s causing some consternation in the general review:

   Since the client configuration endpoint is an OAuth 2.0 protected
   resource, it SHOULD have some rate limiting on failures to prevent
   the registration access token from being disclosed though repeated
   access attempts.

A comment has been raised arguing that this text isn’t helpful to implementors as it doesn’t tell them what kind of rate limiting to do or how to accomplish it. It has also been pointed out that there’s not an obvious need for this recommendation if there’s enough entropy in the registration access token to begin with.

The suggestion has been made to drop the above text, and potentially to add a reference to the sections on token complexity in 6750 §5.2 and 6819 §5.1.4.2.2. My suggested text in that regard is:

Since possession of the registration access token authorizes the holder to potentially read, modify, or delete a client’s registration (including its credentials such as a client_secret), the registration access token MUST contain sufficient entropy such as described in [RFC6750] Section 5.2 and [RFC6819] Section 5.1.4.2.2.

I would add this as the last sentence to the first paragraph in the security considerations section.

What does the WG think of this suggested change?

 — Justin

---

From: John Bradley <[email-masked]>
Date: Fri, 3 Apr 2015 18:55:47 -0300

I am OK with that.  Rate limiting only really helps with denial of service attacks, and that is a separate issue.

In 6750 we were very slippery in avoiding specifying any entropy minimum or structure for the token, given the nature of that applying to any endpoint.

In 6819 we did better by specifying a minimum 128 bits for keys and references.

That would require crushing the internet to do online brute force in any reasonable amount of time or roughly the computing power of Google to do a offline attack against a single token in a year (rough guess).

The one thing we don’t caution against is using the same registration_client_uri for every client.  
If someone is doing that (not unreasonable in some cases) and if they have a large number of clients then they probably should use higher entropy tokens eg 256 bit.

If there are millions of registered clients at a AS hypothetically your chances of getting lucky against one of them are better. 

It is still very unlikely at 128 bits but the attack surface is larger if there is only one resource and you attack all the clients at once.

It may not be worth mentioning however, I know I am the paranoid one.

John B.

> On Apr 3, 2015, at 5:20 PM, Justin Richer <[email-masked]> wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 Apr 2015 21:15:36 -0400 (EDT)

On Fri, 3 Apr 2015, Justin Richer wrote:

> A comment has been raised arguing that this text isn’t helpful to
> implementors as it doesn’t tell them what kind of rate limiting to do or
> how to accomplish it. It has also been pointed out that there’s not an
> obvious need for this recommendation if there’s enough entropy in the
> registration access token to begin with.
>
> The suggestion has been made to drop the above text, and potentially to
> add a reference to the sections on token complexity in 6750 §5.2 and
> 6819 §5.1.4.2.2. My suggested text in that regard is:
>
> Since possession of the registration access token authorizes the holder
> to potentially read, modify, or delete a client’s registration
> (including its credentials such as a client_secret), the registration
> access token MUST contain sufficient entropy such as described in
> [RFC6750] Section 5.2 and [RFC6819] Section 5.1.4.2.2.
>

I think it's a fine change, in general.  But I also saw the discussion on
the other list, so maybe I'm biased.

In specific, RFC 6750 does not include the word "entropy", and we might
want to explicitly mention that "sufficient" means "sufficient to prevent
a random guessing attack".

-Ben

---

From: Justin Richer <[email-masked]>
Date: Sat, 04 Apr 2015 07:14:30 -0400

> a random guessing attack".

I think that's a reasonable addition, thanks!

  -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 07 Apr 2015 11:58:00 +0100

Hi

Would it be correct to assume that the best method for encoding the 
auto-generated bearer tokens is Base64URL ? I've spotted recently some 
of our code uses the Hex encoding which I believe is inferior compared 
to Base64URL given that the latter has a richer set of characters.

Is it a correct assumption ?

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Tue, 7 Apr 2015 06:09:15 -0700

Best would depend on what you are encoding.  If the thing you are encoding is mostly URL safe then using URL escaping might give you the smallest result. 
If it is 8bit data then BASE64URL will give you a smaller result than HEX encoding.

JWT use BASE64URL as a datapoint.

John B.
> On Apr 7, 2015, at 3:58 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi
> 
> Would it be correct to assume that the best method for encoding the auto-generated bearer tokens is Base64URL ? I've spotted recently some of our code uses the Hex encoding which I believe is inferior compared to Base64URL given that the latter has a richer set of characters.
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 07 Apr 2015 14:19:45 +0100

Hi John

Thanks for the comments, what I'm curious about is not how to get a 
generated (bearer) access token encoded with the encoded value having a 
fewer number of characters but how to better support a security 
requirement that it should be difficult for an attacker to reproduce a 
given access token value...

So I've been wondering if the fact that Base64(URL) has a richer set of 
characters than HEX makes it a better alternative...Not 100% sure how 
important it can be...

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Tue, 7 Apr 2015 06:36:00 -0700

How difficult it is to brute force the token has to do with the underlying entropy.   For opaque access tokens the specs recommend 128bits of entropy.   How you encode that is not relevant to the security.

> On Apr 7, 2015, at 6:19 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi John
> 
> Thanks for the comments, what I'm curious about is not how to get a generated (bearer) access token encoded with the encoded value having a fewer number of characters but how to better support a security requirement that it should be difficult for an attacker to reproduce a given access token value...
> 
> So I've been wondering if the fact that Base64(URL) has a richer set of characters than HEX makes it a better alternative...Not 100% sure how important it can be...
> 
> Thanks, Sergey
>