On Fri, 3 Apr 2015, Justin Richer wrote:
> 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?
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
