Network Working Group A. Brown Internet Draft Nortel Expires: C. Weider Category: Microsoft Mark Wahl Innosoft April 10, 1997 Practical guidance for naming and interconnectivity Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents 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 view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract There are existing communities of LDAP, X.500 and Whois++ servers on the Internet. An LDAPv3 server can be a part of one of more of these communities. LDAP directory services would benefit from reduced naming conflicts and increased ability to locate servers and information both within LDAP islands and between LDAP and other communities. This document recommends guidelines for naming and interconnection of LDAP servers to enable the existence of communities of a loosely coupled LDAP-based directory service that can leverage the X.500 knowledge model and the existing infrastructure of names from the Domain Name System (DNS). This will facilitate the establishment of a global naming plan and the interconnection of a global directory. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [10]. 1 Introduction 1.1 Background While some directory implementations will have a requirement to use the dc naming structure described in [DC Naming] which is based on DNS naming, this does not preclude connection to the infrastructure that comprises a hierarchy resulting from the knowledge model [X.500]. Similarly, there may be implementations that are part of the knowledge model infrastructure that may wish to make use of the dc naming model. 1.2 Purpose The aim of this document is to facilitate the interconnection of LDAP servers. One goal is to enable the location of directory servers and information stored on those servers. Another goal is to allow the initial interconnection of LDAP servers into arbitrary islands, in such a way as to allow these islands to interconnect at a later date without causing naming conflicts. This will facilitate the establishment of a global naming plan and the interconnection of a global directory. 1.3 Scope Use of each naming philosophy has its own implications, such as registration, and may require cooperation of large communities before being used on a large scale. The dc naming and knowledge models are introduced, along with a section on bridging these models. Recommendations are provided on which model(s) to use, based on a list of requirements that each model addresses. [Ed. Note: Do we need this section?] Using these guidelines, an administrator can chose one or a combination of namespace choices, based on the requirements (e.g., browsing, intra-server searching, cost, timely updates, performance, security, etc.) of the directory being deployed. 2 Internet Directory Naming If you wish to install an LDAP server that will never, for all time, be used by anyone outside your organization, you may use any root name for your LDAP server's namespace that you wish. However, if you might want to be able to connect your server with other servers within your organization, or wish to allow users outside your organization to access some of your data, you need to use one of the generally accepted LDAP naming schemes to allow your computer to find and be found by other computers. There are two basic models for naming of LDAP servers. The first continues the tradition used by X.500, which uses a geographically based namespace. A typical example would be 'country = Canada, province= Ontario, organization = Nortel.'. The second, recently developed in the IETF, leverages the existing DNS naming structure to create LDAP names. An example would be dc = critical-angle, dc = com. Each of these has its advantages and disadvantages. We will discuss each of these in detail below. 2.1 dc Names The basis for 'dc naming', as it is called, is the existing DNS naming infrastructure. Since a DNS name is today a prerequisite for supplying a service to the Internet, and since a DNS name is guaranteed to be globally unique, it can be used through the DC naming algorithm as a root for your local LDAP server. The algorithm used to take an existing DNS name and turn it into an LDAP root is extremely simple. Given a DNS name, such as foo.bar.com, simply split it up into components and use each component as a level in the name, i.e. dc = foo, dc = bar, dc = com. This can then be used as a root for an LDAP server, so that a typical entry on that server might have the Distinguished Name (DN) cn=Ebenezer Scrooge, o= Scrooge and Marley, dc = foo, dc = bar, dc = com. Interconnection issues for servers using DC names are covered below. 2.1.1 Obtaining a dc name To connect to the Internet and provide a service, you typically need a DNS name for your organization. This is usually provided as a part of your Internet connectivity package from your local Internet provider. Once you have this name, if you wish to connect your LDAP server to the Global Directory, or allow it to be found by users who may only know the DNs of entries on your server, you will need to follow the algorithm above and build a root name for your server. 2.2 X.500 Naming X.500 naming is similar to DNS naming in that each component of an X.500 name represents a level in a hierarchy. However X.500 naming is not limited to domain components. An X.500 name component, called a Relative Distinguished Name (RDN), can be a geographical entity, an organization's name, a component in a natural hierarchy, such as a digit in the E.164 numbering plan, or some other name that is useful to applications and users that access a directory. In X.500 there is considered to be one hierarchical tree, which may be comprised of sub-trees, such as one structured after the E.164 numbering plan. 2.2.1 Obtaining a Name in X.500 To become part of the global X.500 directory hierarchy, you must register a name that is unique among its siblings under a particular node in the tree. The registration authority for the top level of the hierarchy is currently being established. [Ed. Note: What is the status of ANSI's proposal to the ITU?] This registrar may delegate authority to entities who wish to have entries directly under the root of the tree, such as countries and international organizations. These authorities may further delegate sub- trees under their responsibility to other organizations. 3 Interconnection Models Each LDAP server holds a part of the overall LDAP namespace. Tying LDAP servers together into a global directory requires that servers be able to locate each other. There is an existing mechanism for locating servers using the knowledge model, which will be outlined below. This document defines an additional mechanism for locating servers using the DC style naming, and section 4 covers how to interface the dc naming and knowledge models. 3.1 dc Model The DC model is designed to facilitate 'grass-roots' deployment of LDAP, i.e. deployment which is not globally centrally managed or coordinated. Therefore, when you deploy servers using the DC model, you should exercise discipline in actually assigning DNS names to your LDAP servers. That will allow the following algorithm for server location to work without central coordination, and will make it easier for you to interoperate with other LDAP servers. 3.1.1 Locating an LDAP server from a DC style DN To locate an LDAP server from a DC style DN, convert the DC components into the corresponding DNS name. Then use [Discovery] to find the appropriate server. This mapping can be done on either the client or server side. If it is done on the client side, and the server is in the correct location, the client can go directly to the appropriate server without having to interact with any other server. If it is done on the server side, the server is responsible for doing the translation and referring the client appropriately. Note that if this is done on the server side, the server may have additional information which allows it to determine the location of the target DN. 3.1.2 Naming your server Your server should be named such that a client or server following the above algorithm would be able to locate the server. If there are multiple DC based naming contexts on your server, your server should be locatable through the use of any of those contexts. Example: If you have a naming context of DC=foo, DC=bar, DC=com on your LDAP server, that server should be reachable through the SRVLOC record corresponding to ldap.tcp.foo.bar.com. Similarly, if you also have a naming context of DC=hoohoo, DC= bar2, DC=com, that server should also be reachable through ldap.tcp.hoohoo.bar2.com. 3.1.3 Server requirements to support this plan If you are responsible for deploying an entire subtree distributed across several servers, you may wish to put superior and subordinate references in for all servers which are not rooted directly at a DN comprised solely of DC components. For example, let's say that you had two servers in your organization, one rooted at dc=foo, dc=com, and the other one rooted at ou=marketing, dc=foo, dc=com. Obviously the only way to locate the second server is to have a subordinate reference to it on the parent server, as the name translation algorithm listed above is only able to handle dc components. In addition, the server may wish to perform DC-based name resolution for arbitrary DNs which end in a dc-based name component. The question of whether such results are cached by the server is not addressed by this document. 3.2 Knowledge Model If a local server does not contain the information requested by a client, the server may either reject the request, contact another server to locate the required information, or may refer the client to another server. For one server to be able to contact another using the knowledge model, it must first possess a knowledge reference for the remote server. A knowledge reference consists of a server's address (i.e., IP address or domain name) and possibly the DN of an entry in the portion of the directory hierarchy held by the remote server. Name resolution is the process by which the X.500 hierarchy is traversed from the root of the tree down to the entry identified by the X.500 name in question. If the name resolution process encounters a knowledge reference, the process continues onto the server specified in the reference. 4 Interfacing the dc Naming and Knowledge Model Infrastructures This section describes how servers following the dc and knowledge models of interconnection can refer queries to servers which follow the other naming model. This is done by configuring the superior reference of servers following the DC model and top level references of servers following the knowledge model to point to specialized servers known as referral servers. These referral servers act as a bridge between the interconnection models, so that most LDAP servers need only have a minor configuration choice made in order to allow clients to be able to reach data on all other servers regardless of whether the interconnection model these two servers support are the same. 4.1 Referral servers A referral server is an LDAPv3 server whose primary purpose in this application is to return referrals for clients to progress particular requests. These requests are characterized as operations in which the target or base entry uses a different naming scheme than that of the server to which client first sent the query. Referral servers need not maintain any master or fully replicated data on entries of interest to users, instead they would contain knowledge references or CIP indexes. There might be multiple referral servers in the Internet. Any referral server SHOULD have query routing algorithms which implement at least two of the following interconnection models: - CIP index of LDAP servers - DNS - X.500 - Another indexing system which supports LDAP queries The algorithms for the first three models are discussed in the following sections 4.1.1 through 4.1.3. Like all LDAPv3 servers, referral servers will return data about themselves when the query is a base object search of the root. These servers SHOULD be able to process a one level search of the root. These servers will likely return an error if the query is a subtree search of the root, and MUST return an error if they support either the DNS or X.500 algorithms. 4.1.1 Algorithm for CIP index of LDAP servers This algorithm is used by referral server when it recognizes the target or base entry DN of the client's query, or a superior of that DN, is the base of a CIP index supported by the referral server. In this case, the referral server SHOULD use the specification defined in [CIP for LDAP] to return to the client either a result message (possibly containing a referral) or a set of continuation references. This will usually refer the client to the servers more likely to hold the requested data. This algorithm is also used if the base entry DN of the client's query is superior to the base of a CIP index and the base of the CIP index is in the scope of the query. If however the base of the CIP index is not in the scope of the query, then the algorithms in section 4.1.2 or 4.1.3 would typically be used instead. 4.1.2 Algorithm for DNS This algorithm is used when the most significant RDN component of the target or base entry DN of the client's query consists of a single AVA of the 'dc' attribute type, and the target or base object DN is not recognized as being at or below the base of a CIP index supported by the referral server. In this case, the referral server SHOULD use the DNS to resolve as many components of the DN as possible which have the 'dc' attribute type using the algorithm defined in [DC Naming] and [SRV]. 4.1.3 Algorithm for X.500 This algorithm is used when the most significant RDN component of the target or base entry DN is not an AVA of the 'dc' attribute type, and it is not recognized at or the base of a CIP index supported by the referral server. In this case, the referral server SHOULD refer the operation to one of the 'first level DSA' servers, which is a server that is not part of the DNS interconnection model and which holds a naming context consisting of a single RDN. The referral server SHOULD choose to refer to the servers which hold an entry at or superior to the target or base entry requested by the client, should the information of relationships between naming contexts and servers be available to the referral server. Administrators should note that as there may be in the Internet multiple distinct hierarchies using X.500 interconnection models, any particular referral server may not be able to reach all the servers using X.500 interconnection. 4.1.4 Advertising first level information to X.500 A referral server which supports both the DNS and X.500 algorithms SHOULD advertise to the X.500 interconnection model servers that it contacts knowledge information for the DNS, so that these servers can in return referrals to the referral server. The referral server SHOULD advertise that it is a master or shadow server for each entry whose name is the 'dc' form of a top level DNS domain. The list of all Top Level DNS domains is currently maintained by the InterNIC, operated by Network Solutions, at the URL [Top level DNS domains]. This contents and maintainer of this list is likely subject to change, and this document or a successor will be revised when this occurs. The mechanism by which the referral server provides this information to the X.500 server MAY be one of the following: [Ed. Note: *** To be Provided ***] 4.1.5 Advertising the referral server in DNS A record for a referral server SHOULD be present in the DNS with a SRV record pointing to it. This will allow the DNS name of the SRV record to be easily communicated and allow the number and location of the referral servers themselves with that DNS name to be changed by the referral server's administrators without significantly disrupting the configuration of other servers on the Internet. 4.2 Configuration of servers holding dc names A server which holds a naming context based on a 'dc' style name SHOULD support the interconnection model described in section 3.1. In addition, if the server holds a naming context immediately subordinate to the root or the server does not have a superior reference to server(s) which hold a superior naming context, then the server SHOULD have a superior reference to a referral server. The format of the superior reference is defined in section 5.2 of [Referrals]. The mechanism by which the administrator of the server locates and chooses an appropriate referral server for use as a superior reference is not defined in this document. 4.3 Configuration of servers holding non-first-level X.500 names A server which holds a naming context based on a naming scheme other than one ending in a 'dc' based name where that naming context is not immediately subordinate to the root SHOULD support the interconnection model described in section 3.2. No additional configuration need be done by these server administrators to support referral servers. 4.4 Configuration of servers holding first level X.500 names A 'first level DSA', as defined in section 4.1.3, SHOULD have knowledge references corresponding to every top level DNS domain. It would typically have received this knowledge information from one or more referral servers, as described in section 4.1.4. These knowledge references held in a first level DSA need not necessarily point at the same referral server, however there SHOULD be a reference to at least one referral server for each top level domain in the DNS. The mechanism by which the administrator chooses the appropriate referral servers is not defined in this document. 5 Recommendations [Ed. Note: Do we need this section?] 6 Security This memo describes how LDAP servers can be named and interconnected. Servers should ensure that an appropriate security policy is maintained. An enterprise is not restricted in the information which it may store in DNS or LDAP servers. A client which contacts an untrusted server may have incorrect or misleading information returned (e.g. an organization's server may claim to hold naming contexts representing domain names which have not been delegated to that organization). 7 Internationalization [Ed.Note: To be provided] 8 References [CIP for LDAP] Roland Hedberg "LDAPv2 client Vs the Index Mesh", draft- ietf-find-cip-ldapv2-01.txt, January 1997. [DC Naming] S. Kille, M. Wahl, A. Grimstad, R. Huber, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, January 98. [Discovery] R. Moats, M. Hamilton, P. Leach, "Finding Stuff (How to discover services)", draft-ietf-srvloc-discovery-05.txt, October 97. [Referrals] Tim Howes, Mark Wahl, "Referrals and Knowledge References in LDAP Directories", draft-ietf-ldapext-referral-00.txt, March 98. [SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)," RFC 2052, October 1996. [Top level DNS domains] [Ed. Note: To be provided] [X.500] ITU-T X.500 Series of Recommendations, "The Directory", 1993. 9 Author's Addresses Anne R. Brown Nortel Technology P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada Voice: +1 613 765 5274 Email: arbrown@nortel.com Chris Weider Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA Voice: +1 425 703 2947 Email: cweider@microsoft.com Mark Wahl Innosoft 4815 W. Braker Lane #502-385 Austin, TX 79759 USA Voice: +1 512 372 3160 Email: M.Wahl@Critical-Angle.com