Internet DRAFT - draft-hedstrom-dhc-ldap
draft-hedstrom-dhc-ldap
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
<draft-hedstrom-dhc-ldap-02.txt>
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 <xxx>. 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
