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 <jric...@mit.edu> 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? > > — Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
