[secdir] secdir review of draft-ietf-abfab-gss-eap-naming-05

[Richard Barnes <[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.

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"