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

[Justin Richer <[e-mail]>]

Ben, thanks for the review. Responses to particular points inline.

> On Apr 1, 2015, at 8:29 AM, Ben Laurie <[e-mail]> wrote:
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> Summary: ready with issues.
> 
> Nit: the Security Consideration section contains normative
> requirements. I don't know if this is strictly wrong, but it is
> unusual. The style I am used to has the normative requirements in the
> main body of the I-D, with Security Considerations confining itself to
> explaining what is going on security-wise.

I’ve seen both styles, and we can easily switch to having no normative text in this section if that is preferable to the AD and others here.

> 
> Issue: "Note that the authorization server decides the frequency of the
>   credential rotation and not the client.  Methods by which the client
>   can request credential rotation are outside the scope of this
>   document."
> 
> Clients are presumably as likely as servers to cause credential
> compromise, hence a mechanism by which a client can request a new
> credential seems wise.
> 

Client rotation of secrets was considered and discussed by the working group, but ultimately dropped from this (experimental) version of the spec and deferred to a future extension or update of this spec. There are a lot of considerations on how to do that properly, and nobody has (to my knowledge) implemented a client-driven secret rotation yet.

> Of course, this could be used by an attacker to lock a client out, so
> more thought required.

That’s only a concern if the attacker also gains the registration access token, which would presumably protect the credential rotation call as well. Since the registration access token is the mechanism by which a client is authorized by at the client configuration endpoint.

> 
> Issue: size limits.
> 
> There don't appear to be any limits (minimum server must accept, max
> client must send) for client data. Not necessarily a security issue,
> but seems likely to cause interop problems.

I don’t see a good way to have a reasonable size recommendation across different platforms and deployments. The server is free to reject any metadata values that it doesn’t like, including those that are too long. The server chooses the client_id and client_secret, so those aren’t an issue on the server side, but a client will need to be able to deal with “a JSON string” value for each of these for widest interoperability. If you have suggested text for size restrictions that would be reasonable across platforms, please send it along.

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

> 
> Issue: "The server MUST support TLS 1.2" - it seems unwise to mandate
> a particular version of TLS - work on TLS 1.3 is already under way,
> and TLS 1.2 is not (it seems) that far off deprecation!
> 

The current text is at the request of the AD (Kathleen) and it’s meant to point to the best practice at the time of spec publication. My goal here is just to get people to use TLS and use it properly to protect the endpoints in question, but there’s not a good official way to say “just use TLS and don’t be stupid" in the IETF yet. This, you’ll note, is the topic of the thread resulting from this original email. I’ll defer to the outcome of that thread on this point and change the draft’s text if required.

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


Thanks again for your review,
 — Justin