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

[Ben Laurie <[e-mail]>]

On 3 April 2015 at 17:57, Justin Richer <[e-mail]> wrote:
> Ben, thanks for the review. Responses to particular points inline.
>
>> On Apr 1, 2015, at 8:29 AM, Ben Laurie <[e-mail]> wrote:
>> Issue: "Configuration Endpoint" (not a security issue)
>>
>> It looks like the definition of this is deferred to
>> draft-ietf-oauth-dyn-reg, but I couldn't find it there either.
>
> I’m confused by this issue: “Client Configuration Endpoint” is defined as a term in §1.2 and its function and use are defined in §2, which is the majority of the spec’s content. I see no use of “configuration endpoint” apart from the full term of “client configuration endpoint” in the current document version.

Sorry about that, I think I just got lost. You appear to be correct.

>> 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?