From leif@netscape.com  Fri Jul 18 12:19:34 1997
To: iana@ISI.EDU
Subject: Re: DHCP extension for LDAP


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




                 DHCP Options for Locating LDAP Servers
                   <draft-hedstrom-dhcp-ldap-01.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              18 July 1997


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

   The code for this option is <xxx>. Its minimum length is 1.

    Code   Len         LDAP URL

   +-----+-----+-----+-----+-----+-----+--
   | xxx |  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              18 July 1997


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


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



Hedstrom and Howard                                             [Page 3]





Internet Draft           DHCP Options for LDAP              18 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

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

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

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

      [4]  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]



--------------60AFE91858B96D9ACBADD5F7
Content-Type: text/plain; charset=us-ascii; name="dhc-ldap.ms"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="dhc-ldap.ms"

.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Hedstrom and Howard
.ds RF [Page %]
.ds CF
.ds LH Internet Draft
.ds RH 18 July 1997
.ds CH DHCP Options for LDAP
.hy 0
.ad l
.in 0
Network Working Group                                        L. Hedstrom
INTERNET DRAFT                             Netscape Communications Corp.
Intended Category: Experimental                                L. Howard
                                                  Independent Consultant
Expires in six months from                                  18 July 1997




.ce
DHCP Options for Locating LDAP Servers
.ce
<draft-hedstrom-dhcp-ldap-01.txt>



.ti 0
Status of this Memo

.fi
.in 3
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).


.ti 0
Notice

All product and company names mentioned herein may be trademarks of
their respective owners.


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


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


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

The code for this option is <xxx>. Its minimum length is 1.

.nf
 Code   Len         LDAP URL
 
+-----+-----+-----+-----+-----+-----+--
| xxx |  n  |  u1 |  u2 |  u3 |  u4 | ...
+-----+-----+-----+-----+-----+-----+--
.fi


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


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


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


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


.ti 0
References
 
   [1]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131.
 
   [2]  Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
        Extensions", RFC 1533.

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

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


.ti 0
Authors' Addresses

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

--------------60AFE91858B96D9ACBADD5F7--