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.
This document defines a method for assigning names to information from RADIUS
and GSS-EAP, in particular SAML attributes received via the latter.
The security considerations in this document are difficult to evaluate because
the general architecture is unclear to me, e.g., who attaches these names to
things and who reads them. (The naming scheme itself seems well defined.) The
text that causes me concern is the following:
"
These names MUST NOT be used for attributes issued by a party other than one
closely associated with the source of credentials unless the source of
credentials is re-asserting these attributes.
"
The use of "MUST NOT" here implies that the intent is for the application
reading attributes to have assurance that they are "closely associated with the
source". However, the application has no way of verifying whether this MUST
NOT has been adhered to, so the entity setting names is trusted in this regard.
The document should note this, and the corresponding risk that the namer will
break this MUST NOT. This risk is hard for the reader to evaluate because
(AFAICT) the document doesn't specify who sets names in this system. (Passive
voice considered harmful.)
If the names did not have this implied security semantic, then the identity of
the namer wouldn't be an issue. Then this document could just define the
format of the names and move on.
This is a nonsense MUST: "a service MUST make a policy decision"
Editorial:
Page 7: "thatwe know"
Page 8: "MAy be absent" (or is this an update to RFC 2119? :) )
Page 11: "mechansisms are permitted"
Page 13: "Sam hartman"