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

[Sam Hartman <[e-mail]>]

>>>>> "Richard" == Richard Barnes <[e-mail]> 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.