Network Working Group L. Hedstrom INTERNET DRAFT Independent Consultant Intended Category: Experimental L. Howard PADL Software Pty. Ltd. D. Siegmund Apple Computer, Inc. Expires in six months from 3 May 2002 DHCP Options for Locating LDAP Servers Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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). Notice All product and company names mentioned herein may be trademarks of their respective owners. Abstract This document defines a new DHCP option for delivering configuration information to LDAP (Lightweight Directory Access Protocol) clients. The information returned is represented as LDAP URLs, as specified in the LDAPv3 URL draft[1]. The DHCP client may use the URLs returned by the DHCP server to locate an LDAP server for the client's network. The URL may include the TCP port of the LDAP server, and the distinguished name which identifies the base object for searching. 1. Introduction This draft defines a new option in the Bootstrap Protocol (BOOTP) and the Dynamic Host Configuration Protocol (DHCP)[1],[2] to enable LDAP clients to find LDAP servers, their ports and base distinguished names (DNs), among other attributes. The configuration is returned to the DHCP client as a list of LDAP URLs (according to the syntax defined in [3]). The LDAP server name, or IP address, is mandatory. The LDAP port number is optional; the default assigned port is 389. While the the base DN is also optional, we anticipate that it will normally be specified. Even if the base DN is specified in the DHCP message, it may be ignored by the client in preference of a locally defined DN. LDAP attribute list and filter components may be specified, but they are optional and can be ignored by the client. The clients must honor the LDAP search scope, if present in the returned URLs. 2. LDAP option This option specifies one or more LDAP URLs for the client to use to access LDAP servers. URLs should be listed in order of preference (notwithstanding section 3 of this document). Multiple URLs are separated with a literal space. The code for this option is . Its minimum length is 1. Code Len LDAP URL +-----+-----+-----+-----+-----+-----+-- | xxx | n | u1 | u2 | u3 | u4 | ... +-----+-----+-----+-----+-----+-----+-- In the following examples, the value of the option is shown as a string enclosed in double-quotes. The quotes themselves are not part of the option value, they are shown merely to delimit the start and end of the option. This example specifies the LDAP server, and the base DN: "ldap://ldap.ace.com/o=Ace%20Industries" LDAP over SSL is supported using the ldaps protocol, e.g. "ldaps://ldap.ace.com:636/o=Ace%20Industries" This example specifies multiple URLs: "ldap://my.ace.com/o=My%20Ace ldap://ldap.ace.com/o=Ace%20Industries" 3. URL extensions for server location Two new extensions are defined, x-weight and x-priority. Both these extensions are optional, and it is not required that they be supported by an LDAP client using DHCP in the manner described above. The extensions have the same meanings as defined in RFC2782 [4]. The client must attempt to contact the target host with the lowest- numbered priority (denoted by x-priority) it can reach, and target hosts with the same priority should be tried in pseudo random order. The syntax of the x-priority extension is an integer in the range 0-65535. When selecting a target from those that have the same priority, the chance of contacting a specific one should be proportional to its weight. The syntax of the x-weight extension is an integer in the range 1-65535. When there is no load balancing to be done, the weight should be zero or the extension omitted. If the x-priority extension is omitted, then the order of URLs returned determines their preference. For example: ldap://ldap.ace.com/o=Ace%20Industries??sub??x-weight=0,x- priority=10 denotes the LDAP server ldap.ace.com, serving the naming context o=Ace Industries, with a weight of 0 and a priority of 10. 4. URL extensions for server binding The bindname extension, defined in [3], may be used to specify the distinguished name with which the LDAP client should bind to the server. The x-bindpw extension (defined here) may be used to provide the client with bind credentials for binding to an LDAP server, although it should be noted that this information may be easily retrieved by malicious DHCP clients, and is thus of little use. 5. Security considerations Security considerations discussed in [3], particularly with respect to the provision of authentication information, are directly applicable here. Additionally, it should be noted that providing LDAP server information by a broadcast protocol such as DHCP may allow unauthorized clients to learn the location of and authentication information for LDAP servers and hence pose as valid clients. This presents a security problem when sensitive information, such as user passwords, is published via LDAP servers. The DHCP protocol provides no mechanisms for the client to verify the validity and correctness of the received information. The security considerations in [1] discuss several weaknesses, particularly the problem with unauthorized DHCP servers. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131. [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132. [3] T. Howes and M. Smith., "The LDAP URL Format", RFC 2255. [4] Vixie, P., A. Gulbrandsen and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782. Authors' Addresses Leif Hedstrom 23 Terrace Ave Half Moon Bay, CA USA leif@ogre.com Luke Howard PO Box 59 Central Park Vic 3145 Australia lukeh@padl.com Dieter Siegmund 1 Infinite Loop MS 302-4K Cupertino, CA 95014 USA dieter@apple.com