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: gpaterno@gpaterno.com G. Paterno’ draft-gpaterno-dhcp-ldap-00.txt [Page 5]