1 2Internet Draft J. Sermersheim 3Personal Submission R. Harrison 4Intended Category: Standard Track Novell, Inc 5Document: draft-sermersheim-ldap-chaining-02.txt Feb 2004 6 7 8 9 LDAP Control to Specify Chaining Behavior 10 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 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 37Abstract 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 481. 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 57Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 1 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 742. 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 843. 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 115Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 2 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 1544. Notes to Implementors 155 156 <todo: add some> 157 158 1594.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 1684.2 StartTLS 169 170 This operation cannot be chained because the TLS handshake protocol 171 does not allow man-in-the-middle attacks. 172 173Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 3 174 LDAP Control to Specify Chaining Behavior 175 176 177 1785. 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 1865.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 2136. 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 2257. IANA Considerations 226 227 Registration of the following values is requested [RFC3383]. 228 229 230 231Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 4 232 LDAP Control to Specify Chaining Behavior 233 2347.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 2537.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 2717.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 289Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 5 290 LDAP Control to Specify Chaining Behavior 291 292 Author/Change Controller: IESG 293 Comments: request consecutive result codes be assigned 294 295 2968. 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 3129. 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 347Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 6 348 LDAP Control to Specify Chaining Behavior 349 350Intellectual 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 373Full 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 405Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 7 406 407