1 2 3INTERNET-DRAFT Michael P. Armijo 4<draft-ietf-ldapext-locate-08.txt> Levon Esibov 5June 5, 2002 Paul Leach 6Expires: December 5, 2002 Microsoft Corporation 7 R.L. Morgan 8 University of Washington 9 10 Discovering LDAP Services with DNS 11 12Status of this Memo 13 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 16 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 21 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 26 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 32 33 Distribution of this memo is unlimited. It is filed as <draft- 34 ietf-ldapext-locate-08.txt>, and expires on December 5, 2002. 35 Please send comments to the authors. 36 37 Copyright Notice 38 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 40 41 42Abstract 43 44 A Lightweight Directory Access Protocol (LDAP) request must be 45 directed to an appropriate server for processing. This document 46 specifies a method for discovering such servers using information in 47 the Domain Name System. 48 49 50 51 52 53 54 55 56 57Armijo, Esibov, Leach and Morgan [Page 1] 58 59INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002 60 61 62 631. Introduction 64 65 The LDAPv3 protocol [1] is designed to be a lightweight access 66 protocol for directory services supporting X.500 models. As a 67 distributed directory service, the complete set of directory 68 information (known as the Directory Information Base) is spread 69 across many different servers. Hence there is the need to 70 determine, when initiating or processing a request, which servers 71 hold the relevant information. In LDAP, the Search, Modify, Add, 72 Delete, ModifyDN, and Compare operations all specify a Distinguished 73 Name (DN) [2] on which the operation is performed. A client, or a 74 server acting on behalf of a client, must be able to determine the 75 server(s) that hold the naming context containing that DN, since 76 that server (or one of that set of servers) must receive and process 77 the request. This determination process is called "server 78 location". To support dynamic distributed operation, the 79 information needed to support server location must be available via 80 lookups done at request processing time, rather than, for example, 81 as static data configured into each client or server. 82 83 It is possible to maintain the information needed to support server 84 location in the directory itself, and X.500 directory deployments 85 typically do so. In practice, however, this only permits location 86 of servers within a limited X.500-connected set. LDAP-specific 87 methods of maintaining server location information in the directory 88 have not yet been standardized. This document defines an 89 alternative method of managing server location information using the 90 Domain Name System. This method takes advantage of the global 91 deployment of the DNS, by allowing LDAP server location information 92 for any existing DNS domain to be published by creating the records 93 described below. A full discussion of the benefits and drawbacks of 94 the various directory location and naming methods is beyond the 95 scope of this document. 96 97 RFC 2247[3] defines an algorithm for mapping DNS domain names into 98 DNs. This document defines the inverse mapping, from DNs to DNS 99 domain names, based on the conventions in [3], for use in this 100 server location method. The server location method described in 101 this document is only defined for DNs that can be so mapped, i.e., 102 those DNs that are based on domain names. In practice this is 103 reasonable because many objects of interest are named with domain 104 names, and use of domain-name-based DNs is becoming common. 105 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [9]. 109 110 111 112 113 114 115Armijo, Esibov, Leach and Morgan [Page 2] 116 117INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002 118 119 1202. Mapping Distinguished Names into Domain Names 121 122 This section defines a method of converting a DN into a DNS domain 123 name for use in the server location method described below. Some 124 DNs cannot be converted into a domain name. Converted DNs result 125 in a fully qualified domain name. 126 127 128 The output domain name is initially empty. The DN is processed in 129 right-to-left order (i.e., beginning with the first RDN in the 130 sequence of RDNs). An RDN is able to be converted if it (1) 131 consists of a single AttributeTypeAndValue; (2) the attribute type 132 is "DC"; and (3) the attribute value is non-null. If it can be 133 converted, the attribute value is used as a domain name component 134 (label). The first such value becomes the rightmost (i.e., most 135 significant) domain name component, and successive converted RDN 136 values extend to the left. If an RDN cannot be converted, 137 processing stops. If the output domain name is empty when 138 processing stops, the DN cannot be converted into a domain name. 139 140 For DN: 141 142 cn=John Doe,ou=accounting,dc=example,dc=net 143 144 The client would convert the DC components as defined above into 145 DNS name: 146 147 example.net 148 149 The determined DNS name will be submitted as a DNS query using the 150 algorithm defined in section 3. 151 152 153 1543. Locating LDAPv3 servers through DNS 155 156 LDAPv3 server location information is to be stored using DNS Service 157 Location Record (SRV)[5]. The data in a SRV record contains the DNS 158 name of the server that provides the LDAP service, corresponding 159 Port number, and parameters that enable the client to choose an 160 appropriate server from multiple servers according to the algorithm 161 described in [5]. The name of this record has the following format: 162 163 _<Service>._<Proto>.<Domain>. 164 165 where <Service> is "ldap", and <Proto> is "tcp". <Domain> is the 166 domain name formed by converting the DN of a naming context mastered 167 by the LDAP Server into a domain name using the algorithm in 168 Section 2. Note that "ldap" is the symbolic name for the LDAP 169 service in Assigned Numbers[6], as required by [5]. 170 171 172 173Armijo, Esibov, Leach and Morgan [Page 3] 174 175INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002 176 177 178 Presence of such records enables clients to find the LDAP servers 179 using standard DNS query [4]. A client (or server) seeking an LDAP 180 server for a particular DN converts that DN to a domain name using 181 the algorithm of Section 2, does a SRV record query using the DNS 182 name formed as described in the preceding paragraph, and interprets 183 the response as described in [5] to determine a host (or hosts) to 184 contact. As an example, a client that searches for an LDAP server 185 for the DN "ou=foo,dc=example,dc=net" that supports the TCP protocol 186 will submit a DNS query for a set of SRV records with owner name: 187 188 _ldap._tcp.example.net. 189 190 The client will receive the list of SRV records published in DNS 191 that satisfy the requested criteria. The following is an example of 192 such a record: 193 194 _ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net. 195 196 The set of returned records may contain multiple records in the case 197 where multiple LDAP servers serve the same domain. If there are no 198 matching SRV records available for the converted DN the client SHOULD 199 NOT attempt to 'walk the tree' by removing the least significant 200 portion of the constructed fully qualified domain name. 201 202 2034. IANA Considerations 204 205 This document does not require any IANA actions. 206 207 2085. Security Considerations 209 210 DNS responses can typically be easily spoofed. Clients using this 211 location method SHOULD ensure, via use of strong security 212 mechanisms, that the LDAP server they contact is the one they 213 intended to contact. See [7] for more information on security 214 threats and security mechanisms. 215 216 When using LDAP with TLS the client MUST check the server's name, 217 as described in section 3.6 of [RFC 2830]. As specified there, the 218 name the client checks for is the server's name before any 219 potentially insecure transformations, including the SRV record 220 lookup specified in this memo. Thus the name the client MUST check 221 for is the name obtained by doing the mapping step defined in 222 section 2 above. For example, if the DN "cn=John 223 Doe,ou=accounting,dc=example,dc=net" is converted to the DNS name 224 "example.net", the server's name MUST match "example.net". 225 226 This document describes a method that uses DNS SRV records to 227 discover LDAP servers. All security considerations related to DNS 228 SRV records are inherited by this document. See the security 229 considerations section in [5] for more details. 230 231Armijo, Esibov, Leach and Morgan [Page 4] 232 233INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002 234 235 2366. References 237 238 [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 239 Protocol(v3)", RFC 2251, December 1997. 240 241 [2] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access 242 Protocol (v3): UTF-8 String Representation of Distinguished 243 Names", RFC 2253, December 1997. 244 245 [3] Kille, S. and M. Wahl, "Using Domains in LDAP/X.500 246 Distinguished Names", RFC 2247, January 1998. 247 248 [4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 249 1034, STD 13, November 1987. 250 251 [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 252 specifying the location of services (DNS SRV)", RFC 2782, 253 February 2000. 254 255 [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 256 1700, October 1994. 257 258 [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R., 259 "Authentication Methods for LDAP", RFC 2829, May 2000. 260 261 [8] Hodges, J., Morgan, R., Wahl, M., "Lightweight Directory Access 262 Protocol (v3): Extension for Transport Layer Security", 263 RFC 2830, May 2000. 264 265 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 266 Levels", BCP 14, RFC 2119, March 1997. 267 268 269 270 2717. Authors' Addresses 272 273 Michael P. Armijo 274 One Microsoft Way 275 Redmond, WA 98052 276 micharm@microsoft.com 277 278 Paul Leach 279 One Microsoft Way 280 Redmond, WA 98052 281 paulle@microsoft.com 282 283 Levon Esibov 284 One Microsoft Way 285 Redmond, WA 98052 286 levone@microsoft.com 287 288 289Armijo, Esibov, Leach and Morgan [Page 5] 290 291INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002 292 293 RL "Bob" Morgan 294 University of Washington 295 4545 15th Ave NE 296 Seattle, WA 98105 297 US 298 299 Phone: +1 206 221 3307 300 EMail: rlmorgan@washington.edu 301 URI: http://staff.washington.edu/rlmorgan/ 302 303 3048. Intellectual Property Statement 305 306The IETF takes no position regarding the validity or scope of any 307intellectual property or other rights that might be claimed to pertain 308to the implementation or use of the technology described in this 309document or the extent to which any license under such rights might or 310might not be available; neither does it represent that it has made any 311effort to identify any such rights. Information on the IETF's 312procedures with respect to rights in standards-track and standards- 313related documentation can be found in BCP-11. Copies of claims of 314rights made available for publication and any assurances of licenses to 315be made available, or the result of an attempt made to obtain a general 316license or permission for the use of such proprietary rights by 317implementors or users of this specification can be obtained from the 318IETF Secretariat. 319 320The IETF invites any interested party to bring to its attention any 321copyrights, patents or patent applications, or other proprietary rights 322which may cover technology that may be required to practice this 323standard. Please address the information to the IETF Executive 324Director. 325 326 3279. Full Copyright Statement 328 329Copyright (C) The Internet Society (2001). All Rights Reserved. 330This document and translations of it may be copied and furnished to 331others, and derivative works that comment on or otherwise explain it or 332assist in its implementation may be prepared, copied, published and 333distributed, in whole or in part, without restriction of any kind, 334provided that the above copyright notice and this paragraph are included 335on all such copies and derivative works. However, this document itself 336may not be modified in any way, such as by removing the copyright notice 337or references to the Internet Society or other Internet organizations, 338except as needed for the purpose of developing Internet standards in 339which case the procedures for copyrights defined in the Internet 340Standards process must be followed, or as required to translate it into 341languages other than English. The limited permissions granted above are 342perpetual and will not be revoked by the Internet Society or its 343successors or assigns. This document and the information contained 344herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 345 346 347Armijo, Esibov, Leach and Morgan [Page 6] 348 349INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002 350 351INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 352IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 353INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 354WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 355 356 35710. Expiration Date 358 359 This document is filed as <draft-ietf-ldapext-locate-08.txt>, and 360 expires December 5, 2002. 361 362Armijo, Esibov, Leach and Morgan [Page 7]