Subject: secdir review of draft-ietf-abfab-gss-eap-naming-05

From: Richard Barnes <[email-masked]>
Date: Wed, 3 Oct 2012 17:11:30 -0400

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"

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2012 17:45:42 -0400

>>>>> "Richard" == Richard Barnes <[email-masked]> writes:

    Richard> I have reviewed this document as part of the security
    Richard> directorate's ongoing effort to review all IETF documents
    Richard> being processed by the IESG.  These comments were written
    Richard> primarily for the benefit of the security area directors.
    Richard> Document editors and WG chairs should treat these comments
    Richard> just like any other last call comments.
    Richard> text that causes me concern is the following: " These names
    Richard> MUST NOT be used for attributes issued by a party other
    Richard> than one closely associated with the source of credentials
    Richard> unless the source of credentials is re-asserting these
    Richard> attributes.  " The use of "MUST NOT" here implies that the
    Richard> intent is for the application reading attributes to have
    Richard> assurance that they are "closely associated with the
    Richard> source".  However, the application has no way of verifying
    Richard> whether this MUST NOT has been adhered to, so the entity
    Richard> setting names is trusted in this regard.  The document
    Richard> should note this, and the corresponding risk that the namer
    Richard> will break this MUST NOT.  This risk is hard for the reader
    Richard> to evaluate because (AFAICT) the document doesn't specify
    Richard> who sets names in this system.  (Passive voice considered
    Richard> harmful.)

Yeah, we need more clarity around that as everyone who reads the
document brings up this issue.  I think it's OK because enforcing that
MUST NOT is a spec design issue in draft-ietf-abfab-aaa-saml, and a
couple of drafts in kitten.  I.E. if the IETF does its job, then
applications can depend on that MUST NOT being enforced.  We need to
make it more clear and we need to be careful when reviewing those other
specs.

So, I'll work on proposing text for this, but I think this is a clarity
issue rather than a security problem.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Oct 2012 17:06:19 -0400

>>>>> "Richard" == Richard Barnes <[email-masked]> writes:

    Richard> The security considerations in this document are difficult
    Richard> to evaluate because the general architecture is unclear to
    Richard> me, e.g., who attaches these names to things and who reads
    Richard> them.  (The naming scheme itself seems well defined.)  The
    Richard> text that causes me concern is the following: " These names
    Richard> MUST NOT be used for attributes issued by a party other
    Richard> than one closely associated with the source of credentials
    Richard> unless the source of credentials is re-asserting these
    Richard> attributes.  " The use of "MUST NOT" here implies that the
    Richard> intent is for the application reading attributes to have
    Richard> assurance that they are "closely associated with the
    Richard> source".  However, the application has no way of verifying
    Richard> whether this MUST NOT has been adhered to, so the entity
    Richard> setting names is trusted in this regard.  The document
    Richard> should note this, and the corresponding risk that the namer
    Richard> will break this MUST NOT.  This risk is hard for the reader
    Richard> to evaluate because (AFAICT) the document doesn't specify
    Richard> who sets names in this system.  (Passive voice considered
    Richard> harmful.)

I'd like to push back on this.
Text was adding in 05 making it clear that  in designing mechanisms
specifications we need to enforce that MUST not.
The full paragraph in question is as follows:

   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 the attributes.  For example, a
   source of credentials can consult whatever sources of attributes it
   chooses, but acceptors can assume attributes in the federated context
   are from the source of credentials.  This requirement is typically

   enforced in mechanism specifications.  For example
   [I-D.ietf-abfab-aaa-saml] provides enough information thatwe know the
   attributes it carries today are in the federated context.  Similarly,
   we know that the requirements of this paragraph are met by SAML
   mechanisms where the assertion is the means of authentication.

I actually think that's reasonably easy to analyze and that we're in the
process of doing the analysis for draft-ietf-abfab-aaa-saml and have
done the analysis for other mechanisms.