Last Call Review of draft-ietf-oauth-dyn-reg-24
review-ietf-oauth-dyn-reg-24-secdir-lc-kaufman-2015-03-12-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

This document specifies a protocol whereby an instance of installed software
on a node can register itself with an OAuth 2.0 authorization server and in
doing so (normally) acquire a secret to be used in subsequent
authentications. According to the introduction:

"This specification generalizes the registration mechanisms defined by the
OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration]
specification and used by the User Managed Access (UMA) Profile of OAuth 2.0
[I-D.hardjono-oauth-umacore] specification in a way that is compatible with
both, while being applicable to a wider set of OAuth 2.0 use cases."

I am not an expert on the evolution of OAuth, and I would expect others on
Secdir are, so they be more able to evaluate the goodness of the particular
design decisions, but this appears to me to be consistent with the way OAuth
does related things and the particular attributes that this document
specifies as being relevant to the process seem right.

The security considerations section of the document is somewhat unorthodox
in that it specifies security aspects of the protocol (e.g., that it MUST
run over TLS 1.2 and MAY run over other transport-layer mechanisms. In most
recent RFCs, the security considerations section is not normative but rather
reviews the security aspects of the protocol. I'm not objecting though...
this organization seems entirely reasonable.

I will throw in one vague concern and one specific issue:

1) This document is all about infrastructure to allow software (as opposed
to the end user or service using the software) to authenticate itself. This
has been the holy grail of many authorization architectures for a long time,
but the technology to accomplish it securely is by and large still not in
place. I worry that specifying protocols for doing it might fool people into
thinking they are getting more security than they really are. There may be
some other document containing the rationale and scenarios for attempting
this, but it was not obvious (at least to me) from reading the document.

2) The software_version values are specified as opaque where the only
operation to be done on them is comparisons for equality. It's not clear (at
least to me) the intended usage of this field, but generally version numbers
work best when they have multiple parts (at least major version and minor
version and sometimes lower level indicators) and where the different parts
can be compared for "greater than" and "less than" in addition to tests for
equality. That allows forward compatibility when a new version is released
that is intended to be compatible with an existing version while detecting
incompatibility in the case where a major version number changes.

	--Charlie