Internet Engineering Task Force Jeff Hodges, Stanford University INTERNET-DRAFT October, 1997 Category: Standards Track Requirements for Distinguished Names in Autonomous to Loosely-coupled LDAP-based Directory Services Status of this Document This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This document expires in April 1998. Abstract This document analyzes the issues involved in the Distinguished Name- spaces of autonomous to loosely-coupled, LDAP-based directory services (LLDSs). It folds in experience learned from the global X.500-based Dis- tinguished Name-space, and proposes requirements for the construction of Distinguished Names for LLDSs of varying scopes. 1. Introduction LDAP-based directory services provide a "named entry with attributes" model -- an entry's attributes may be retrieved by looking up its name in the directory. In order to provide a directory service in which por- tions of the namespace are contributed by relatively autonomous servers, there must be agreements on how the namespace's topology, properties, and allocation work. J. Hodges [Page 1] Internet-Draft DN Requirements for LLDSs Oct-1997 This document provides general background on naming in LDAP-based direc- tory services, analyzes the specific case of loosely-coupled, LDAP-based directory services (LLDSs), examines experience gleaned from the X.500- based global directory, postulates some future applications for LLDSs, and then proposes requirements for such a directory service's Dis- tinguished Name-space. Note that this document does not address requirements for an LLDS Dis- tinguished Name-space in the context of their utilization as part of LDAP URLs [LDAPurls] or LDAP Uniform Resource Names (URNs). See the fol- lowing section for details. This is a requirements definition document. It does not define a partic- ular solution or its implementation. These topics will either be addressed in other Internet-Drafts or this document will be merged with ones addressing them. 1.1. What this Document Doesn't Address This document does not address the specific cases of.. 1. The details of entry Relative Distinguished Name (RDN) construction and "entry naming" in general. They both are ostensibly pieces of overall "entry naming schemes". Such schemes may address not only how RDNs are selected, but also issues such as how to accomodate representing "names" of entries utilizing non-distinguished attri- butes. Entry naming schemes are thus decidedly site-specific and potentially complex in their own right. 2. How, given the DN of an entry and/or some attribute value from the entry, e.g. the value of the "mail" attribute, one would go about locating a specific directory service or server hosting the entry. 3. How DNs and thus entries in an autonomous or loosely-coupled direc- tory service are mapped to so-called "real world objects". This is entirely site- and entry-specific. 4. Distinguished Name-space requirements in the context of LDAP URLs or URNs. The requirements proposed in this document are based on the assumption of Distinguished Names being utilized on their own, not specifically as part of LDAP URLs or other amalgamations such as URNs. LDAP URLs/URNs may be considered and utilized, in some contexts, as "meta-Distinguished Names" which would explicitly contain more specific directory service context than Distinguished Names can on their own. Determining requirements for such utilization of Dis- tinguished Names is outside the (current) scope of this document. All of the above concepts are outside of the (current) scope of this J. Hodges [Page 2] Internet-Draft DN Requirements for LLDSs Oct-1997 document. They may be addressed in other Internet-Drafts, or the scope of this document may be widened to include them. 2. Document Conventions The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [ReqsKeywords]. 3. Background: Concepts of Naming in an LDAP-based Directory Service Directory services provide a lookup capability -- knowing something about an object, such as one of its names, one may lookup additional information about it in the directory. Thus a name in the directory ser- vices context is analogous to the concept of "keys" in the relational database management systems (RDBMS) context. X.500 [X.500], and thus LDAP [LDAP], employ a hierarchical namespace. This namespace is analogous to the "keyspace" a specific RDBMS-based database may have. An entry may have a name that relates only unto itself, with the only requirement being that the name is unique at that level of that particular branch of the hierarchy -- i.e. among its siblings. However, one must be able to locate the name at its position in the hierarchy before the name is meaningful in a context beyond that of the entry itself. Thus in X.500 and LDAP, names have the concepts of being "relative" or "distinguished". A relative name is the entry's name unto itself, and isn't required to have any relation to other entries at that point in the hierarchy. There is a fully-qualified form of an entry's name, called the Distinguished Name (DN). DNs are quite similar to fully- qualified Internet domain names [DNS] in that their components trace the path from the root of the namespace hierarchy down to the entry. The entry's relative name is simply a component of the entry's Distinguished Name, much the same way that an Internet host's name is just a component of the host's fully-qualified domain name. An entry's relative name is known as its Relative Distinguished Name (RDN). Given that RDNs must be unique at each level in the hierarchy (i.e. among their siblings), then each DN derived from that naming hierarchy will be unique, relative to that hierarchy. One uses different forms of an entry's name to look it up, depending upon one's context relative to the naming hierarchy. If one's context is the same as that of the entry, one may refer to it using only its RDN. If one's context is different, e.g. perhaps being outside the directory context and "looking in", then one (essentially) uses the entry's DN (which is fully-qualified by definition). J. Hodges [Page 3] Internet-Draft DN Requirements for LLDSs Oct-1997 4. The Specific Problem Space: Loosely-coupled, LDAP-based Directory Services Loosely-coupled, LDAP-based directory services (LLDS) are being postu- lated by various working groups within the IETF. Specifically, such directory services will be made up of coalitions of cooperating, but essentially autonomous, site-specific directory services belonging to distinct and independent administrative domains. One of the primary pur- poses of such directory services will be to provide for lookup of, and searching for, entries across administrative domains. This, in essence, calls for a unified "distinguished name"-space in an LLDS's context, which we'll term in this document a "LLDS distinguished name-space". The autonomous directory services making up an LLDS will be contributing to portions of the LLDS distinguished name-space in much the same way that various administrative domains' DNS services contribute portions of the DNS namespace [DNS]. Given the characteristics of naming in LDAP- based directory services described above, the DNs contributed to a LLDS by the cooperating participants must be at least distinctly unambiguous, if not distinctly unique. This is similar to how Domain Names contri- buted to the DNS namespace must be unambiguous, i.e. they and their associated entry may be hosted on more than one server, if not dis- tinctly unique. 5. Prior Work: The X.500 Directory The X.500 standard proposes a global directory naming scheme in [X.500Naming]. In this scheme, the DN hierarchy, known as the Directory Information Tree (DIT), is based upon combinations of the names of geo- political (e.g. countries, states, provinces, etc.) and organizational (e.g. companies, governments, universities, etc.) entities. In practice, this has proved quite unwieldy, though not entirely unwork- able, in many geopolitical and organizational contexts because conflicts abound when trying to allocate globally distinct and unique DNs directly from the patchwork quilt of real-world namespaces -- specifically, there is ~noone~ with the authority to consistently mediate them all. This situation can be summarized as.. There is no overarching, international naming authority for geopolitical and organizational entities in the global, real-world context. [Amen. -- ed.] 6. The Future: Applications of LLDSs There are many potential applications for LLDSs. A broad-based, J. Hodges [Page 4] Internet-Draft DN Requirements for LLDSs Oct-1997 Internet-wide whitepages listing for people is arguably the most com- monly promoted one. Other high-leverage, emerging applications will be in the context of Internet-based electronic commerce and security infrastructures. In this context, DNs, and/or URLs based on the DNs [LDAPurls], will likely be cached for later use, where "later" might be on a scale of (potentially many) years. Also, products are already emerging, e.g. Netscape Communicator, which directly utilize and cache LDAP URLs and DNs. Certainly, more are likely to follow, and broad-based usage of such tools to increase. 7. Definitions of Directory Service Contexts 7.1. Local Directory Service Context A "local directory service context" may range from a single autonomous directory server to a set of loosely-coupled directory servers, i.e. an LLDS. 7.2. General LLDS Context A "general LLDS context" may range from a small set of LLDSs to a set of arbitrary size. 8. Requirements for LLDS Distinguished Name-spaces Given LDAP's distinguished name-space model, the movement towards creat- ing LLDSs, the lessons from X.500, and envisioned applications for LLDSs, these are requirements for distinguished names in the context of loosely-coupled, LDAP-based directory services... 8.1. The Primary Requirements R1.0. Distinguished Names (DNs) of entries in a given "local directory service context" MUST be able to perform as unique primary keys. This is essentially "by definition" of a DN. Local-context DNs MAY OR MAY NOT be unique across other autonomous directory servers or other LLDSs. R1.1. Distinguished Names (DNs) of entries in a given "general LLDS context" MAY be able to perform as unique primary keys. If a given DN is not unique, then a non-null set of entries within the general LLDS context will have that same DN. However, this DN SHOULD be unambiguous within the general LLDS context -- i.e. distinct entries in a general LLDS context MAY have the same DN IF there is an explicitly esta- blished relationship among them, otherwise distinct entries SHOULD have DNs which are unique within the general LLDS context. J. Hodges [Page 5] Internet-Draft DN Requirements for LLDSs Oct-1997 8.2. Overall Derived Requirements for DNs in a General LLDS Context R2. DNs contributed to a general LLDS distinguished name-space by oth- erwise autonomous directory service instances MUST satisfy R1.1. R3. DNs in a local directory context, which MAY potentially become a part of a general LLDS context, SHOULD utilize DNs that satisfy R1.1. R4. DNs in a local directory context, which may or may not become a part of a general LLDS context, MAY utilize DNs that satisfy R1.1. R5. A general LLDS context's distinguished name-space hierarchy, from which DNs are allocated (and modulo the specific requirements for RDNs below), SHOULD be based on some pre-existing heirarchical naming infrastructure having these specific properties... R5.1. It is available across the administrative domains participat- ing in the general LLDS context. R5.2. It is well-understood, and has a low-cost registration process (in both monetary and effort terms). R5.3. It is widely subscribed-to. R5.4. It is actively and effectively managed and has clearly defined procedures that are published across participating administrative domains. R5.5. It provides names that are guaranteed-unique across the parti- cipating administrative domains. R5.6. It provides names that change relatively infrequently, by some established, well-documented procedure, or not at all. 8.3. Requirements for Entry RDNs R6. Entry RDNs MUST be unique among their siblings (this is by defini- tion, but worth reiterating). R7. Entry RDNs SHOULD be immutable. R8. Entry RDNs MAY be based on any attribute type, subject to the entry's object class restrictions, and the attribute's value SHOULD be sourced from a documented, site-specific scheme that provides well- managed, guaranteed-unique names. R9. Entry RDNs MAY be constructed using only one attribute type and J. Hodges [Page 6] Internet-Draft DN Requirements for LLDSs Oct-1997 value pair, or MAY be constructed of an amalgamation of attributes. If the latter option is used, the involved attributes and their values SHOULD satisfy R8. 9. Summary This document has presented LDAP-based directory service naming con- cepts, analyzed naming issues involved in loosely-coupled LDAP-based directory services, and briefly summarized prior X.500-based experience with naming. The presented LLDS Distinguished Name-space requirements seek to satisfy the issues involved in LLDS naming as well as ameliorate the naming issues experienced with the global X.500-based directory. The intent is that in using these requirements as guidelines, we can reasonably and manageably design and construct Distinguished Name-spaces for LLDSs of arbitary and evolving scope. 10. Security Considerations This document expresses requirements for Distinguished Names in contexts ranging from an autonomous directory server to a loosely-coupled direc- tory service of potentially Internet-wide scope. Other documents which specify designs for systems and/or protocols seeking to satisfy these requirements should consider security implications from at least this perspective.. DNs and/or URLs based upon them are publicly consummable and cache- able. Each one will conceivably expose some of a LLDS's structure. What are the implications for the security and authorization facili- ties of the individual directory services participating in the LLDS, and the various client systems based upon the LLDS? 11. Acknowledgements Many of the concepts in this document are drawn from [Dirnaming]. Al Grimstad, Chris Apple, and Chris Weider contributed valuable comments and perspectives to this document. 12. References [Dirnaming] Naming Plan for Internet Directory-Enabled Applications. A. Grim- stad, R. Huber, S. Sataluri, S. Kille, M. Wahl. Internet-Draft, work-in-progress. August 1997. Available as: J. Hodges [Page 7] Internet-Draft DN Requirements for LLDSs Oct-1997 [DNS]Domain Name System Structure and Delegation. J. Postel. RFC 1951. March 1994. [LDAP]Lightweight Directory Access Protocol. W. Yeong, T. Howes & S. Kille. RFC 1777, Draft Standard. March 1995. [LDAPurls] An LDAP URL Format. T. Howes & M. Smith. RFC 1959. June 1996. [ReqsKeywords] Scott Bradner, "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119. [X.500] The Directory: Overview of Concepts, Models and Service. CCITT Recommendation X.500, 1993. [X.500Naming] Annex B to CCITT Recommendation X.521, 1993. 13. Author's Address Jeff Hodges Computing & Communication Services Stanford University Pine Hall 241 Panama Street Stanford, CA 94305-4122 USA Phone: +1-650-723-2452 EMail: Jeff.Hodges@Stanford.edu URL: http://www.stanford.edu/~hodges/ J. Hodges [Page 8]