ASID Working Group Paul J. Leach, Microsoft INTERNET-DRAFT <draft-leach-asid-ldap-locating-00.txt> Expires September 25, 1997 March 25, 1997 Locating Native Internet LDAP Servers Preliminary Draft 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". WARNING: The specification in this document is subject to change, and will certainly change. It is inappropriate AND STUPID to implement to the proposed specification in this document. In particular, anyone who implements to this specification and then complains when it changes will be properly viewed as an idiot, and any such complaints shall be ignored. YOU HAVE BEEN WARNED. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the ASID working group at <ietf-asid@umich.edu>. Discussions of the working group are archived at <URL: ftp://terminator.rs.itd.umich.edu/ietf-asid/archive>. DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 1]
Internet-Draft Locating LDAP Servers 03/26/97 ABSTRACT The LDAPv3 protocol (as specified in [1]) is designed to be a lightweight access protocol for directory services supporting X.500 models. This may be the X.500 directory itself, but the LDAP specification explicitly allows it to be a different directory. Let us define a "native LDAP server" to be one that is not a front end to the X.500 directory service. Let us further define an "Internet based organization" as one that has a domain name, and an "Internet LDAP server" to be one containing a directory entries for such an organization. A native LDAP server can not rely upon the X.500 directory's knowledge base to locate the appropriate server to service a request on an object in a part of the directory tree (DIT) other than the naming context(s) it stores. This draft defines a way that native Internet LDAP servers can make use of the DNS's knowledge base (which it stores as "glue" records) to perform the same function, while still supporting integration with the X.500 directory. This draft builds on recent work by Kille and Wahl [2] to define a mechanism by which collections of native Internet LDAP servers can be integrated to create a directory service. That work supports this cause by defining a mapping from DNS names into LDAP DNs. In an Internet context, many of the names about which users seek information are DNS names, or include DNS names. A native LDAP based directory service for the Internet should make it convenient to process such names -- there is a huge social investment spanning two decades to get to the point where names like "john.doe@somewhere.com" and "http://www.sony.com" can appear in newspaper articles, TV commercials, and on billboards and millions of people understand what do with them. As a result, we assume that Internet based organizations wish to preserve this investment, yet also want to deploy directory services. Table of Contents 1. Introduction.......................................................3 2. Motivation..............................Error! Bookmark not defined. 3. Overview...........................................................4 4. Client behavior....................................................4 5. Server behavior....................................................5 DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 2]
Internet-Draft Locating LDAP Servers 03/26/97 6. Security Considerations............................................6 7. References.........................................................6 8. Author's address...................................................6 1. Introduction The LDAP protocol is designed to be a lightweight access protocol for directory services supporting X.500 models [1]. This may be the X.500 directory itself, or it could be a different directory. One particularly desirable use is as the access protocol for a directory service for the Internet. In the Internet context, the named entities which exist today about which users seek information almost all either have, or contain, DNS names [3,4], since it is by far the most widely used naming service in the Internet. There has a huge social investment spanning two decades to get to the point where names like "john.doe@somecorp.com" and "http://www.sony.com" can appear in newspaper articles, TV commercials, and on billboards, and millions of people understand what do with them. Recent work by Kille and Wahl [2] makes a good start at being able to use LDAP as an access protocol for information about objects with DNS names by defining a mapping from DNS names to Distinguished Names (DNs). In this draft, we define how to organize a collection of LDAP servers to be able to resolve and do searches on such DNs. We also describe how to select a "good" instances from among replicated instances of such servers, using DNS SRV and LOC RRs . We preserve the ability to integrate with the X.500 directory. 2. Overview The problem we wish to solve is: Starting with a LDAP distinguished name (DN), find an LDAP server that holds the naming context (NC) containing the entry denoted by that DN. We say that a DN is "DNS-based" if it has a suffix which has been constructed according to the rules of [2] - i.e., it ends with one or more DC components. Otherwise, we say it is "X.500 based". Using these definitions, we can now be more precise about the definition of native Internet LDAP server: a native Internet LDAP server is one that whose NCs have DNs that are all DNS-based. We assume that all native LDAP servers have DNS names. DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 3]
Internet-Draft Locating LDAP Servers 03/26/97 We assume that there exists a procedure, which is outside the scope of this draft, that servers can use for generating referrals for X.500 based DNs if a DN is not in the NC of the server. That leaves us with the task of specifying how a client selects the initial LDAP server to contact to resolve a DN, and the the procedure for a server to use to generate referrals for DNS-based DNs if a DN is not in the NC of the server. 3. Client behavior An LDAP client resolves a "target" DN using the following procedure: 1. Obtain the DNS name of an LDAP server, based on the type of the DN: · DNS-based It should extract the DNS name from the target DN using the rules in [2]. For example, if the DN is "CN=Joe%20Blow,DC=somecorp,DC=com", then the DNS name is "somecorp.com". · X.500-based · It MAY select the DNS name of any LDAP server that it knows, since any LDAP server is likely to at least able to give it a referral to a more appropriate LDAP server. If it happens that a particular selection fails, then it can just select another LDAP server. · All clients MUST be configured to know the DNS name of one "default" LDAP server. 2 . Resolve the DNS name according to the rules in [7] or [8] to open a connection to the LDAP server, then send the request to it. 3 . If the result is a referral, extract the DNS name of the server, then go to step 2. O ptimizations in step 1 that apply regardless of the type of the DN: · Clients MAY be configured to know one or more NCs and the DNS name of the LDAP server(s) for those NCs. If so, it SHOULD select one of the servers holding the NC with the longest DN that matches a suffix of the target DN. · Clients SHOULD cache the DNs and server DNS names from recently received referrals. The server name associated with the cached DN with the matching longest suffix in common with the target SHOULD be used. DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 4]
Internet-Draft Locating LDAP Servers 03/26/97 4. Server behavior An LDAP server, upon receipt of a request, has to decide to either process the request or return a referral to another LDAP server. It would process the request itself if the DN specified in the request is in one of the naming contexts handled by the server, and not in any subordinate naming context. (If it is a gateway or proxy, there may have be no such naming contexts.) Otherwise, it MAY chain the request to another server (if allowed by the request and the server's configuration); if it chooses to do this, it should behave as specified by the client procedure in the previous section. Otherwise, if is a DNS-based name (the DN specified in the request has DC components), it should create a DNS name from it as specified in [2], and return it in a referral. Otherwise, it is an X.500-based DN, and it create a referral using the presumed-to-exist procedure that is outside the scope of this document. 5. Security Considerations TBS 6. References [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol(v3)". Internet-Draft <draft-ietf-asid-ldapv3- protocol.txt>, ASID Working Group, June 5, 1996. [2] S. Kille, M. Wahl, An Approach for Using Domains in LDAP Distinguished Names, Internet Draft <draft-ietf-asid-ldap-domains- 00.txt>, ASID Working Group, July 31, 1996 (Work in progress) [3] P. Mockapetris, RFC 1034, DOMAIN NAMES - CONCEPTS AND FACILITIES, November, 1987. [4] P. Mockapetris, RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION, November, 1987. [5] T. Howes, M. Smith, RFC 1959, An LDAP URL Format, June 1996 [6] RFC 1876, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", 01/15/1996. DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 5]
Internet-Draft Locating LDAP Servers 03/26/97 [7] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", 03/13/1996, Internet Draft <draft- gulbrandsen-dns-rr-srvcs-03.txt>, March 1996. [8] Leach, P., "Selecting a server from among many replicas", Internet Draft, <draft-ietf-asid-replica-selection-00.txt>, February 1997. 7. Author's address Paul J. Leach Microsoft 1 Microsoft Way Redmond, Washington, 98052, U.S.A. Email: paulle@microsoft.com DO NOT IMPLEMENT TO THIS DOCUMENT! [Page 6]