1 2 3 4 5 6 7INTERNET-DRAFT Kurt D. Zeilenga 8Intended Category: Experimental Isode Limited 9Expires in six months 14 February 2007 10 11 12 13 The LDAP Relax Rules Control 14 <draft-zeilenga-ldap-relax-01.txt> 15 16 17Status of this Memo 18 19 This document is intended to be, after appropriate review and 20 revision, submitted to the RFC Editor for publication as an 21 Experimental document. Distribution of this memo is unlimited. 22 Technical discussion of this document will take place on the IETF LDAP 23 Extensions mailing list <ldapext@ietf.org>. Please send editorial 24 comments directly to the author <Kurt.Zeilenga@Isode.COM>. 25 26 This document replaces draft-zeilenga-ldap-managedit-xx.txt. 27 28 By submitting this Internet-Draft, each author represents that any 29 applicable patent or other IPR claims of which he or she is aware have 30 been or will be disclosed, and any of which he or she becomes aware 31 will be disclosed, in accordance with Section 6 of BCP 79. 32 33 Internet-Drafts are working documents of the Internet Engineering Task 34 Force (IETF), its areas, and its working groups. Note that other 35 groups may also distribute working documents as Internet-Drafts. 36 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference material 40 or to cite them other than as "work in progress." 41 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html. 44 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 47 48 49 Copyright (C) The IETF Trust (2007). All Rights Reserved. 50 51 Please see the Full Copyright section near the end of this document 52 for more information. 53 54 55 56 57 58Zeilenga LDAP Relax Rules Control [Page 1] 59 60INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 61 62 63Abstract 64 65 This document defines the Lightweight Directory Access Protocol (LDAP) 66 Relax Rules Control which allows a directory user agent (a client) to 67 request the directory service temporarily relax enforcement of various 68 data and service model rules. 69 70 711. Background and Intended Use 72 73 Directory servers accessible via Lightweight Directory Access Protocol 74 (LDAP) [RFC4510] are expected to act in accordance with the X.500 75 [X.500] series of ITU-T Recommendations. In particular, servers are 76 expected to ensure the X.500 data and service models are not violated. 77 78 An LDAP server is expected to prevent modification of the structural 79 object class of an object [RFC4512]. That is, the X.500 models do not 80 allow a 'person' object to be transformed into an 81 'organizationalPerson' object through modification of the object. 82 Instead, the 'person' object must be deleted and then a new 83 'organizationalPerson' object created in its place. This approach, 84 aside from being inconvient, is problematic for a number reasons. 85 First, as LDAP does not have a standardized method for performing the 86 two operations in a single transaction, the intermediate directory 87 state (after the delete, before the add) is visible to other clients, 88 which may lead to undesirable client behavior. Second, attributes 89 such as 'entryUUID' [RFC4530] will reflect the object was replaced, 90 not transformed. 91 92 An LDAP server is expected to prevent clients from modifying values of 93 NO-USER-MODIFICATION attributes [RFC4512]. For instance, an entry is 94 not allowed to assign or modify the value of the 'entryUUID' 95 attribute. However, where an administrator is restoring a previously 96 existing object, for instance when repartitioning data between 97 directory servers or when migrating from one vendor server product to 98 another, it may be desirable to allow the client to assign or modify 99 the value of the 'entryUUID' attribute. 100 101 This document defines the LDAP Relax Rules control. This control may 102 be attached to LDAP requests to update the Directory Information Tree 103 (DIT) to request various data and service rules be temporarily relaxed 104 during the performance of the requested DIT update. The server is 105 however to ensure the resulting directory state is valid. 106 107 Use of this control is expected that use of this extension will be 108 restricted by administrative and/or access controls. It is intended 109 to be used primarily by directory administrators. 110 111 112 113 114Zeilenga LDAP Relax Rules Control [Page 2] 115 116INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 117 118 119 This extension is considered experimental as it is not yet clear 120 whether it adequately addresses directory administrators' needs for 121 flexible mechanisms for managing directory objects. It is hoped that 122 after suitable amount of time, either this extension or a suitable 123 replacement will be standardization. 124 125 1261.1. Terminology 127 128 Protocol elements are described using ASN.1 [X.680] with implicit 129 tags. The term "BER-encoded" means the element is to be encoded using 130 the Basic Encoding Rules [X.690] under the restrictions detailed in 131 Section 5.1 of [RFC4511]. 132 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in BCP 14 [RFC2119]. 136 137 DSA stands for Directory System Agent, a server. DSE stands for 138 DSA-specific Entry. 139 140 1412. The Relax Rules Control 142 143 The Relax Rules control is an LDAP Control [RFC4511] whose controlType 144 is IANA-ASSIGNED-OID, controlValue is empty, and the criticality of 145 TRUE. 146 147 There is no corresponding response control. 148 149 The control is appropriate for all LDAP update requests, including 150 add, delete, modify, and modifyDN (rename) [RFC4511]. 151 152 The presence of the Rules Rules control in an LDAP update request 153 indicates the server temporarily relax X.500 model contraints during 154 performance of the directory update. 155 156 The server may restrict use of this control and/or limit the extent of 157 the relaxation provided based upon local policy or factors. 158 159 The server is obligated to ensure the resulting directory state is 160 consistent with the X.500 models. For instance, the server ensure 161 that values of attributes conform to the value syntax. 162 163 It is noted that while this extension may be used to add or modify 164 objects in a manner which violate the controlling subschema, the 165 presence of objects in the DIT is not inconsistent with the X.500 166 models. For instance, an object created prior to establshment of a 167 168 169 170Zeilenga LDAP Relax Rules Control [Page 3] 171 172INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 173 174 175 DIT content rule may contain an attribute now precluded by the current 176 controlling DIT Content Rule. 177 178 Servers implementing this technical specification SHOULD publish the 179 object identifier IANA-ASSIGNED-OID as a value of the 180 'supportedControl' attribute [RFC4512] in their root DSE. A server 181 MAY choose to advertise this extension only when the client is 182 authorized to use it. 183 184 1853. Use Cases 186 1873.1. Object metamorphism 188 189 In absence of this control, an attempt to modify an object's 190 'objectClass' in a manner which cause a change in the structural 191 object class of the object would normally lead to an 192 objectClassModsProhibited error [RFC4511]. The presence of the Relax 193 Rules control in the modify request requests the change be allowed. 194 If the server is willing and able to allow the change in the 195 structural object class of the object. 196 197 For instance, to change an 'organization' object into an 198 'organizationalUnit' object, a client could issue the following LDAP 199 request: 200 201 dn: o=Unit,dc=example,dc=net 202 control: IANA-ASSIGNED-OID 203 changetype: modify 204 delete: objectClass 205 objectClass: organization 206 - 207 add: objectClass 208 objectClass: organizationalUnit 209 - 210 211 In this case, the server is expected to either effect the requested 212 change in the structural object class, including updating of the value 213 of the structural object class, or fail the operation. 214 215 2163.2. Inactive Attribute Types 217 218 In absence of the Relax Rules control, an attempt to add or modify 219 values to an attribute whose type has been marked inactive in the 220 controlling subschema (its attribute type description contains the 221 OBSOLETE field) [RFC4512] normally results in a failure. 222 223 224 225 226Zeilenga LDAP Relax Rules Control [Page 4] 227 228INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 229 230 231 In the presence of the Relax Rules control, the server performs the 232 update operation as if the attribute's type is marked active in the 233 controlling subschema (its attribute type description does not contain 234 the OBSOLETE field). 235 236 2373.3. DIT Content Rules 238 239 In absence of the Relax Rules control, an attempt to include the name 240 (or OID) of an auxiliary class to an object's 'objectClass' which is 241 not allowed by the controlling DIT Content Rule would be disallowed 242 [RFC4512]. Additionally, an attempt to add values of an attribute 243 not allowed (or explicitly precluded) by the DIT Content Rule would 244 fail. 245 246 In presence of the Relax Rules control, the server performs the update 247 operation as if the controlling DIT Content Rule allowed any and all 248 known auxiliary classses to be present and allowed any and all known 249 attributes to be present (and precluded no attributes). 250 251 2523.4. DIT Structure Rules and Name Forms 253 254 In absence of the Relax Rules control, the service enforces DIT 255 structure rules and name form requirements of the controlling 256 subschema [RFC4512]. 257 258 In the presence of the Relax Rules control, the server performs the 259 update operation ignoring all DIT structure rules and name forms in 260 the controlling subschema. 261 262 2633.5. Modification of Nonconformant Objects 264 265 It is also noted that in absense of this control, modification of an 266 object which presently violates the controlling subschema will fail 267 unless the modification would result in the object conforming to the 268 controlling subschema. That is, modifications of an non-conformant 269 object should result in a conformant object. 270 271 In the presence of this control, modifications of a non-conformant 272 object need not result in a conformant object. 273 274 2753.6. NO-USER-MODIFICATION attribute modification 276 277 In absence of this control, an attempt to modify values of a 278 NO-USER-MODIFICATION attribute [RFC4512] would normally lead to a 279 280 281 282Zeilenga LDAP Relax Rules Control [Page 5] 283 284INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 285 286 287 constraintViolation or other appropriate error [RFC4511]. In the 288 presence of the Relax Rules control in the update request requests the 289 modification be allowed. 290 291 Relaxation of the NO-USER-MODIFICATION constraint is not appropriate 292 for some operational attribute types. For instance, as the value of 293 the 'structuralObjectClass' is derived by the values of the 294 'objectClass' attribute, the 'structuralObjectClass' attribute type's 295 NO-USER-MODIFICATION contraint MUST NOT be relaxed. To effect a 296 change in the structuralObjectClass class, values of objectClass 297 should be changed as discussed in Section 3.1. Other attributes for 298 which the NO-USER-MODIFICATION constraint should not be relaxed 299 include 'subschemaSubentry' [RFC4512] and 300 'collectiveAttributeSubentries' [RFC3671]. 301 302 The subsections of this section discuss modification of various 303 operational attributes where their NO-USER-MODIFICATION constraint may 304 be relaxed. Future documents may specify where NO-USER-MODIFICATION 305 constraints on other operational attribute may be relaxed. In absence 306 of a document detailing that the NO-USER-MODIFICATION constraint on a 307 particular operational attribute may be relaxed, implementors SHOULD 308 assume relaxation of the constraint is not appropriate for that 309 attribute. 310 311 3123.1.1. 'entryUUID' attribute 313 314 To provide a value for the 'entryUUID' [RFC4530] attribute on entry 315 creation, the client should issue an LDAP Add request with a Relax 316 Rules control providing the desired value. For instance: 317 318 dn: ou=Unit,dc=example,dc=net 319 control: IANA-ASSIGNED-OID 320 changetype: add 321 objectClass: organizationalUnit 322 ou: Unit 323 entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14 324 325 In this case, the server is either to add the entry using the 326 provided 'entryUUID' value or fail the request. 327 328 To provide a replacement value for the 'entryUUID' after entry 329 creation, the client should issue an LDAP Modify request with a 330 Relax Rules control including an approrpiate change. For instance: 331 332 dn: ou=Unit,dc=example,dc=net 333 control: IANA-ASSIGNED-OID 334 changetype: modify 335 336 337 338Zeilenga LDAP Relax Rules Control [Page 6] 339 340INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 341 342 343 replace: entryUUID 344 entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14 345 - 346 347 In this case, the server is either to replace the 'entryUUID' value 348 as requested or fail the request. 349 350 3513.2.2. createTimestamp 352 353 To provide a value for the 'createTimestamp' [RFC4512] attribute 354 on entry creation, the client should issue an LDAP Add request with 355 a Relax Rules control providing the desired 'createTimestamp' 356 value. For instance: 357 358 dn: ou=Unit,dc=example,dc=net 359 control: IANA-ASSIGNED-OID 360 changetype: add 361 objectClass: organizationalUnit 362 ou: Unit 363 createTimestamp: 20060101000000Z 364 365 In this case, the server is either to add the entry using the 366 provided 'createTimestamp' value or fail the request. 367 368 To provide a replacement value for the 'createTimestamp' after 369 entry creation, the client should issue an LDAP Modify request with 370 a Relax Rules control including an approrpiate change. For instance: 371 372 dn: ou=Unit,dc=example,dc=net 373 control: IANA-ASSIGNED-OID 374 changetype: modify 375 replace: createTimestamp 376 createTimestamp: 20060101000000Z 377 - 378 379 In this case, the server is either to replace the 'createTimestamp' 380 value as requested or fail the request. 381 382 The server should ensure the requested 'createTimestamp' value is 383 appropriate. In particular, it should fail the request if the 384 requested 'createTimestamp' value is in the future or is greater 385 than the value of the 'modifyTimestamp' attribute. 386 387 3883.2.3. modifyTimestamp 389 390 To provide a value for the 'modifyTimestamp' [RFC4512] attribute 391 392 393 394Zeilenga LDAP Relax Rules Control [Page 7] 395 396INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 397 398 399 on entry creation, the client should issue an LDAP Add request with 400 a Relax Rules control providing the desired 'modifyTimestamp' 401 value. For instance: 402 403 dn: ou=Unit,dc=example,dc=net 404 control: IANA-ASSIGNED-OID 405 changetype: add 406 objectClass: organizationalUnit 407 ou: Unit 408 modifyTimestamp: 20060101000000Z 409 410 In this case, the server is either to add the entry using 411 the provided 'modifyTimestamp' value or fail the request. 412 413 To provide a replacement value for the 'modifyTimestamp' after 414 entry creation, the client should issue an LDAP Modify 415 request with a Relax Rules control including an approrpiate 416 change. For instance: 417 418 dn: ou=Unit,dc=example,dc=net 419 control: IANA-ASSIGNED-OID 420 changetype: modify 421 replace: modifyTimestamp 422 modifyTimestamp: 20060101000000Z 423 - 424 425 In this case, the server is either to replace the 'modifyTimestamp' 426 value as requested or fail the request. 427 428 The server should ensure the requested 'modifyTimestamp' value is 429 appropriate. In particular, it should fail the request if the 430 requested 'modifyTimestamp' value is in the future or is less than 431 the value of the 'createTimestamp' attribute. 432 433 434 3.2.3. creatorsName and modifiersName 435 436 To provide a value for the 'creatorsName' and/or 'modifiersName' 437 [RFC4512] attribute on entry creation, the client should issue an 438 LDAP Add request with a Relax Rules control providing the desired 439 values. For instance: 440 441 dn: ou=Unit,dc=example,dc=net 442 control: IANA-ASSIGNED-OID 443 changetype: add 444 objectClass: organizationalUnit 445 ou: Unit 446 creatorsName: cn=Jane Doe,dc=example,net 447 448 449 450Zeilenga LDAP Relax Rules Control [Page 8] 451 452INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 453 454 455 modifiersName: cn=Jane Doe,dc=example,net 456 457 In this case, the server is either to add the entry using 458 the provided values or fail the request. 459 460 To provide a replacement values after entry creation for either of 461 the 'creatorsName' or 'modifiersName' attributes or both, the 462 client should issue an LDAP Modify request with a Relax Rules control 463 including the approrpiate changes. For instance: 464 465 dn: ou=Unit,dc=example,dc=net 466 control: IANA-ASSIGNED-OID 467 changetype: modify 468 replace: creatorsName 469 creatorsName: cn=Jane Doe,dc=example,net 470 - 471 replace: modifiersName 472 modifiersName: cn=Jane Doe,dc=example,net 473 - 474 475 In this case, the server is either to replace the provided 476 values as requested or fail the request. 477 478 4794. Security Considerations 480 481 Use of this extension should be subject to appropriate administrative 482 and access controls. Use of this mechanism is intended to be 483 restricted to directory administrators. 484 485 Security considerations for the base operations [RFC4511] extended 486 by this control, as well as general LDAP security considerations 487 [RFC4510], generally apply to implementation and use of this 488 extension. 489 490 4915. IANA Considerations 492 4935.1. Object Identifier 494 495 It is requested that the IANA assign a LDAP Object Identifier 496 [RFC4520] to identify the LDAP Relax Rules Control defined in this 497 document. 498 499 Subject: Request for LDAP Object Identifier Registration 500 Person & email address to contact for further information: 501 Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> 502 Specification: RFC XXXX 503 504 505 506Zeilenga LDAP Relax Rules Control [Page 9] 507 508INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 509 510 511 Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> 512 Comments: Identifies the LDAP Relax Rules Control 513 5145.2 LDAP Protocol Mechanism 515 516 Registration of this protocol mechanism [RFC4520] is requested. 517 518 Subject: Request for LDAP Protocol Mechanism Registration 519 Object Identifier: IANA-ASSIGNED-OID 520 Description: Relax Rules Control 521 Person & email address to contact for further information: 522 Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> 523 Usage: Control 524 Specification: RFC XXXX 525 Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> 526 Comments: none 527 528 5296. Author's Address 530 531 Kurt D. Zeilenga 532 Isode Limited 533 534 Email: Kurt.Zeilenga@Isode.COM 535 536 5377. References 538 539 [[Note to the RFC Editor: please replace the citation tags used in 540 referencing Internet-Drafts with tags of the form RFCnnnn where 541 possible.]] 542 543 5447.1. Normative References 545 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 548 549 [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671, 550 December 2003. 551 552 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 553 Road Map", RFC 4510, June 2006. 554 555 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 556 4511, June 2006. 557 558 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 559 560 561 562Zeilenga LDAP Relax Rules Control [Page 10] 563 564INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 565 566 567 Models", RFC 4512, June 2006. 568 569 [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol 570 (LDAP) entryUUID Operational Attribute", RFC 4530, June 571 2006. 572 573 [X.500] International Telecommunication Union - 574 Telecommunication Standardization Sector, "The Directory 575 -- Overview of concepts, models and services," 576 X.500(1993) (also ISO/IEC 9594-1:1994). 577 578 5797.2. Informative References 580 581 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 582 (IANA) Considerations for the Lightweight Directory 583 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006. 584 585 586 587Intellectual Property 588 589 The IETF takes no position regarding the validity or scope of any 590 Intellectual Property Rights or other rights that might be claimed to 591 pertain to the implementation or use of the technology described in 592 this document or the extent to which any license under such rights 593 might or might not be available; nor does it represent that it has 594 made any independent effort to identify any such rights. Information 595 on the procedures with respect to rights in RFC documents can be found 596 in BCP 78 and BCP 79. 597 598 Copies of IPR disclosures made to the IETF Secretariat and any 599 assurances of licenses to be made available, or the result of an 600 attempt made to obtain a general license or permission for the use of 601 such proprietary rights by implementers or users of this specification 602 can be obtained from the IETF on-line IPR repository at 603 http://www.ietf.org/ipr. 604 605 The IETF invites any interested party to bring to its attention any 606 copyrights, patents or patent applications, or other proprietary 607 rights that may cover technology that may be required to implement 608 this standard. Please address the information to the IETF at 609 ietf-ipr@ietf.org. 610 611 612 613Full Copyright 614 615 616 617 618Zeilenga LDAP Relax Rules Control [Page 11] 619 620INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007 621 622 623 Copyright (C) The IETF Trust (2007). 624 625 This document is subject to the rights, licenses and restrictions 626 contained in BCP 78, and except as set forth therein, the authors 627 retain all their rights. 628 629 This document and the information contained herein are provided on an 630 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 631 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 632 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 633 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 634 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674Zeilenga LDAP Relax Rules Control [Page 12] 675 676