]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc3088.txt
Fix prev commit
[openldap] / doc / rfc / rfc3088.txt
1
2
3
4
5
6
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 3088                           OpenLDAP Foundation
9 Category: Experimental                                        April 2001
10
11
12                          OpenLDAP Root Service
13                  An experimental LDAP referral service
14
15 Status of this Memo
16
17    This memo defines an Experimental Protocol for the Internet
18    community.  It does not specify an Internet standard of any kind.
19    Discussion and suggestions for improvement are requested.
20    Distribution of this memo is unlimited.
21
22 Copyright Notice
23
24    Copyright (C) The Internet Society (2001).  All Rights Reserved.
25
26 Abstract
27
28    The OpenLDAP Project is operating an experimental LDAP (Lightweight
29    Directory Access Protocol) referral service known as the "OpenLDAP
30    Root Service".  The automated system generates referrals based upon
31    service location information published in DNS SRV RRs (Domain Name
32    System location of services resource records).  This document
33    describes this service.
34
35 1. Background
36
37    LDAP [RFC2251] directories use a hierarchical naming scheme inherited
38    from X.500 [X500].  Traditionally, X.500 deployments have used a
39    geo-political naming scheme (e.g., CN=Jane
40    Doe,OU=Engineering,O=Example,ST=CA,C=US).  However, registration
41    infrastructure and location services in many portions of the naming
42    hierarchical are inadequate or nonexistent.
43
44    The construction of a global directory requires a robust registration
45    infrastructure and location service.  Use of Internet domain-based
46    naming [RFC2247] (e.g., UID=jdoe,DC=eng,DC=example,DC=net) allows
47    LDAP directory services to leverage the existing DNS [RFC1034]
48    registration infrastructure and DNS SRV [RFC2782] resource records
49    can be used to locate services [LOCATE].
50
51
52
53
54
55
56
57
58 Zeilenga                      Experimental                      [Page 1]
59 \f
60 RFC 3088                 OpenLDAP Root Service                April 2001
61
62
63 1.1.  The Glue
64
65    Most existing LDAP implementations do not support location of
66    directory services using DNS SRV resource records.  However, most
67    servers support generation of referrals to "superior" server(s).
68    This service provides a "root" LDAP service which servers may use as
69    their superior referral service.
70
71    Client may also use the service directly to locate services
72    associated with an arbitrary Distinguished Name [RFC2253] within the
73    domain based hierarchy.
74
75    Notice:
76      The mechanisms used by service are experimental.  The descriptions
77      provided by this document are not definitive.  Definitive
78      mechanisms shall be published in a Standard Track document(s).
79
80 2. Generating Referrals based upon DNS SRV RRs
81
82    This service returns referrals generated from DNS SRV resource
83    records [RFC2782].
84
85 2.1. DN to Domain Name Mapping
86
87    The service maps a DN [RFC2253] to a fully qualified domain name
88    using the following algorithm:
89
90        domain = null;
91        foreach RDN left-to-right        // [1]
92
93        {
94            if not multi-valued RDN and
95                RDN.type == domainComponent
96            {
97                if ( domain == null || domain == "." )
98                {   // start
99                    domain = "";
100                }
101                else
102                {   // append separator
103                    domain .= ".";
104                }
105
106                if ( RDN.value == "."  )
107                {   // root
108                    domain = ".";
109                }
110                else
111
112
113
114 Zeilenga                      Experimental                      [Page 2]
115 \f
116 RFC 3088                 OpenLDAP Root Service                April 2001
117
118
119                {   // append domainComponent
120                    domain .= RDN.value;
121                }
122                continue;
123            }
124            domain = null;
125        }
126
127    Examples:
128
129        Distinguished Name              Domain
130        -----------------------------   ------------
131        DC=example,DC=net               example.net
132        UID=jdoe,DC=example,DC=net      example.net
133        DC=.                            .            [2]
134        DC=example,DC=net,DC=.          .            [3]
135        DC=example,DC=.,DC=net          net          [4]
136        DC=example.net                  example.net  [5]
137        CN=Jane Doe,O=example,C=US      null
138        UID=jdoe,DC=example,C=US        null
139        DC=example,O=example,DC=net     net
140        DC=example+O=example,DC=net     net
141        DC=example,C=US+DC=net          null
142
143    Notes:
144
145    0) A later incarnation will use a Standard Track mechanism.
146
147    1) A later incarnation of this service may use a right-to-left
148       algorithm.
149
150    2) RFC 2247 does not state how one can map the domain representing
151       the root of the domain tree to a DN.  We suggest the root of the
152       domain tree be mapped to "DC=." and that this be reversable.
153
154    3) RFC 2247 states that domain "example.net" should be mapped to the
155       DN "DC=example,DC=net", not to "DC=example,DC=net,DC=.".  As it is
156       not our intent to introduce or support an alternative domain to DN
157       mapping, the algorithm ignores domainComponents to the left of
158       "DC=.".
159
160    4) RFC 2247 states that domain "example.net" should be mapped to the
161       DN "DC=example,DC=net", not to "DC=example,DC=.,DC=net".  As it is
162       not our intent to introduce or support an alternative domain to DN
163       mapping, the algorithm ignores domainComponents to the left of
164       "DC=." and "DC=." itself if further domainComponents are found to
165       the right.
166
167
168
169
170 Zeilenga                      Experimental                      [Page 3]
171 \f
172 RFC 3088                 OpenLDAP Root Service                April 2001
173
174
175    5) RFC 2247 states that value of an DC attribute type is a domain
176       component.  It should not contain multiple domain components.  A
177       later incarnation of this service may map this domain to null or
178       be coded to return invalid DN error.
179
180    If the domain is null or ".", the service aborts further processing
181    and returns noSuchObject.  Later incarnation of this service may
182    abort processing if the resulting domain is a top-level domain.
183
184 2.2. Locating LDAP services
185
186    The root service locates services associated with a given fully
187    qualified domain name by querying the Domain Name System for LDAP SRV
188    resource records.  For the domain example.net, the service would do a
189    issue a SRV query for the domain "_ldap._tcp.example.net".  A
190    successful query will return one or more resource records of the
191    form:
192
193      _ldap._tcp.example.net. IN SRV 0 0 389 ldap.example.net.
194
195    If no LDAP SRV resource records are returned or any DNS error occurs,
196    the service aborts further processing and returns noSuchObject.
197    Later incarnations of this service will better handle transient
198    errors.
199
200 2.3. Constructing an LDAP Referrals
201
202    For each DNS SRV resource record returned for the domain, a LDAP URL
203    [RFC2255] is constructed.  For the above resource record, the URL
204    would be:
205
206      ldap://ldap.example.net:389/
207
208    These URLs are then returned in the referral.  The URLs are currently
209    returned in resolver order.  That is, the server itself does not make
210    use of priority or weight information in the SRV resource records.  A
211    later incarnation of this service may.
212
213 3. Protocol Operations
214
215    This section describes how the service performs basic LDAP
216    operations.  The service supports operations extended through certain
217    controls as described in a later section.
218
219
220
221
222
223
224
225
226 Zeilenga                      Experimental                      [Page 4]
227 \f
228 RFC 3088                 OpenLDAP Root Service                April 2001
229
230
231 3.1. Basic Operations
232
233    Basic (add, compare, delete, modify, rename, search) operations
234    return a referral result if the target (or base) DN can be mapped to
235    a set of LDAP URLs as described above.  Otherwise a noSuchObject
236    response or other appropriate response is returned.
237
238 3.2. Bind Operation
239
240    The service accepts "anonymous" bind specifying version 2 or version
241    3 of the protocol.  All other bind requests will return a non-
242    successful resultCode.  In particular, clients which submit clear
243    text credentials will be sent an unwillingToPerform resultCode with a
244    cautionary text regarding providing passwords to strangers.
245
246    As this service is read-only, LDAPv3 authentication [RFC2829] is not
247    supported.
248
249 3.3. Unbind Operations
250
251    Upon receipt of an unbind request, the server abandons all
252    outstanding requests made by client and disconnects.
253
254 3.4. Extended Operations
255
256    The service currently does recognize any extended operation.  Later
257    incarnations of the service may support Start TLS [RFC2830] and other
258    operations.
259
260 3.5. Update Operations
261
262    A later incarnation of this service may return unwillingToPerform for
263    all update operations as this is an unauthenticated service.
264
265 4. Controls
266
267    The service supports the ManageDSAit control.  Unsupported controls
268    are serviced per RFC 2251.
269
270 4.1. ManageDSAit Control
271
272    The server recognizes and honors the ManageDSAit control [NAMEDREF]
273    provided with operations.
274
275    If DNS location information is available for the base DN itself, the
276    service will return unwillingToPerform for non-search operations.
277    For search operations, an entry will be returned if within scope and
278    matches the provided filter.  For example:
279
280
281
282 Zeilenga                      Experimental                      [Page 5]
283 \f
284 RFC 3088                 OpenLDAP Root Service                April 2001
285
286
287        c: searchRequest {
288            base="DC=example,DC=net"
289            scope=base
290            filter=(objectClass=*)
291            ManageDSAit
292        }
293
294        s: searchEntry {
295            dn: DC=example,DC=net
296            objectClass: referral
297            objectClass: extensibleObject
298            dc: example
299            ref: ldap://ldap.example.net:389/
300            associatedDomain: example.net
301        }
302        s: searchResult {
303            success
304        }
305
306    If DNS location information is available for the DC portion of a
307    subordinate entry, the service will return noSuchObject with the
308    matchedDN set to the DC portion of the base for search and update
309    operations.
310
311        c: searchRequest {
312            base="CN=subordinate,DC=example,DC=net"
313            scope=base
314            filter=(objectClass=*)
315            ManageDSAit
316        }
317
318        s: searchResult {
319            noSuchObject
320            matchedDN="DC=example,DC=net"
321        }
322
323 5. Using the Service
324
325    Servers may be configured to refer superior requests to
326    <ldap://root.openldap.org:389>.
327
328    Though clients may use the service directly, this is not encouraged.
329    Clients should use a local service and only use this service when
330    referred to it.
331
332    The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over
333    TCP/IPv4.  Future incarnations of this service may support TCP/IPv6
334    or other transport/internet protocols.
335
336
337
338 Zeilenga                      Experimental                      [Page 6]
339 \f
340 RFC 3088                 OpenLDAP Root Service                April 2001
341
342
343 6. Lessons Learned
344
345 6.1. Scaling / Reliability
346
347    This service currently runs on a single host.  This host and
348    associated network resources are not yet exhausted.  If they do
349    become exhausted, we believe we can easily scale to meet the demand
350    through common distributed load balancing technics.  The service can
351    also easily be duplicated locally.
352
353 6.2. Protocol interoperability
354
355    This service has able avoided known interoperability issues in
356    supporting variants of LDAP.
357
358 6.2.1. LDAPv3
359
360    The server implements all features of LDAPv3 [RFC2251] necessary to
361    provide the service.
362
363 6.2.2. LDAPv2
364
365    LDAPv2 [RFC1777] does not support the return of referrals and hence
366    may not be referred to this service.  Though a LDAPv2 client could
367    connect and issue requests to this service, the client would treat
368    any referral returned to it as an unknown error.
369
370 6.2.3. LDAPv2+
371
372    LDAPv2+ [LDAPv2+] provides a number of extensions to LDAPv2,
373    including referrals.  LDAPv2+, like LDAPv3, does not require a bind
374    operation before issuing of other operations.  As the referral
375    representation differ between LDAPv2+ and LDAPv3, the service returns
376    LDAPv3 referrals in this case.  However, as commonly deployed LDAPv2+
377    clients issue bind requests (for compatibility with LDAPv2 servers),
378    this has not generated any interoperability issues (yet).
379
380    A future incarnation of this service may drop support for LDAPv2+
381    (and LDAPv2).
382
383 6.2.4. CLDAP
384
385    CLDAP [RFC1798] does not support the return of referrals and hence is
386    not supported.
387
388
389
390
391
392
393
394 Zeilenga                      Experimental                      [Page 7]
395 \f
396 RFC 3088                 OpenLDAP Root Service                April 2001
397
398
399 7. Security Considerations
400
401    This service provides information to "anonymous" clients.  This
402    information is derived from the public directories, namely the Domain
403    Name System.
404
405    The use of authentication would require clients to disclose
406    information to the service.  This would be an unnecessary invasion of
407    privacy.
408
409    The lack of encryption allows eavesdropping upon client requests and
410    responses.  A later incarnation of this service may support
411    encryption (such as via Start TLS [RFC2830]).
412
413    Information integrity protection is not provided by the service.  The
414    service is subject to varies forms of DNS spoofing and attacks.  LDAP
415    session or operation integrity would provide false sense of security
416    concerning the integrity of DNS information.  A later incarnation of
417    this service may support DNSSEC and provide integrity protection (via
418    SASL, TLS, or IPSEC).
419
420    The service is subject to a variety of denial of service attacks.
421    The service is capable of blocking access by a number of factors.
422    This capability have yet to be used and likely would be ineffective
423    in preventing sophisticated attacks.  Later incarnations of this
424    service will likely need better protection from such attacks.
425
426 8. Conclusions
427
428    DNS is good glue.  By leveraging of the Domain Name System, global
429    LDAP directories may be built without requiring a protocol specific
430    registration infrastructures.
431
432    In addition, use of DNS service location allows global directories to
433    be built "ad hoc".  That is, anyone with a domain name can
434    participate.  There is no requirement that the superior domain
435    participate.
436
437 9. Additional Information
438
439    Additional information about the OpenLDAP Project and the OpenLDAP
440    Root Service can be found at <http://www.openldap.org/>.
441
442
443
444
445
446
447
448
449
450 Zeilenga                      Experimental                      [Page 8]
451 \f
452 RFC 3088                 OpenLDAP Root Service                April 2001
453
454
455 10. Author's Address
456
457    Kurt Zeilenga
458    OpenLDAP Foundation
459
460    EMail: kurt@openldap.org
461
462 11. Acknowledgments
463
464    Internet hosting for this experiment is provided by the Internet
465    Software Consortium <http://www.isc.org/>.  Computing resources were
466    provided by Net Boolean Incorporated <http://www.boolean.net/>.  This
467    experiment would not have been possible without the contributions of
468    numerous volunteers of the open source community.  Mechanisms
469    described in this document are based upon those introduced in
470    [RFC2247] and [LOCATE].
471
472 References
473
474    [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
475               STD 13, RFC 1034, November 1987.
476
477    [RFC1777]  Yeong, W., Howes, T. and S. Kille, "Lightweight Directory
478               Access Protocol", RFC 1777, March 1995.
479
480    [RFC1798]  Young, A., "Connection-less Lightweight Directory Access
481               Protocol", RFC 1798, June 1995.
482
483    [RFC2119]  Bradner, S., "Key Words for use in RFCs to Indicate
484               Requirement Levels", BCP 14, RFC 2119, March 1997.
485
486    [RFC2247]  Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
487               Sataluri, "Using Domains in LDAP/X.500 Distinguished
488               Names", RFC 2247, January 1998.
489
490    [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
491               Access Protocol (v3)", RFC 2251, December 1997.
492
493    [RFC2253]  Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
494               Access Protocol (v3): UTF-8 String Representation of
495               Distinguished Names", RFC 2253, December 1997.
496
497    [RFC2255]  Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
498               December 1997.
499
500    [RFC2782]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
501               specifying the location of services (DNS SRV)", RFC 2782,
502               February 2000.
503
504
505
506 Zeilenga                      Experimental                      [Page 9]
507 \f
508 RFC 3088                 OpenLDAP Root Service                April 2001
509
510
511    [RFC2829]  Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
512               "Authentication Methods for LDAP", RFC 2829, May 2000.
513
514    [RFC2830]  Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
515               Access Protocol (v3): Extension for Transport Layer
516               Security", RFC 2830, May 2000.
517
518    [LOCATE]   IETF LDAPext WG, "Discovering LDAP Services with DNS",
519               Work in Progress.
520
521    [LDAPv2+]  University of Michigan LDAP Team, "Referrals within the
522               LDAPv2 Protocol", August 1996.
523
524    [NAMEDREF] Zeilenga, K. (editor), "Named Subordinate References in
525               LDAP Directories", Work in Progress.
526
527    [X500]     ITU-T Rec. X.500, "The Directory: Overview of Concepts,
528               Models and Service",  1993.
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562 Zeilenga                      Experimental                     [Page 10]
563 \f
564 RFC 3088                 OpenLDAP Root Service                April 2001
565
566
567 Full Copyright Statement
568
569    Copyright (C) The Internet Society (2001).  All Rights Reserved.
570
571    This document and translations of it may be copied and furnished to
572    others, and derivative works that comment on or otherwise explain it
573    or assist in its implementation may be prepared, copied, published
574    and distributed, in whole or in part, without restriction of any
575    kind, provided that the above copyright notice and this paragraph are
576    included on all such copies and derivative works.  However, this
577    document itself may not be modified in any way, such as by removing
578    the copyright notice or references to the Internet Society or other
579    Internet organizations, except as needed for the purpose of
580    developing Internet standards in which case the procedures for
581    copyrights defined in the Internet Standards process must be
582    followed, or as required to translate it into languages other than
583    English.
584
585    The limited permissions granted above are perpetual and will not be
586    revoked by the Internet Society or its successors or assigns.
587
588    This document and the information contained herein is provided on an
589    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
590    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
591    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
592    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
593    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
594
595 Acknowledgement
596
597    Funding for the RFC Editor function is currently provided by the
598    Internet Society.
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618 Zeilenga                      Experimental                     [Page 11]
619 \f