external/bsd/openldap/dist/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