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

[Ben Laurie <[e-mail]>]

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.

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.

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

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.

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.

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!

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.