Skip to main content

Last Call Review of draft-ietf-abfab-gss-eap-naming-

Request Review of draft-ietf-abfab-gss-eap-naming
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-10-04
Requested 2012-09-28
Authors Sam Hartman , Josh Howlett
Draft last updated 2012-10-04
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Genart Last Call review of -?? by Suresh Krishnan
Assignment Reviewer Richard Barnes
State Completed
Review review-ietf-abfab-gss-eap-naming-secdir-lc-barnes-2012-10-04
Result Ready with Issues
Completed 2012-10-04
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"

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"