On 4/3/2015 9:15 PM, Benjamin Kaduk wrote:
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
I think that's a reasonable addition, thanks!
-- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
