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

[Ben Laurie <[e-mail]>]

On 6 April 2015 at 21:14, Justin Richer <[e-mail]> wrote:
> Ben et. al.,
>
> I took the proposal to the WG and have changed the draft text based on their
> feedback. The results are published here:
>
>   http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-13

Looks good.

>
>  — Justin
>
> On Apr 3, 2015, at 12:14 PM, Kathleen Moriarty
> <[e-mail]> wrote:
>
>
>
> On Fri, Apr 3, 2015 at 3:02 PM, Justin Richer <[e-mail]> wrote:
>>
>> 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.
>
>
> If the WG is good with the change and there is no reason to make this a
> non-problem, that would be ideal.
>
> Thanks,
> Kathleen
>>
>>
>>  — Justin
>
>
>
>
> --
>
> Best regards,
> Kathleen
>
>