Network Working Group                                        L. Hedstrom
INTERNET DRAFT                             Netscape Communications Corp.
Intended Category: Experimental                                L. Howard
                                                  Independent Consultant
Expires in six months from                                  30 July 1997




                 DHCP Options for Locating LDAP Servers
                    <draft-hedstrom-dhc-ldap-00.txt>



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 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



Hedstrom and Howard                                             [Page 1]

Internet Draft           DHCP Options for LDAP              30 July 1997


   the TCP port of the LDAP server, and the distinguished name which
   identifies the base object for searching.


. 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.


. 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).

   The code for this option is 95. Its minimum length is 1.

    Code   Len         LDAP URL

   +----+-----+-----+-----+-----+-----+--
   | 95 |  n  |  u1 |  u2 |  u3 |  u4 | ...
   +----+-----+-----+-----+-----+-----+--


   This example URL specifies the LDAP server, and the base DN:

      ldap://ldap.ace.com/o=Ace Industries


   Secure LDAP is supported using the ldaps protocol (over SSL), e.g.

      ldaps://ldap.ace.com:636/o=Ace Industries




Hedstrom and Howard                                             [Page 2]

Internet Draft           DHCP Options for LDAP              30 July 1997


. 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 RFC2052 [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 Industries??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.


. 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.


. 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



Hedstrom and Howard                                             [Page 3]

Internet Draft           DHCP Options for LDAP              30 July 1997


   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

      []  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131.

      []  Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
           Extensions", RFC 1533.

      []  T. Howes and M. Smith., "The LDAP URL Format", INTERNET-DRAFT
           <draft-ietf-asid-ldapv3-url-03.txt>, June 1997.

      []  Vixie, P., "A DNS RR for specifying the location of services
           (DNS SRV)", RFC 2052.


Authors' Addresses

   Leif Hedstrom
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA
   +1 415 937-2507
   leif@netscape.com

   Luke Howard
   PO Box 59
   Central Park Vic 3145
   Australia
   lukeh@xedoc.com











Hedstrom and Howard                                             [Page 4]