idnits 2.17.1 draft-zeilenga-ldap-txn-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 514. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (15 December 2008) is 5608 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- No information found for draft-zeilenga-ldap-noop-xx - is the name correct? -- No information found for draft-zeilenga-ldap-relax-xx - is the name correct? -- No information found for draft-zeilenga-ldap-dontusecopy-xx - is the name correct? Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Experimental Isode Limited 4 Expires in six months 15 December 2008 6 LDAP Transactions 7 9 Status of Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor for publication as an 13 Experimental RFC. Distribution of this memo is unlimited. Technical 14 discussion of this document will take place on the IETF LDAP 15 Extensions mailing list . Please send editorial 16 comments directly to the author . 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he or she becomes aware 21 will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright (C) The IETF Trust (2008). 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 45 Lightweight Directory Access Protocol (LDAP) update operations, such 46 as Add, Delete, and Modify operations, have atomic, consistency, 47 isolation, durability (ACID) properties. Each of these update 48 operations act upon an entry. It is often desirable to update two or 49 more entries in a single unit of interaction, a transaction. 50 Transactions are necessary to support a number of applications 51 including resource provisioning. This document extends LDAP to 52 support transactions. 54 1. Overview 56 This document extends the Lightweight Directory Access Protocol (LDAP) 57 [RFC4510] to allow clients to relate a number of update operations 58 [RFC4511] and have them performed as one unit of interaction, a 59 transaction. As with distinct update operations, each transaction has 60 atomic, consistency, isolation, and durability (ACID) properties 61 [ACID]. 63 This extension consists of two extended operations, one control, and 64 one unsolicited notification message. The Start Transaction operation 65 is used to obtain a transaction identifier. This identifier is then 66 attached to multiple update operations to indicate that they belong to 67 the transaction using the Transaction Specification control. The End 68 Transaction is used to settle (commit or abort) the transaction. The 69 Aborted Transaction Notice is provided by the server to notify the 70 client that the server is no longer willing or able to process an 71 outstanding transaction. 73 1.1. Conventions and Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 Protocol elements are described using ASN.1 [X.680] with implicit 80 tags. The term "BER-encoded" means the element is to be encoded using 81 the Basic Encoding Rules [X.690] under the restrictions detailed in 82 Section 5.1 of [RFC4511]. 84 DSA stands for "Directory System Agent" (a server). DSE stands for 85 "DSA-specific entry". 87 2. Elements of an LDAP Transaction 88 2.1. Start Transaction Request and Response 90 A Start Transaction Request is an LDAPMessage of CHOICE extendedReq 91 where the requestName is IANA-ASSIGNED-OID.1 and the requestValue is 92 absent. 94 A Start Transaction Response is an LDAPMessage of CHOICE extendedRes 95 sent in response to a Start Transaction Request. Its responseName is 96 absent. When the resultCode is success (0), responseValue is present 97 and contains a transaction identifier. Otherwise, the responseValue 98 is absent. 100 2.2. Transaction Specification Control 102 A Transaction Specification control is an LDAPControl where the 103 controlType is IANA-ASSIGNED-OID.2, the criticality is TRUE, and the 104 controlValue is a transaction identifier. The control is appropriate 105 for update requests including Add, Delete, Modify, and ModifyDN 106 (Rename) requests [RFC4511], as well as the Password Modify requests 107 [RFC3062]. 109 As discussed in Section 4, the Transaction Specification control can 110 be used in conjunction with request controls appropriate for the 111 update request. 113 2.3. End Transactions Request and Response 115 An End Transaction Request is an LDAPMessage of CHOICE extendedReq 116 where the requestName is IANA-ASSIGNED-OID.3 and the requestValue is 117 present and contains a BER-encoded txnEndReq. 119 txnEndReq ::= SEQUENCE { 120 commit BOOLEAN DEFAULT TRUE, 121 identifier OCTET STRING } 123 A commit value of TRUE indicates a request to commit the transaction 124 identified by the identifier. A commit value of FALSE indicates a 125 request to abort the identified transaction. 127 An End Transaction Response is an LDAPMessage sent in response to a 128 End Transaction Request. Its response name is absent. The 129 responseValue when present contains a BER-encoded txnEndRes. 131 txnEndRes ::= SEQUENCE { 132 messageID MessageID OPTIONAL, 133 -- msgid associated with non-success resultCode 135 updatesControls SEQUENCE OF updateControls SEQUENCE { 136 messageID MessageID, 137 -- msgid associated with controls 138 controls Controls 139 } OPTIONAL 140 } 141 -- where MessageID and Controls are as specified in RFC 4511 143 The txnEndRes.messageID provides the message id of the update request 144 associated with a non-success response. txnEndRes.messageID is absent 145 when resultCode of the End Transaction Response is success (0). 147 The txnEndRes.updatesControls provides a facility for returning 148 response controls that normally (i.e., in absence of transactions) 149 would be returned in an update response. The updateControls.messageID 150 provides the message id of the update request associated with the 151 response controls provided in updateControls.controls. 153 The txnEndRes.updatesControls is absent when there are no update 154 response controls to return. 156 If both txnEndRes.messageID and txnEndRes.updatesControl are absent, 157 the responseValue of the End Transaction Response is absent. 159 2.4. Aborted Transaction Notice 161 The Aborted Transaction Notice is an Unsolicited Notification message 162 where the responseName is IANA-ASSIGNED-OID.4 and responseValue is 163 present and contains a transaction identifier. 165 3. An LDAP Transaction 167 3.1. Extension Discovery 169 To allow clients to discover support for this extension, servers 170 implementing this specification SHOULD publish IANA-ASSIGNED-OID.1 and 171 IANA-ASSIGNED-OID.3 as values of the 'supportedExtension' attribute 172 [RFC4512] within the Root DSE, and publish the IANA-ASSIGNED-OID.2 as 173 a value of the 'supportedControl' attribute [RFC4512] of the Root DSE. 175 A server MAY choose to advertise this extension only when the client 176 is authorized to use it. 178 3.2. Starting a Transaction 179 A client wishing to perform a sequence of directory updates as an 180 transaction issues a Start Transaction Request. A server which is 181 willing and able to support transactions responds to this request with 182 a Start Transaction Response providing a transaction identifier and 183 with a resultCode of success (0). Otherwise, the server responds with 184 a Start Transaction Response with a result code other than success 185 indicating the nature of the failure. 187 The transaction identifier provided upon successful start of a 188 transaction is used in subsequent protocol messages to identify this 189 transaction. 191 3.3. Specification of a Transaction 193 The client then can issue one or more update requests, each with a 194 Transaction Specification control containing the transaction 195 identifier indicating the updates are to processed as part of the 196 transaction. Each of these update request MUST have a different 197 MessageID value. If the server is unwilling or unable to attempt to 198 process the requested update operation as part of the transaction, the 199 server immediately returns the appropriate response to the request 200 with a resultCode indicating the nature of the failure. Otherwise, 201 the server immediately returns success (0) and the defers further 202 processing of the operation is then deferred until settlement. 204 If the server becomes unwilling or unable to continue the 205 specification of a transaction, the server issues an Aborted 206 Transaction Notice with a non-success resultCode indicating the nature 207 of the failure. All operations that were to be processed as part of 208 the transaction are implicitly abandoned. Upon receipt of an Aborted 209 Transaction Notice, the client is to discontinue all use of the 210 transaction identifier as the transaction is null and void. Any 211 future use of identifier by the client will result in a response 212 containing a non-success resultCode. 214 3.4. Transaction Settlement 216 A client requests settlement of transaction by issuing an End 217 Transaction request for the transaction indicating whether it desires 218 the transaction to be committed or aborted. 220 Upon receipt of a request to abort the transaction, the server is to 221 abort the identified transaction (abandoning all operations which are 222 part of the transaction) and indicate that it has done so by returning 223 an End Transaction Response with a resultCode of success (0). 225 Upon receipt of a request to commit the transaction, the server 226 processes all update operations of the transaction as one atomic, 227 durable, isolated, and consistent action with each requested update 228 being processed in turn. Either all of the requested updates are to 229 be successfully applied or none of the requested are to be applied. 230 The server returns an End Transaction Response with a resultCode of 231 success (0) and no responseValue to indicate all the requested updates 232 were applied. Otherwise, the server returns an End Transaction with 233 an non-success resultCode indicating the nature of the failure. If 234 the failure is associated with a particular update request, the 235 txnEndRes.messageID in the responseValue is the messageID of this 236 update request. If the failure was not associated with any particular 237 update request, no txnEnd.messageID is provided. 239 There is no requirement that a server serialize transactions, or 240 updates requested outside of a transaction. That is, a server MAY 241 process multiple commit requests (from one or more clients) acting 242 upon different sets of entries concurrently. A server MUST avoid 243 deadlock. 245 3.5. Miscellaneous Issues 247 Transactions cannot be nested. 249 Each LDAP transaction should be initiated, specified, and settled 250 within a stable security context. Between the Start request and the 251 End response, the peers SHOULD avoid negotiating new security 252 associations and/or layers. 254 Upon receipt of a Bind or Unbind request, the server SHALL abort any 255 and all outstanding transactions without notice and nullify their 256 identifiers. 258 4. Interaction with Other Extensions 260 The LDAP Transaction extension may be used with many but not all LDAP 261 control extensions designed to extend Update (and possibly other) 262 operations. The remainder of this subsection discusses interaction 263 with a number of control extensions. Interaction with other control 264 extensions may be discussed in other documents, in particular in 265 control extension specifications. 267 4.1. Assertion Control 269 The Assertion [RFC4528] control is appropriate for use with update 270 requests specified as part of a transaction. The evaluation of the 271 assertion is performed as part of the transaction. 273 The Assertion control is inappropriate for use with either the 274 Transaction Start or End extended operations. 276 4.2. ManageDsaIT Control 278 The ManageDsaIT [RFC3296] control is appropriate for use with update 279 requests specified as part of a transaction. 281 The ManageDsaIT control is inappropriate for use with either the 282 Transaction Start or End extended operations. 284 4.3. No-Op Control 286 The No-Op [NO-OP] control is appropriate for use with the Transaction 287 Start or End extended operations. 289 The No-Op control is not appropriate for update requests specified as 290 part of a transaction. A server supporting both the No-Op control 291 extension and this extension SHALL regard a request containing both 292 controls as a protocol violation. As both of the No-Op and 293 Transaction Specification request controls are required to be marked 294 as critical, a server implementing one of these request controls, or 295 neither, is expected to return unavailableCriticalExtension as 296 prescribed by [RFC4511]. 298 4.4. Proxied Authorization Control 300 The Proxied Authorization [RFC4370] control is appropriate for use 301 with the Transaction Start extended operation, but not the Transaction 302 End extended operation or any update request specified as part of a 303 transaction. 305 To request that a transaction be performed under a different 306 authorization, the client provides a Proxied Authorization control 307 with the Transaction Start request. If the client is not authorized 308 to assume the requested authorization identity, the server is to 309 return the authorizationDenied (123) resultCode in its response. 310 Otherwise, further processing of the request and transaction is 311 performed under the requested authorization identity. 313 Any proxied authorization request attached to an update request 314 specified as part of a transaction, or attached to a Transaction end 315 request, is to be regarded as a protocol error. 317 4.5. Read Entry Controls 319 The Pre- and Post-Read Entry [RFC4527] request control are appropriate 320 for use with update requests specified as part of a transaction. 322 The response control produced in response to a Pre- or Post-Read Entry 323 request control is returned in the txnEndRes.updatesControls field of 324 responseValue of the End Transaction Response. 326 The Pre- and Post-Read Entry controls are inappropriate for use in the 327 LDAPMessage.controls field of the Transaction Start and End request 328 and response messages. 330 4.6. Relax Rules Control 332 The Relax Rules [RELAX] control is appropriate for use with update 333 requests specified as part of a transaction. 335 The Relax Rules control is inappropriate for use with either the 336 Transaction Start or End extended operations. 338 5. Distributed Directory Considerations 340 The LDAP/X.500 models provide for distributed directory operations, 341 including server-side chaining and client-side chasing of referrals. 343 This document does not preclude servers from chaining operations which 344 are part of a transaction. However, if a server does attempt such 345 chaining, it MUST ensure that transaction semantics are provided. 347 This mechanism defined by this document does not support client-side 348 chasing. Transaction identifiers are specific to a particular LDAP 349 association (as established via the LDAP Bind operation). 351 The LDAP/X.500 models provide for a single-master/multiple-shadow 352 replication architecture. There is no requirement that changes made 353 to the directory based upon processing a transaction be replicated as 354 one atomic action. Hence, clients SHOULD NOT assume tight data 355 consistency nor fast data convergence of shadow copies unless they 356 have prior knowledge that these properties are provided. Note that 357 DontUseCopy control [DONTUSECOPY] control may be used in conjunction 358 with the LDAP search request to ask for the return of the 359 authoritative copy of the entry. 361 6. Security Considerations 363 Transactions mechanisms may be the target of denial-of-service 364 attacks, especially where implementation lock shared resources for the 365 duration of a transaction. 367 General security considerations [RFC4510], especially those associated 368 with update operations [RFC4511], apply to this extension. 370 7. IANA Considerations 372 It is requested that Internet Assigned Numbers Authority (IANA) make 373 the following assignments. 375 7.1. Object Identifier 377 Assignment of an LDAP Object Identifier [RFC4520] to identify the 378 protocol elements specified in this document this document is 379 requested. 381 Subject: Request for LDAP Object Identifier Registration 382 Person & email address to contact for further information: 383 Kurt Zeilenga 384 Specification: RFC XXXX 385 Author/Change Controller: Kurt Zeilenga 386 Comments: Identifies protocol elements for LDAP Transactions 388 7.2. LDAP Protocol Mechanism 390 Registration of the protocol mechanisms [RFC4520] specified in this 391 document is requested. 393 Subject: Request for LDAP Protocol Mechanism Registration 394 Object Identifier: see table 395 Description: see table 396 Person & email address to contact for further information: 397 Kurt Zeilenga 398 Specification: RFC XXXX 399 Author/Change Controller: Kurt Zeilenga 400 Comments: 402 Object Identifier Type Description 403 ------------------- ---- ---------------------------------- 404 IANA-ASSIGNED-OID.1 E Start Transaction Extended Request 405 IANA-ASSIGNED-OID.2 C Transaction Specification Control 406 IANA-ASSIGNED-OID.3 E End Transaction Extended Request 407 IANA-ASSIGNED-OID.4 N Aborted Transaction Notice 409 Legend 410 ------------------------ 411 C => supportedControl 412 E => supportedExtension 413 N => Unsolicited Notice 415 8. Acknowledgments 417 The author gratefully acknowledges the contributions made by Internet 418 Engineering Task Force participants. 420 9. Author's Address 422 Kurt D. Zeilenga 423 Isode Limited 425 Email: Kurt.Zeilenga@Isode.COM 427 10. References 429 [[Note to the RFC Editor: please replace the citation tags used in 430 referencing Internet-Drafts with tags of the form RFCnnnn where 431 possible.]] 433 10.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 438 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 439 RFC 3062, February 2001. 441 [RFC3296] Zeilenga, K., "Named Subordinate References in 442 Lightweight Directory Access Protocol (LDAP) 443 Directories", RFC 3296, July 2002. 445 [RFC4370] Weltman, R., "LDAP Proxied Authentication Control", RFC 446 4370, Feb. 2006. 448 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 449 Road Map", RFC 4510, June 2006. 451 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 452 4511, June 2006. 454 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 455 Models", RFC 4512, June 2006. 457 [RFC4527] Zeilenga, K., "LDAP Read Entry Controls", RFC 4527, June 458 2006. 460 [RFC4528] Zeilenga, K., "LDAP Assertion Control", RFC 4528, June 461 2006. 463 [X.680] International Telecommunication Union - 464 Telecommunication Standardization Sector, "Abstract 465 Syntax Notation One (ASN.1) - Specification of Basic 466 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 468 [X.690] International Telecommunication Union - 469 Telecommunication Standardization Sector, "Specification 470 of ASN.1 encoding rules: Basic Encoding Rules (BER), 471 Canonical Encoding Rules (CER), and Distinguished 472 Encoding Rules (DER)", X.690(2002) (also ISO/IEC 473 8825-1:2002). 475 [NO-OP] Zeilenga, K., "LDAP No-Operation Control", draft- 476 zeilenga-ldap-noop-xx.txt, a work in progress. 478 [RELAX] Zeilenga, K., "LDAP Relax Rules Control", draft- 479 zeilenga-ldap-relax-xx.txt, a work in progress. 481 10.2. Informative References 483 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 484 (IANA) Considerations for the Lightweight Directory 485 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006. 487 [ACID] Section 4 of ISO/IEC 10026-1:1992. 489 [DONTUSECOPY] Zeilenga, K., "LDAP Don't Use Copy Control", draft- 490 zeilenga-ldap-dontusecopy-xx.txt, a work in progress. 492 Intellectual Property 494 The IETF takes no position regarding the validity or scope of any 495 Intellectual Property Rights or other rights that might be claimed to 496 pertain to the implementation or use of the technology described in 497 this document or the extent to which any license under such rights 498 might or might not be available; nor does it represent that it has 499 made any independent effort to identify any such rights. Information 500 on the procedures with respect to rights in RFC documents can be found 501 in BCP 78 and BCP 79. 503 Copies of IPR disclosures made to the IETF Secretariat and any 504 assurances of licenses to be made available, or the result of an 505 attempt made to obtain a general license or permission for the use of 506 such proprietary rights by implementers or users of this specification 507 can be obtained from the IETF on-line IPR repository at 508 http://www.ietf.org/ipr. 510 The IETF invites any interested party to bring to its attention any 511 copyrights, patents or patent applications, or other proprietary 512 rights that may cover technology that may be required to implement 513 this standard. Please address the information to the IETF at 514 ietf-ipr@ietf.org. 516 Full Copyright 518 Copyright (C) The IETF Trust (2008). 520 This document is subject to the rights, licenses and restrictions 521 contained in BCP 78, and except as set forth therein, the authors 522 retain all their rights. 524 This document and the information contained herein are provided on an 525 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 526 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 527 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 528 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 529 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 530 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.