Authorization Identities shouldn't be restricted to being only Distinguished Names RL "Bob" Morgan, University of Washington Jeff Hodges, Oblix, Inc. original: Wed, March 25, 1998 Updated: Tue, 9 Nov 1999 This note is available as: http://www.Stanford.edu/~hodges/doc/AuthzIDsNotRestrictedToDNs-1999-11-09.txt This is a note about the form of authorization identities for use in LDAPv3. This issue came up while we were working on the TLS-for-LDAP [LDAPv3-TLS] and LDAP Authentication [LDAPv3-AUTH] specs. We believe it's an important point, hence this note to provoke discussion and (we hope) continued consensus. The discussion was originally held on the ietf-ldapext@netscape.com email distribution list (which is probably the best place for continued discussion). It has been suggested in several venues that the identities used for access control purposes with LDAP should always be Distinguished Names. The ldapext-acl-reqts draft [ACL-Reqts] says this explicitly (U2 in section 3.3), and this has been suggested in some conversations we have had (email and face-to-face). This note presents an argument that identities (ie, the authorization IDs asserted by clients and expressed in ACL-type expressions used by servers) must be allowed to be any octet string. The TLS-for-LDAP draft [LDAPv3-TLS] currently does not constrain authorization IDs to be DNs (nor does [RFC 2251], for that matter). In terms of the [LDAPv3-TLS] and [LDAPv3-AUTH] drafts, this is the "authorization identity" described in section 5.4 of [LDAPv3-AUTH], and referred to in section 7.1.2 of [LDAPv3-TLS]: A client MAY either implicitly request that its LDAP authorization identity be derived from its authenticated TLS credentials or it MAY explicitly provide an authorization identity and assert that it be used in combination with its authenticated TLS credentials. Further, the Authorization Identity is explicitly syntactically defined in Section 11 of [LDAPv3-AUTH] as being _either_ a "unspecified userid, UTF-8 encoded" _or_ a "distinguished-name-based authz id". We understand, we think, the motivation for requiring the authorization identity to be a DN. DNs are the stuff of directories, and it gives at least a little structure to the identity. Some attributes (modifiersname?) referring to protocol identities are already defined as DNs, apparently. But for much the same reasons that some current directory server products offer a flexible mapping between the DN in a client cert and the authorization ID DN, we argue that the authorization ID must be permitted to be something other than a DN. Consider: (1) If you look at the evolution from X.509v1/PEM [PEM] to X.509v3/PKIX [PKIX], there is a consistent reduction in the signif- icance of the subject DN. In PEM it was not only required, it indicat- ed the CA hierarchy, and this is a well-known design disaster. In PKIX it doesn't have to be present at all; subjectAltName, which can take any number of other forms, is a key new feature permitting a non-DN identifier. In the LDAP-TLS scenario this means that a perfectly valid client cert might have no client DN in it at all. Requiring the authorization ID to be a DN seems much more like the mistake that PEM made than the flexibility that PKIX has found it appropriate to permit. (2) The appeal of DNs as authorization IDs for LDAP seems to be based on the X.500 scenario, where the directories of interest contain mostly person entries, and all DSAs are linked so entries in other parts of the DIT can be chased down. But the wider applicability of LDAP negates both of these assumptions. Suppose a network management station is using LDAP as an access protocol to query a data-collection agent, acting as an LDAP server, for device info (the sort of use envisioned in the MS-Cisco Directory-Enabled Networks initiative, for example), using Kerberos as an security layer. How does a DN-format authorization ID fit into this picture? Answer: it doesn't. The LDAP server only maintains info about device objects, not about users or whatever other entities are acting as requesters. Expecting that this server would be able to act as an LDAP client to look up info about the requesting ID (specifically the krbName to DN mapping in this example) seems to be well beyond the scope of current practice or any procedures that have been generally agreed upon. The most natural thing for this server would be to represent its internal authorization info as Kerberos principals and get Kerberos principals as authorization IDs in requests. (3) It is our impression that the community is still quite divided on the role of DN structure, and what forms DNs will take in practice. Will DN components be used to locate LDAP servers, or represent certificate validation paths? Should the hierarchy be c=, o= or dc=, dc=? Should the last RDN be a name-like human-palatable string or a guaranteed-unique UUID or GUID? Will particular DSAs or dir-based apps require one form or another? It seems premature to specify that ACLs and other places that might hold authorization identities should fill them up with DNs if we don't even know what they will look like, especially if an organization (eg, our former one at Stanford, with Kerberos) already has a deployed security infrastructure with well- established principal forms. In short, we think that mandating DNs as authorization IDs assumes that we know much more about how authorization will work, and how DNs will be used, than we really do at this point. We should simply specify that the SASL authorization ID field [SASL] be used to transmit this data, and that any octet string is acceptable. This reveals prob- lems with the simple bind method, which requires a DN as the bind ID, and doesn't support a separate authorization ID. This implies that the simple bind mechanism should plausibly be deprecated in favor of authentication mechanisms supporting such a concept, such as the SASL Digest mechanism [Digest]. It is now Fall 1999, over a year and a half since we wrote the first version of this note. [LDAPv3-AUTH] and [LDAPv3-TLS] are on the threshold of becoming Proposed Standard RFCs and explicitly express the notion of Authorization IDs _not_ being constrained to being only DNs. We feel this is a good thing. Unfortunately, we note that there are still drafts in-the-works that have not yet acknowledged this notion. References ---------- [ACL-Reqts] Access Control Requirements for LDAP http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-acl-reqts-02.txt [Digest] Using Digest Authentication as a SASL Mechanism http://info.internet.isi.edu:80/in-drafts/files/draft-leach-digest-sasl-05.txt [LDAPv3-AUTH] Authentication Methods for LDAP http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-authmeth-04.txt [LDAPv3-TLS] Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-ldapv3-tls-05.txt [PEM] Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1421.txt [PKIX] Internet X.509 Public Key Infrastructure Certificate and CRL Profile http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2459.txt [RFC 2251] Lightweight Directory Access Protocol (v3) ftp://ftp.isi.edu/in-notes/rfc2251.txt [SASL] Simple Authentication and Security Layer (SASL) http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2222.txt --- END