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

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Aug 2009 21:53:19 +0100

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.

General notes:

It's not entirely clear to me why one would want to consider this as  
part of an authorization check, unless one was attempting to match  
the name of the sponsor against a list of "known good" sponsors -  
that is, if a sponsor was subsequently revoked as a whole as being a  
suitable sponsor, one might want the sponsored clearances to be  
pulled as well. (It might be useful to note *why* one might want to  
do this, within the draft).

However, it occurs to me that this kind of matching might be better  
done against an OID, such as one from the Enterprise arc, rather than  
a simple string, which might prove to be subject to human foibles.

Dave.
--

---

From: Sean Turner <[email-masked]>
Date: Wed, 12 Aug 2009 14:16:59 -0400

Dave,

Thanks for your review.  Responses inline.

spt

Dave Cridland wrote:
> 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).
> 

Good point! I'll add that the DirectoryString MUST NOT be NULL.

> part of an authorization check, unless one was attempting to match the 
> name of the sponsor against a list of "known good" sponsors - that is, 
> if a sponsor was subsequently revoked as a whole as being a suitable 
> sponsor, one might want the sponsored clearances to be pulled as well. 
> (It might be useful to note *why* one might want to do this, within the 
> draft).

I'll move the last sentence in the 1st para in the intro to a new 
paragraph and add some examples:

This attribute may be used in authorization decisions.  For example, a 
web server deciding whether to allow a user access could check that the 
clearance sponsor present in the user's certificate is on an "approved" 
list. The web server could also check that the included clearance 
sponsor is on an "approved" list to issue the included clearance.

> However, it occurs to me that this kind of matching might be better done 
> against an OID, such as one from the Enterprise arc, rather than a 
> simple string, which might prove to be subject to human foibles.

Fat fingering is a concern but some people really like "human readable."
I'm certainly hoping that for people that use this there's a check to 
make sure that what they put in the string is only from an allowable list.

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 12 Aug 2009 12:01:41 -0700

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

>> security area directors.  Document editors and WG chairs should  
>> treat these comments just like any other last call comments.
>> This is a straighforward definition of an attribute suitable for X. 
>> 509 certificates (either public key or attribute) or X.500/LDAP  
>> I note that recent cases where a DirectoryName has been used with X. 
>> 509 for authentication - in particular usage of the CommonName of  
>> 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).

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