Re: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12

[Justin Richer <[e-mail]>]

On Apr 3, 2015, at 1:26 PM, Ben Laurie <[e-mail]> wrote:
> 
> On 3 April 2015 at 18:22, Justin Richer <[e-mail]> wrote:
>>> 
>>>>> Issue: " 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."
>>>>> 
>>>>> I am not sure what this is getting at. Limits on key re-use? Some kind
>>>>> of BEAST defence? Something else?
>>>>> 
>>>>> Without some quantification of the threat, it seems hard to act on
>>>>> this requirement.
>>>> 
>>>> The rate limiting is going to take a number of different forms depending on the platform and deployment characteristics of the authorization server, so we don’t recommend any particular approach. This is also something that’s going to be changing quickly over the years, and instead of prescribing a specific solution we thought it better to describe the problem here and say that it must be mitigated.
>>> 
>>> Solution to what? This is precisely my issue - you haven't described
>>> the problem, you've described a solution to some problem I'm finding
>>> hard to guess.
>>> 
>>> In other words: how could the registration access token be disclosed
>>> through repeated access attempts?
>> 
>> An attacker could keep poking at a client configuration endpoint with random self-generated tokens until it finds one that works. There’s no oracle attack or other portion that lets the attacker know they’re getting closer to a good token, just a basic repeated hammering of a protected resource This problem is mitigated by having a sufficiently random token (as recommended in RFC6750 and RFC6819) as well as rate-limiting the connections to the endpoint (also suggested by RFC6819). This is fairly common advice for any endpoint protected by a secret (in this case, an OAuth token). Is there a better way to state this so that it’s more clear to developers what they should look out for?
> 
> How about making it a non-problem by requiring sufficiently strong
> tokens that there is no possibility of brute force?
> 
> Mildly astonished that this attack is even considered feasible.

I’m fine with that resolution, or with just deferring to the appropriate sections of 6750 and 6819 here, if the AD’s are amenable to that change.

 — Justin