Subject: Re: [ldapext] Summary of group discussion

From: Howard Chu <[email-masked]>
Date: Sat, 15 Aug 2009 02:27:06 -0700

Keutel, Jochen wrote:
> Hello Andrew,
>     I'm definitely late in commenting this ... I just missed the
> discussion in September, sorry.
>
> One thing I'd like to add: X.501 defines the X.500 access control
> schema. Esp. it defines:
>
> ACIItem ::= SEQUENCE {
>     identificationTag DirectoryString { ub-tag },
>     precedence Precedence,
>     authenticationLevel AuthenticationLevel,
>     itemOrUserFirst CHOICE {
>       itemFirst [0] SEQUENCE {
>         protectedItems ProtectedItems,
>         itemPermissions SET OF ItemPermission },
>       userFirst [1] SEQUENCE {
>         userClasses UserClasses,
>         userPermissions SET OF UserPermission } } }
>
> UserClasses ::= SEQUENCE {
>     allUsers [0] NULL OPTIONAL,
>     thisEntry [1] NULL OPTIONAL,
>     name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
>     userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
>       -- dn component shall be the name of an
>       -- entry of GroupOfUniqueNames
>     subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL }
>
> The referenced NameAndOptionalUID is defined in X.520:
>
> NameAndOptionalUID ::= SEQUENCE {
>     dn DistinguishedName,
>     uid UniqueIdentifier OPTIONAL }
>
> So here we have a unique identifier twice: Inside the groupOfUniqueNames
> and in the NameAndOptionalUID structure. Both are not used in the real
> world ... (at least I've never seen it).
>
> The problem I see: Products using this ACI schema (esp. X.500 based
> products as e.g. Siemens DirX or CriticalPath) do only work if the
> userGroup component of UserClasses is really a groupOfuniqueNames. Of
> course you can put the DN of a groupOfNames or groupOfEntries or ...
> into this field - but ACI checking won't work.
>
> So I see 2 points:
>
> 1. Shall X.501 be changed as well?

In X.501(1993), which is the spec that LDAP conforms to, section 16.4.2.5 
"Determining group membership" clause (b) says

The entry named by the userGroup specification must be an instance of the 
object class groupOfNames or groupOfUniqueNames.

So from that perspective, we're not completely cutting things off.

> 2. Shall this ACI issue be mentioned in your draft?

The other alternative is to fix the LDAP definition of the NameAndOptionalUID 
syntax, so that it's actually usable in LDAP.

Given the bass-ackward RDN ordering that was chosen for the string 
representation of DNs in LDAP, the only unambiguous thing to do with these is 
to put the x500uniqueIdentifier *first* in the string. So revise RFC4517's 
definition 3.3.21

	NameAndOptionalUID = [BitString] distinguishedName

The SHARP character in the current definition is extraneous since the 
BitString definition is already fully delimited.

If we fix this syntax then I would drop all objections relating to its use.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

---

From: Howard Chu <[email-masked]>
Date: Sat, 15 Aug 2009 02:37:05 -0700

Howard Chu wrote:
> to put the x500uniqueIdentifier *first* in the string.

OK, it's not the *only* unambiguous thing. We could also just use another RDN 
delimiter (COMMA) instead of the SHARP in the current definition.

> So revise RFC4517's

---

From: Michael Ströder <[email-masked]>
Date: Sat, 15 Aug 2009 12:59:38 +0200

Howard Chu wrote:
> The other alternative is to fix the LDAP definition of the
> NameAndOptionalUID syntax, so that it's actually usable in LDAP.
> 
> representation of DNs in LDAP, the only unambiguous thing to do with
> these is to put the x500uniqueIdentifier *first* in the string. So
> revise RFC4517's definition 3.3.21
> 

1. I don't any deployment which uses the optional BitString part. The
deployments I know just use the distinguishedName.

2. The implementations I know which might make use of the optional UID part
did not use a BitString there. They messed it up with attribute 'uid' (which
is of DirectoryString).

3. Changing declaration in RFC 4517 would potentially break things.

=> My suggestion would be to add an applicability note to section 3.3.21 which
states that either distinguishedName MUST NOT contain SHARP. Or maybe it would
be possible to mandate that SHARP MUST be escaped like described in RFC 4514.

Ciao, Michael.

---

From: Howard Chu <[email-masked]>
Date: Sat, 15 Aug 2009 04:48:47 -0700

> deployments I know just use the distinguishedName.

Right. I doubt that anyone will ever notice a change here.

> did not use a BitString there. They messed it up with attribute 'uid' (which

Then they're broken regardless of what we decide.

> 3. Changing declaration in RFC 4517 would potentially break things.

For a very very small number of deployments. I suspect the number is zero.

> be possible to mandate that SHARP MUST be escaped like described in RFC 4514.

No, changing the escaping rules for DNs would definitely break things.

 >>      subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL }

ACIs specifying users are also not just simple DNs. The obvious implication is 
that when a user with an associated x500UniqueIdentifier authenticates to a 
DSA, this UID must also be included in the authzID that the DSA associates to 
the session. RFC4511 doesn't mention anything about this. Additionally, X.501 
16.4.2.4 (g) Note 3

      NOTE 3 – When authentication is based on supplied SecurityParameters, 
the unique identifier associated with the user may be taken from the 
subjectUniqueIdentifier field of the sender’s Certificate in the optional
CertificationPath

I would take this to mean that if an LDAP session was authenticated with 
SASL/EXTERNAL using an X.509 client cert, the LDAP DSA SHOULD look for the 
cert's subjectUniqueIdentifier. But I guess that's a digression for another 
thread...

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 15 Aug 2009 11:10:12 -0700

On Aug 15, 2009, at 4:48 AM, Howard Chu wrote:

> ACIs specifying users are also not just simple DNs.

In theory, yes.

I have never seen the optional UID used in practice, and I seriously  
doubt directory agents consistently and properly implement UID support.

And even if the implementations one was using did well provide UID  
support, I would not recommend use of the feature.  Instead, deployers  
should instead utilize a naming scheme which produces single use,  
stable DNs.

> The obvious implication is that when a user with an associated  
> x500UniqueIdentifier authenticates to a DSA, this UID must also be  
> included in the authzID that the DSA associates to the session.  
> RFC4511 doesn't mention anything about this.

The LDAP TS likely should include a security consideration (and likely  
in multiple documents) that deployers should utilize an appropriate  
naming scheme to avoid the need for UIDs.

-- Kurt