Sorry, I forgot to include in CC the working group. My
apologies.
Giuseppe
---------- Forwarded message ----------
From: Giuseppe Paterṇ (Gippa) <gpaterno gpaterno.com>
Date: Oct 24, 2006 1:15 PM
Subject: Re: [dhcwg] Proposal for experimental DHCP option
To: Stig Venaas <stig.venaasuninett.no>
Dear Stig,
first of all thank you for your attention. It's the first
time I
interact with an IESG working group,so I please the group
forgive me
if I make some mistake.
You pointed out exactly the main reason why I wrote the I-D:
locate
the closest replica that fit the "network". It's
basically the same
problem of specifying DNS: you might decide that a given
site, or even
subnet, has a totally different DNS. As for that, you can
decide that
this or that subnet has a different LDAP server (you can
have several
reasons for that).
Before posting the draft, I exchanged a lot of email and
talked over
IRC with an internal group of the company I work for (Red
Hat):
they're basically former netscape people (that came in with
the AOL
acquisition). Please note that I'm not writing on behalf of
Red Hat. I
wrote as indipendant, this has been done on non-working
time. I also
talked to some OpenLDAP developers: I wasn't aware of an
LDAP working
group in IESG ...
I evaluated with them the DNS SRV option, but it is not
always the
best. If you have a global flat DNS, you cannot distinguish
what is
the local replica: look at Active Directory for example,
that do more
or less the same thing. The LDAP client would go round-robin
through
the DNS SRV records. Yes, you could split the DNS in
geographical
region, eg: Italy. But, again on the example, Milan and Rome
offices
might have a local LDAP replica.
That come in the DHCP option: it gives you the flexibility
of
automatically configure the client for LDAP queries and to
choose the
best LDAP server as decided by the network admin (say the
closest or
the best one).
The draft you saw came from the discussion with our internal
LDAP team
and some OpenLDAP developers: I initially wrote a draft in
which two
options were defined. One for a list of IPs (such as DNS)
and one of
the Base DN. (I attached it in this mail for reference).
Both teams
preferred the LDAP URI as they said it gives you more
flexibility in
terms of LDAP options (such as port, TLS, ....). And that's
true. The
only concern I have is that you can specify only one ldap
server,
while it would be great to have a secondary choice. On this
concern,
they replied that most of the customers have a load
balancers for
multiple LDAPs or an HA solution, but I'm still not 100%
sure...
Any hits/concerns/help/suggestion is appreciated!!
Regards,
Giuseppe
On 10/24/06, Stig Venaas <stig.venaasuninett.no> wrote:
> My first thought before reading the draft, was that you
could just use
> DNS SRV. I agree though, as you stated in the draft,
that it may be
> problematic to locate the closest replica.
>
> Have you discussed this issue with other LDAP people?
It would be
> interesting to hear what people think at the LDAP list
at umich, or
> I believe ldapext and ldapbis wg mailing lists might
still exist...
Network Working Group
Giuseppe Paterno’
Internet-Draft
Independent Consultant
Expires March: 2007
July 2006
DHCP Options for LDAP Directory Services
discovery
Status of this Memo
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at
http://www.ietf.org/
shadow.html.
By submitting this Internet-Draft, each author represents
that any
applicable patent or other IPR claims of which he or she
is aware
have been or will be disclosed, and any of which he or
she becomes
aware will be disclosed, in accordance with Section 6 of
BCP 79.
Conventions used in this document
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and
"OPTIONAL" in
this document are to be interpreted as described in
[RFC-2119].
Abstract
This document defines two new DHCP options for delivering
configuration information for LDAP services. The first
option defines
a list of the closest LDAP servers for the client, while
the second
one deliver the base distinguished name of the LDAP tree.
These
options delivers enough LDAP information to enable the
client to
authenticate users and perform LDAP address lookup to the
closest
available LDAP server.
G. Paterno’ draft-gpaterno-dhcp-ldap-00.txt
[Page 1]
Internet-Draft
July 2006
1. Introduction
The Lightweight Directory Access Protocol (LDAP) [1] is
an access
protocol for directories. LDAP allows distributed
environment so that
replica copies exists into a given organization or even
the Internet.
In most organizations, LDAP is used to allow user
authentication and
databases lookup such as hosts, groups or e-mail
addresses.
The current methodologies of defining LDAP parameters are
limited to
statically configuring the servers into the clients or
seldom by
specifying them into the appropriate DNS RR records [2].
The
disadvantage of the first solution is that the client is
unable to
dynamically reconfigure/provision the system, while the
disadvantage
of the last solution is that the client is unable to
locate the
closest available replica, therefore not optimizing the
network for
large organizations.
The need is to have a methodology to autoconfigure LDAP
clients with
the closest available replica: the advantages provide
relief in
administration tasks and optimization of configuration of
mobile
clients (ex: laptops, PDAs, ...) or devices (ex:
multifunction
printers, IP phones, ...).
This specification describe two DHCP options [5] that
carry LDAP
information for the clients of the network. The first,
named LDAP
Servers Option, carries a list of preferred LDAP servers.
The other
one, named the base distinguished name (Base DN) option,
is used to
lookup information on the LDAP servers.
2. LDAP Servers Option
This option specifies one or more LDAP servers for the
client to
contact for accessing the directory. Servers SHOULD be
listed in
order of preference.
The code for this option is 95. The minimum length of
this option is
4 octets, and the length MUST be a multiple of 4. Note:
this option
is listed in [4], but has to be confirmed by IANA. See
IANA
Considerations for details.
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----
+--
| 95 | n | a1 | a2 | a3 | a4 | a1 | a2 |
a3 | a4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----
+--
G. Paterno’ draft-gpaterno-dhcp-ldap-00.txt
[Page 2]
Internet-Draft
July 2006
3. LDAP Base DN Option
This option specifies the Base DN that the client will
autoconfigure
for the directory lookups. Base DN option has to be
encoded in 7-bit
ASCII or base64 format [8], with a preference for the
first format
(whenever applicable). The dhcp client MUST implement
either formats.
The string should NOT be zero terminated.
The code for this option is [TBD]. The maximum possible
length for
this option is 255 bytes.
Code Len Base DN
+-----+----+----+----+----+----+--
| TBD | n | c1 | c2 | c3 | c4 | ...
+-----+----+----+----+----+----+--
4. Considerations on LDAP access
The Base DN is not always enough to lookup an entry in
the LDAP
directory, expecially when user authentication and
profiling (UID,
GID, ...) is involved. The LDAP directory might be
structured in
different ways in the organization and cannot be
determined in
advance. As such, whenever is not specified, for user
authentication/profiling the client SHOULD lookup
information as for
RFC-2307 [3], i.e.:
- Users SHOULD be under the "ou=People"
organizational unit;
- Groups SHOULD be under the "ou=Group"
organizational unit;
- Hosts SHOULD be under the "ou=Hosts"
organizational unit.
Geographically distributed environments SHOULD have a
different Base
DN for countries or locations and DHCP hosts in that
location SHOULD
receive LDAP Base DN accordingly, es: "dc=italy,
dc=example, dc=com".
This hierarchy is recommended, but not mandatory. The
client, be
either an authentication mechanism or a general lookup
(say an e-mail
client), may OPTIONALLY perform a subtree search of the
base DN.
5. Security Considerations
DHCP currently provides no authentication or security
mechanisms.
Potential exposures to attack are discussed in section 7
of the DHCP
protocol specification [5]. In particular, these DHCP
options allow
an unauthorized DHCP server to misdirect an LDAP client
to a
nonexistent LDAP server or even a spoofed LDAP server.
These threats
are similar to any DHCP options specified. Whenever any
potential
intruder might connect to the network (say for example in
a Wireless
environment), the author suggests to introduce IEEE
802.1x to enforce
G. Paterno’ draft-gpaterno-dhcp-ldap-00.txt
[Page 3]
Internet-Draft
July 2006
network access.
Moreover, it is suggested that any client should attempt
a StartTLS
[9] while accessing the specified LDAP servers, in order
to secure
LDAP communication.
7. IANA Considerations
IANA has assigned a value of 95 for the DHCP LDAP server
option
described in this document. However this option has been
recovered
[4] because no-one has published an RFC and therefore is
ready to be
reassigned: it has to be confirmed by IANA. Further, an
option for
LDAP Base DN has to be assigned.
6. References
[1] Wahl, M., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol
(v3)",
RFC-2251, December 1997.
[2] A. Gulbrandsen, P. Vixie,
"A DNS RR for specifying the location of
services (DNS SRV)",
RFC-2052, October 1996.
[3] L. Howard,
"An Approach for Using LDAP as a Network
Information Service",
RFC-2307, March 1998.
[4] R. Droms,
"Unused Dynamic Host Configuration Protocol
(DHCP) Option Codes",
RFC-3679, January 2004.
[5] Alexander, S. and R. Droms,
"DHCP Options and BOOTP Vendor
Extensions",
RFC-2132, March 1997.
[6] Bradner, S.,
"Key words for use in RFCs to Indicate
Requirement Levels",
RFC-2119, March 1997.
[7] Droms, R.,
"Dynamic Host Configuration Protocol",
RFC-2131, March 1997.
[8] S. Josefsson,
"The Base16, Base32, and Base64 Data
Encodings",
RFC-3548, July 2003
G. Paterno’ draft-gpaterno-dhcp-ldap-00.txt
[Page 4]
Internet-Draft
July 2006
[9] J. Hodges, R. Morgan, M. Wahl,
"Lightweight Directory Access Protocol (v3):
Extension for Transport Layer Security",
RFC-2830, May 2000
Copyright and disclaimer
Copyright (C) Giuseppe Paterno’ (2006). All Rights
Reserved.
This document is subject to the rights, licenses and
restrictions
contained in BCP 78, and except as set forth therein, the
authors
retain all their rights.
This document and translations of it may be copied and
furnished to
others, and derivative works that comment on or otherwise
explain it
or assist in its implementation may be prepared, copied,
published
and distributed, in whole or in part, without restriction
of any
kind, provided that the above copyright notice and this
paragraph are
included on all such copies and derivative works.
However, this
document itself may not be modified in any way, such as
by removing
the copyright notice or references to the author of this
document or
other Internet organizations, except as needed for the
purpose of
developing Internet standards in which case the
procedures for
copyrights defined in the Internet Standards process must
be
followed, or as required to translate it into languages
other than
English.
The limited permissions granted above are perpetual and
will not be
revoked by the author or its successors or assigns.
Disclaimer of Validity
This document and the information contained herein are
provided on an
"AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
7. Author’s Address
Giuseppe Paterno’
Casella Postale 27
20090 Trezzano Sul Naviglio (MI)
Italy
E-mail: gpaternogpaterno.com
G. Paterno’ draft-gpaterno-dhcp-ldap-00.txt
[Page 5]
_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg
|