>>>>> "Richard" == Richard Barnes <rbarnes@xxxxxxx> 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.