external/bsd/openldap/dist/doc/drafts/draft-sermersheim-ldap-chaining-xx.txt

   1
   2 Internet Draft                                           J. Sermersheim
   3 Personal Submission                                         R. Harrison
   4 Intended Category: Standard Track                           Novell, Inc
   5 Document: draft-sermersheim-ldap-chaining-02.txt               Feb 2004
   6
   7
   8
   9                LDAP Control to Specify Chaining Behavior
  10
  11
  12 Status 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 other
  19    groups may also distribute working documents as Internet-Drafts.
  20    Internet-Drafts are draft documents valid for a maximum of six months
  21    and may be updated, replaced, or obsoleted by other documents at any
  22    time. It is inappropriate to use Internet-Drafts as reference
  23    material or to cite them other than as "work in progress."
  24
  25    The list of current Internet-Drafts can be accessed at
  26    http://www.ietf.org/ietf/1id-abstracts.txt
  27
  28    The list of Internet-Draft Shadow Directories can be accessed at
  29    http://www.ietf.org/shadow.html.
  30
  31    Distribution of this memo is unlimited. Technical discussion of this
  32    document will take place on the IETF LDAP Extensions Working Group
  33    mailing list <ldapext@ietf.org>. Editorial comments may be sent to
  34    the author <jimse@novell.com>.
  35
  36
  37 Abstract
  38
  39    This document describes a Lightweight Directory Access Protocol
  40    (LDAP) request control that allows specification of chaining behavior
  41    for LDAP operations. By using the control with various LDAP
  42    operations, a directory client (DUA), or directory server (DSA)
  43    specifies whether or not a DSA or secondary DSA chains operations to
  44    other DSAs or returns referrals and/or search result references to
  45    the client.
  46
  47
  48 1. Introduction
  49
  50    Many directory servers have the ability through the use of various
  51    mechanisms to participate in a distributed directory model. A
  52    distributed directory is one where the DIT is distributed over
  53    multiple DSAs. One operation completion mechanism used by DSAs in a
  54    distributed directory is chaining. Chaining is defined in [X.518],
  55    and is the act of one DSA communicating a directory operation that
  56
  57 Sermersheim, Harrison    Internet-Draft - Exp. Aug 2004         Page 1 \f
  58                LDAP Control to Specify Chaining Behavior
  59
  60    originated from a DUA to another DSA in a distributed directory.
  61    Contrast this with the act of passing referrals (4.1.11 of [RFC2251])
  62    and SearchResultReferences (4.5.2 of [RFC2251]) back to the client.
  63    Chaining may happen during the name resolution part of an operation
  64    or during other parts of operations like search which apply to a
  65    number of entries in a subtree.
  66
  67    This document does not attempt to define the distributed directory
  68    model, nor does it attempt to define the manner in which DSAs chain
  69    requests. This document defines a request control that the client can
  70    use to specify whether parts of an operation should or should not be
  71    chained.
  72
  73
  74 2. Conventions
  75
  76    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  77    used in this document carry the meanings described in [RFC2119].
  78
  79    The term chaining may apply to uni-chaining as well as multi-chaining
  80    (see [X.518]) depending on the capabilities and configuration of the
  81    DSAs.
  82
  83
  84 3. The Control
  85
  86    Support for the control is advertised by the presence of its
  87    controlType in the supportedControl attribute of a server's root DSE.
  88
  89    This control MAY be included in any LDAP request operation except
  90    abandon, unbind, and StartTLS as part of the controls field of the
  91    LDAPMessage, as defined in Section 4.1.12 of [RFC2251]:
  92
  93    The controlType is set to <IANA-ASSIGNED-OID.1>. The criticality MAY
  94    be set to either TRUE or FALSE. The controlValue is an OCTET STRING,
  95    whose value is the following ChainingBehavior type, BER encoded
  96    following the rules in Section 5.1 of [RFC2251]:
  97
  98    ChainingBehavior ::= SEQUENCE {
  99         resolveBehavior         Behavior OPTIONAL,
 100         continuationBehavior    Behavior OPTIONAL }
 101
 102    Behavior :: = ENUMERATED {
 103         chainingPreferred       (0),
 104         chainingRequired        (1),
 105         referralsPreferred      (2),
 106         referralsRequired       (3) }
 107
 108    resolveBehavior instructs the DSA what to do when a referral is
 109    encountered during the local name resolution part of an operation. If
 110    this field is not specified, other policy dictates the DSA's
 111    behavior.
 112
 113
 114
 115 Sermersheim, Harrison    Internet-Draft - Exp. Aug 2004         Page 2 \f
 116                LDAP Control to Specify Chaining Behavior
 117
 118    continuationBehavior instructs the DSA what to do when a referral is
 119    encountered after the name resolution part of an operation has
 120    completed. This scenario occurs during search operations, and may
 121    occur during yet to be defined future operations. If this field is
 122    not specified, other policy dictates the DSA's behavior.
 123
 124    Behavior specifies whether the DSA should chain the operation or
 125    return referrals when a target object is held by a remote service.
 126
 127         chainingPreferred indicates that the preference is that
 128         chaining, rather than referrals, be used to provide the service.
 129         When this value is set, the server attempts to chain the request
 130         but if it can't it returns referrals.
 131
 132         chainingRequired indicates that chaining is to be used rather
 133         than referrals to service the request. When this value is set,
 134         the server MUST NOT return referrals. It either chains the
 135         request or fails.
 136
 137         referralsPreferred indicates that the client wishes to receive
 138         referrals rather than allow the server to chain the operation.
 139         When this value is set, the server return referrals and search
 140         references when possible, but may chain the operation otherwise.
 141
 142         referralsRequired indicates that chaining is prohibited. When
 143         this value is set, the server MUST NOT chain the request to
 144         other DSAs. Instead it returns referrals as necessary, or fails.
 145
 146    The following list assigns meanings to some of the result codes that
 147    may occur due to this control being present:
 148
 149    - chainingRequired  (IANA-ASSIGNED-1)   Unable to process without
 150                                            chaining.
 151    - cannotChain       (IANA-ASSIGNED-2)   Unable to chain the request.
 152
 153
 154 4. Notes to Implementors
 155
 156    <todo: add some>
 157
 158
 159 4.1 Unbind and Abandon
 160
 161    Clients MUST NOT include the ChainingBehavior control with an Abandon
 162    operation or an Unbind operation. Servers MUST ignore any chaining
 163    control on the abandon and unbind requests. Servers that chain
 164    operation are responsible to keep track of where an operation was
 165    chained to for the purposes of unbind and abandon.
 166
 167
 168 4.2 StartTLS
 169
 170    This operation cannot be chained because the TLS handshake protocol
 171    does not allow man-in-the-middle attacks.
 172
 173 Sermersheim, Harrison    Internet-Draft - Exp. Aug 2004         Page 3 \f
 174                LDAP Control to Specify Chaining Behavior
 175
 176
 177
 178 5. Relationship with other Extensions
 179
 180    This control MAY be used with other controls or with extended
 181    operations. When it is used with other controls or with extended
 182    operations not listed here, server behavior is undefined unless
 183    otherwise specified.
 184
 185
 186 5.1 Relationship with ManageDsaIT
 187
 188    When this control is used along with the ManageDsaIT control, the
 189    resolveBehavior value is evaluated. If resolveBehavior is such that
 190    chaining is allowed, the DSA is allowed to chain the operation as
 191    necessary until the last RDN is found.
 192
 193    For example: DSA1 holds the naming context <dc=net> and a subordinate
 194    reference to <dc=example,dc=net>, DSA2 holds the naming context
 195    <dc=example,dc=net> and a subordinate reference to
 196    <dc=hostc,dc=example,dc=net>.
 197
 198    A modify operation accompanied by the ManageDsaIT control alone is
 199    sent to DSA1. The base object of the modify operation is set to
 200    <dc=hostc,dc=example,dc=net>. Since DSA1 does not hold the
 201    <dc=hostc,dc=example,dc=net> IT DSE, a referral is returned for
 202    <dc=example,dc=net>.
 203
 204    Next, the same modify operation is accompanied by both the
 205    ManageDsaIT and the ChainingBehavior control where the
 206    ChainingBehavior.resolveBehavior is set to chainingPreferred. In this
 207    case, DSA1 chains to DSA2 when it encounters <dc=example,dc=net> and
 208    DSA2 continues the operation. Since DSA2 holds the IT DSE
 209    <dc=hostc,dc=example,dc=net>, the resolve portion completes, and the
 210    rest of the operation proceeds.
 211
 212
 213 6. Security Considerations
 214
 215    Because this control directs a DSA to chain requests to other DSAs,
 216    it may be used in a denial of service attack. Implementers should be
 217    cognizant of this possibility.
 218
 219    This control may be used to allow access to hosts and portions of the
 220    DIT not normally available to clients. Servers supporting this
 221    control should provide sufficient policy to prevent unwanted
 222    occurrences of this.
 223
 224
 225 7. IANA Considerations
 226
 227    Registration of the following values is requested [RFC3383].
 228
 229
 230
 231 Sermersheim, Harrison    Internet-Draft - Exp. Aug 2004         Page 4 \f
 232                LDAP Control to Specify Chaining Behavior
 233
 234 7.1. Object Identifiers
 235
 236    It is requested that IANA register upon Standards Action an LDAP
 237    Object Identifier in identifying the protocol elements defined in
 238    this technical specification.  The following registration template is
 239    suggested:
 240
 241         Subject: Request for LDAP OID Registration
 242         Person & email address to contact for further information:
 243                 Jim Sermersheim
 244                 jimse@novell.com
 245         Specification: RFCXXXX
 246         Author/Change Controller: IESG
 247         Comments:
 248                 One delegation will be made under the assigned OID:
 249
 250                 IANA-ASSIGNED-OID.1 Chaining Behavior Request Control
 251
 252
 253 7.2. LDAP Protocol Mechanism
 254
 255    It is requested that IANA register upon Standards Action the LDAP
 256    protocol mechanism described in this document.  The following
 257    registration template is suggested:
 258
 259         Subject: Request for LDAP Protocol Mechanism Registration
 260         Object Identifier: IANA-ASSIGNED-OID.1
 261         Description: Chaining Behavior Request Control
 262         Person & email address to contact for further information:
 263                 Jim Sermersheim
 264                 jimse@novell.com
 265         Usage: Control
 266         Specification: RFCXXXX
 267         Author/Change Controller: IESG
 268         Comments: none
 269
 270
 271 7.3. LDAP Result Codes
 272
 273    It is requested that IANA register upon Standards Action the LDAP
 274    result codes:
 275
 276         chainingRequired        (IANA-ASSIGNED-1)
 277         cannotChain             (IANA-ASSIGNED-2)
 278
 279         The following registration template is suggested:
 280
 281         Subject: LDAP Result Code Registration
 282         Person & email address to contact for further information:
 283                 Jim Sermersheim
 284                 jimse@novell.com
 285         Result Code Name: chainingRequired
 286         Result Code Name: cannotChain
 287         Specification: RFCXXXX
 288
 289 Sermersheim, Harrison    Internet-Draft - Exp. Aug 2004         Page 5 \f
 290                LDAP Control to Specify Chaining Behavior
 291
 292         Author/Change Controller: IESG
 293         Comments:  request consecutive result codes be assigned
 294
 295
 296 8. Normative References
 297
 298    [X.518]
 299    ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
 300
 301    [RFC2119]
 302    Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement
 303    Levels", Internet Draft, March 1997.
 304    Available as RFC2119.
 305
 306    [RFC2251]
 307    Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access
 308    Protocol (v3)", Internet Standard, December, 1997.
 309    Available as RFC2251.
 310
 311
 312 9. Authors' Addresses
 313
 314    Jim Sermersheim
 315    Novell, Inc.
 316    1800 South Novell Place
 317    Provo, Utah 84606, USA
 318    jimse@novell.com
 319    +1 801 861-3088
 320
 321    Roger Harrison
 322    Novell, Inc.
 323    1800 South Novell Place
 324    Provo, Utah 84606, USA
 325    rharrison@novell.com
 326    +1 801 861-2642
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347 Sermersheim, Harrison    Internet-Draft - Exp. Aug 2004         Page 6 \f
 348                LDAP Control to Specify Chaining Behavior
 349
 350 Intellectual Property Rights
 351
 352      The IETF takes no position regarding the validity or scope of any
 353      intellectual property or other rights that might be claimed to
 354      pertain to the implementation or use of the technology described in
 355      this document or the extent to which any license under such rights
 356      might or might not be available; neither does it represent that it
 357      has made any effort to identify any such rights. Information on the
 358      IETF's procedures with respect to rights in standards-track and
 359      standards-related documentation can be found in BCP-11. Copies of
 360      claims of rights made available for publication and any assurances
 361      of licenses to be made available, or the result of an attempt made
 362      to obtain a general license or permission for the use of such
 363      proprietary rights by implementors or users of this specification
 364      can be obtained from the IETF Secretariat.
 365
 366      The IETF invites any interested party to bring to its attention any
 367      copyrights, patents or patent applications, or other proprietary
 368      rights which may cover technology that may be required to practice
 369      this standard. Please address the information to the IETF Executive
 370      Director.
 371
 372
 373 Full Copyright Statement
 374
 375      Copyright (C) The Internet Society (2004). All Rights Reserved.
 376
 377      This document and translations of it may be copied and furnished to
 378      others, and derivative works that comment on or otherwise explain
 379      it or assist in its implementation may be prepared, copied,
 380      published and distributed, in whole or in part, without restriction
 381      of any kind, provided that the above copyright notice and this
 382      paragraph are included on all such copies and derivative works.
 383      However, this document itself may not be modified in any way, such
 384      as by removing the copyright notice or references to the Internet
 385      Society or other Internet organizations, except as needed for the
 386      purpose of developing Internet standards in which case the
 387      procedures for copyrights defined in the Internet Standards process
 388      must be followed, or as required to translate it into languages
 389      other than English.
 390
 391      The limited permissions granted above are perpetual and will not be
 392      revoked by the Internet Society or its successors or assigns.
 393
 394      This document and the information contained herein is provided on
 395      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
 396      ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
 397      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 398      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 399      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 400
 401
 402
 403
 404
 405 Sermersheim, Harrison    Internet-Draft - Exp. Aug 2004         Page 7 \f
 406