Re: [secdir] Security Directorate Review of draft-turner-clearancesponsor-attribute

[Kurt Zeilenga <[e-mail]>]

On Aug 12, 2009, at 11:16 AM, Sean Turner wrote:

> Dave,
>
> Thanks for your review.  Responses inline.
>
> spt
>
> Dave Cridland wrote:
>> 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.
>> (I would note for the record that I roped in Kurt Zeilenga to check  
>> certain issues, but I nevertheless take full credit for any errors).
>> This is a straighforward definition of an attribute suitable for X. 
>> 509 certificates (either public key or attribute) or X.500/LDAP  
>> directory entries which carries the name of the clearance sponsor,  
>> that is, the entity which initiated and maintains the assignment of  
>> the clearance.
>> I note that recent cases where a DirectoryName has been used with X. 
>> 509 for authentication - in particular usage of the CommonName of  
>> the Subject Name - have been subjected to attacks using embedded  
>> NULs. Whilst presumably using the correct equality matching rule  
>> prevents this, it'd be nice to see that called out. (If the  
>> equality matching rule does not prevent this case, that's obviously  
>> more serious).
>> Mandating that NUL is not a valid codepoint in this attribute would  
>> probably be useful, too.
>
> Good point! I'll add that the DirectoryString MUST NOT be NULL.

DirectoryString is not defined by your I-D but by reference, as is the  
caseIgnoreMatch rule.  The security consideration is applicable to all  
protocols using DirectoryString and caseIgnoreMatch.

I think what you ought to say, in the Security Considerations section  
of this I-D, is something like:

While values of DirectoryString can include the NUL (U+0000) code  
point, values used to represent clearance sponsors typically would  
not.  Implementations of the caseIgnoreMatch rule must, per X.501,  
consider all of the assertion value and attribute value in matching  
and hence protect against truncation attacks.

-- Kurt