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

[Sam Hartman <[e-mail]>]

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