idnits 2.17.1 draft-zeilenga-ldap-relax-03.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 498. 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 (13 July 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 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 13 July 2008 6 The LDAP Relax Rules Control 7 9 Status of this 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 document. Distribution of this memo is unlimited. 14 Technical 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 This document replaces draft-zeilenga-ldap-managedit-xx.txt. 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware have 22 been or will be disclosed, and any of which he or she becomes aware 23 will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering Task 26 Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference material 32 or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright (C) The IETF Trust (2008). 42 Please see the Full Copyright section near the end of this document 43 for more information. 45 Abstract 47 This document defines the Lightweight Directory Access Protocol (LDAP) 48 Relax Rules Control which allows a directory user agent (a client) to 49 request the directory service temporarily relax enforcement of various 50 data and service model rules. 52 1. Background and Intended Use 54 Directory servers accessible via Lightweight Directory Access Protocol 55 (LDAP) [RFC4510] are expected to act in accordance with the X.500 56 [X.500] series of ITU-T Recommendations. In particular, servers are 57 expected to ensure the X.500 data and service models are not violated. 59 An LDAP server is expected to prevent modification of the structural 60 object class of an object [RFC4512]. That is, the X.500 models do not 61 allow a 'person' object to be transformed into an 62 'organizationalPerson' object through modification of the object. 63 Instead, the 'person' object must be deleted and then a new 64 'organizationalPerson' object created in its place. This approach, 65 aside from being inconvient, is problematic for a number reasons. 66 First, as LDAP does not have a standardized method for performing the 67 two operations in a single transaction, the intermediate directory 68 state (after the delete, before the add) is visible to other clients, 69 which may lead to undesirable client behavior. Second, attributes 70 such as 'entryUUID' [RFC4530] will reflect the object was replaced, 71 not transformed. 73 An LDAP server is expected to prevent clients from modifying values of 74 NO-USER-MODIFICATION attributes [RFC4512]. For instance, an entry is 75 not allowed to assign or modify the value of the 'entryUUID' 76 attribute. However, where an administrator is restoring a previously 77 existing object, for instance when repartitioning data between 78 directory servers or when migrating from one vendor server product to 79 another, it may be desirable to allow the client to assign or modify 80 the value of the 'entryUUID' attribute. 82 This document defines the LDAP Relax Rules control. This control may 83 be attached to LDAP requests to update the Directory Information Tree 84 (DIT) to request various data and service rules be temporarily relaxed 85 during the performance of the requested DIT update. The server is 86 however to ensure the resulting directory state is valid. 88 Use of this control is expected that use of this extension will be 89 restricted by administrative and/or access controls. It is intended 90 to be used primarily by directory administrators. 92 This extension is considered experimental as it is not yet clear 93 whether it adequately addresses directory administrators' needs for 94 flexible mechanisms for managing directory objects. It is hoped that 95 after suitable amount of time, either this extension or a suitable 96 replacement will be standardization. 98 1.1. Terminology 100 Protocol elements are described using ASN.1 [X.680] with implicit 101 tags. The term "BER-encoded" means the element is to be encoded using 102 the Basic Encoding Rules [X.690] under the restrictions detailed in 103 Section 5.1 of [RFC4511]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 DSA stands for Directory System Agent, a server. DSE stands for 110 DSA-specific Entry. 112 2. The Relax Rules Control 114 The Relax Rules control is an LDAP Control [RFC4511] whose controlType 115 is IANA-ASSIGNED-OID, controlValue is empty, and the criticality of 116 TRUE. 118 There is no corresponding response control. 120 The control is appropriate for all LDAP update requests, including 121 add, delete, modify, and modifyDN (rename) [RFC4511]. 123 The presence of the Rules Rules control in an LDAP update request 124 indicates the server temporarily relax X.500 model contraints during 125 performance of the directory update. 127 The server may restrict use of this control and/or limit the extent of 128 the relaxation provided based upon local policy or factors. 130 The server is obligated to ensure the resulting directory state is 131 consistent with the X.500 models. For instance, the server ensure 132 that values of attributes conform to the value syntax. 134 It is noted that while this extension may be used to add or modify 135 objects in a manner which violate the controlling subschema, the 136 presence of objects in the DIT is not inconsistent with the X.500 137 models. For instance, an object created prior to establshment of a 138 DIT content rule may contain an attribute now precluded by the current 139 controlling DIT Content Rule. 141 Servers implementing this technical specification SHOULD publish the 142 object identifier IANA-ASSIGNED-OID as a value of the 143 'supportedControl' attribute [RFC4512] in their root DSE. A server 144 MAY choose to advertise this extension only when the client is 145 authorized to use it. 147 3. Use Cases 149 3.1. Object metamorphism 151 In absence of this control, an attempt to modify an object's 152 'objectClass' in a manner which cause a change in the structural 153 object class of the object would normally lead to an 154 objectClassModsProhibited error [RFC4511]. The presence of the Relax 155 Rules control in the modify request requests the change be allowed. 156 If the server is willing and able to allow the change in the 157 structural object class of the object. 159 For instance, to change an 'organization' object into an 160 'organizationalUnit' object, a client could issue the following LDAP 161 request: 163 dn: o=Unit,dc=example,dc=net 164 control: IANA-ASSIGNED-OID 165 changetype: modify 166 delete: objectClass 167 objectClass: organization 168 - 169 add: objectClass 170 objectClass: organizationalUnit 171 - 173 In this case, the server is expected to either effect the requested 174 change in the structural object class, including updating of the value 175 of the structural object class, or fail the operation. 177 3.2. Inactive Attribute Types 179 In absence of the Relax Rules control, an attempt to add or modify 180 values to an attribute whose type has been marked inactive in the 181 controlling subschema (its attribute type description contains the 182 OBSOLETE field) [RFC4512] normally results in a failure. 184 In the presence of the Relax Rules control, the server performs the 185 update operation as if the attribute's type is marked active in the 186 controlling subschema (its attribute type description does not contain 187 the OBSOLETE field). 189 3.3. DIT Content Rules 191 In absence of the Relax Rules control, an attempt to include the name 192 (or OID) of an auxiliary class to an object's 'objectClass' which is 193 not allowed by the controlling DIT Content Rule would be disallowed 194 [RFC4512]. Additionally, an attempt to add values of an attribute 195 not allowed (or explicitly precluded) by the DIT Content Rule would 196 fail. 198 In presence of the Relax Rules control, the server performs the update 199 operation as if the controlling DIT Content Rule allowed any and all 200 known auxiliary classses to be present and allowed any and all known 201 attributes to be present (and precluded no attributes). 203 3.4. DIT Structure Rules and Name Forms 205 In absence of the Relax Rules control, the service enforces DIT 206 structure rules and name form requirements of the controlling 207 subschema [RFC4512]. 209 In the presence of the Relax Rules control, the server performs the 210 update operation ignoring all DIT structure rules and name forms in 211 the controlling subschema. 213 3.5. Modification of Nonconformant Objects 215 It is also noted that in absense of this control, modification of an 216 object which presently violates the controlling subschema will fail 217 unless the modification would result in the object conforming to the 218 controlling subschema. That is, modifications of an non-conformant 219 object should result in a conformant object. 221 In the presence of this control, modifications of a non-conformant 222 object need not result in a conformant object. 224 3.6. NO-USER-MODIFICATION attribute modification 226 In absence of this control, an attempt to modify values of a 227 NO-USER-MODIFICATION attribute [RFC4512] would normally lead to a 228 constraintViolation or other appropriate error [RFC4511]. In the 229 presence of the Relax Rules control in the update request requests the 230 modification be allowed. 232 Relaxation of the NO-USER-MODIFICATION constraint is not appropriate 233 for some operational attribute types. For instance, as the value of 234 the 'structuralObjectClass' is derived by the values of the 235 'objectClass' attribute, the 'structuralObjectClass' attribute type's 236 NO-USER-MODIFICATION contraint MUST NOT be relaxed. To effect a 237 change in the structuralObjectClass class, values of objectClass 238 should be changed as discussed in Section 3.1. Other attributes for 239 which the NO-USER-MODIFICATION constraint should not be relaxed 240 include 'subschemaSubentry' [RFC4512] and 241 'collectiveAttributeSubentries' [RFC3671]. 243 The subsections of this section discuss modification of various 244 operational attributes where their NO-USER-MODIFICATION constraint may 245 be relaxed. Future documents may specify where NO-USER-MODIFICATION 246 constraints on other operational attribute may be relaxed. In absence 247 of a document detailing that the NO-USER-MODIFICATION constraint on a 248 particular operational attribute may be relaxed, implementors SHOULD 249 assume relaxation of the constraint is not appropriate for that 250 attribute. 252 3.1.1. 'entryUUID' attribute 254 To provide a value for the 'entryUUID' [RFC4530] attribute on entry 255 creation, the client should issue an LDAP Add request with a Relax 256 Rules control providing the desired value. For instance: 258 dn: ou=Unit,dc=example,dc=net 259 control: IANA-ASSIGNED-OID 260 changetype: add 261 objectClass: organizationalUnit 262 ou: Unit 263 entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14 265 In this case, the server is either to add the entry using the 266 provided 'entryUUID' value or fail the request. 268 To provide a replacement value for the 'entryUUID' after entry 269 creation, the client should issue an LDAP Modify request with a 270 Relax Rules control including an approrpiate change. For instance: 272 dn: ou=Unit,dc=example,dc=net 273 control: IANA-ASSIGNED-OID 274 changetype: modify 275 replace: entryUUID 276 entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14 277 - 279 In this case, the server is either to replace the 'entryUUID' value 280 as requested or fail the request. 282 3.2.2. createTimestamp 284 To provide a value for the 'createTimestamp' [RFC4512] attribute 285 on entry creation, the client should issue an LDAP Add request with 286 a Relax Rules control providing the desired 'createTimestamp' 287 value. For instance: 289 dn: ou=Unit,dc=example,dc=net 290 control: IANA-ASSIGNED-OID 291 changetype: add 292 objectClass: organizationalUnit 293 ou: Unit 294 createTimestamp: 20060101000000Z 296 In this case, the server is either to add the entry using the 297 provided 'createTimestamp' value or fail the request. 299 To provide a replacement value for the 'createTimestamp' after 300 entry creation, the client should issue an LDAP Modify request with 301 a Relax Rules control including an approrpiate change. For instance: 303 dn: ou=Unit,dc=example,dc=net 304 control: IANA-ASSIGNED-OID 305 changetype: modify 306 replace: createTimestamp 307 createTimestamp: 20060101000000Z 308 - 310 In this case, the server is either to replace the 'createTimestamp' 311 value as requested or fail the request. 313 The server should ensure the requested 'createTimestamp' value is 314 appropriate. In particular, it should fail the request if the 315 requested 'createTimestamp' value is in the future or is greater 316 than the value of the 'modifyTimestamp' attribute. 318 3.2.3. modifyTimestamp 320 To provide a value for the 'modifyTimestamp' [RFC4512] attribute 321 on entry creation, the client should issue an LDAP Add request with 322 a Relax Rules control providing the desired 'modifyTimestamp' 323 value. For instance: 325 dn: ou=Unit,dc=example,dc=net 326 control: IANA-ASSIGNED-OID 327 changetype: add 328 objectClass: organizationalUnit 329 ou: Unit 330 modifyTimestamp: 20060101000000Z 332 In this case, the server is either to add the entry using 333 the provided 'modifyTimestamp' value or fail the request. 335 To provide a replacement value for the 'modifyTimestamp' after 336 entry creation, the client should issue an LDAP Modify 337 request with a Relax Rules control including an approrpiate 338 change. For instance: 340 dn: ou=Unit,dc=example,dc=net 341 control: IANA-ASSIGNED-OID 342 changetype: modify 343 replace: modifyTimestamp 344 modifyTimestamp: 20060101000000Z 345 - 347 In this case, the server is either to replace the 'modifyTimestamp' 348 value as requested or fail the request. 350 The server should ensure the requested 'modifyTimestamp' value is 351 appropriate. In particular, it should fail the request if the 352 requested 'modifyTimestamp' value is in the future or is less than 353 the value of the 'createTimestamp' attribute. 355 3.2.3. creatorsName and modifiersName 357 To provide a value for the 'creatorsName' and/or 'modifiersName' 358 [RFC4512] attribute on entry creation, the client should issue an 359 LDAP Add request with a Relax Rules control providing the desired 360 values. For instance: 362 dn: ou=Unit,dc=example,dc=net 363 control: IANA-ASSIGNED-OID 364 changetype: add 365 objectClass: organizationalUnit 366 ou: Unit 367 creatorsName: cn=Jane Doe,dc=example,net 368 modifiersName: cn=Jane Doe,dc=example,net 370 In this case, the server is either to add the entry using 371 the provided values or fail the request. 373 To provide a replacement values after entry creation for either of 374 the 'creatorsName' or 'modifiersName' attributes or both, the 375 client should issue an LDAP Modify request with a Relax Rules control 376 including the approrpiate changes. For instance: 378 dn: ou=Unit,dc=example,dc=net 379 control: IANA-ASSIGNED-OID 380 changetype: modify 381 replace: creatorsName 382 creatorsName: cn=Jane Doe,dc=example,net 383 - 384 replace: modifiersName 385 modifiersName: cn=Jane Doe,dc=example,net 386 - 388 In this case, the server is either to replace the provided 389 values as requested or fail the request. 391 4. Security Considerations 393 Use of this extension should be subject to appropriate administrative 394 and access controls. Use of this mechanism is intended to be 395 restricted to directory administrators. 397 Security considerations for the base operations [RFC4511] extended 398 by this control, as well as general LDAP security considerations 399 [RFC4510], generally apply to implementation and use of this 400 extension. 402 5. IANA Considerations 404 5.1. Object Identifier 406 It is requested that the IANA assign a LDAP Object Identifier 407 [RFC4520] to identify the LDAP Relax Rules Control defined in this 408 document. 410 Subject: Request for LDAP Object Identifier Registration 411 Person & email address to contact for further information: 412 Kurt Zeilenga 413 Specification: RFC XXXX 414 Author/Change Controller: Kurt Zeilenga 415 Comments: Identifies the LDAP Relax Rules Control 417 5.2 LDAP Protocol Mechanism 419 Registration of this protocol mechanism [RFC4520] is requested. 421 Subject: Request for LDAP Protocol Mechanism Registration 422 Object Identifier: IANA-ASSIGNED-OID 423 Description: Relax Rules Control 424 Person & email address to contact for further information: 425 Kurt Zeilenga 426 Usage: Control 427 Specification: RFC XXXX 428 Author/Change Controller: Kurt Zeilenga 429 Comments: none 431 6. Author's Address 433 Kurt D. Zeilenga 434 Isode Limited 436 Email: Kurt.Zeilenga@Isode.COM 438 7. References 440 [[Note to the RFC Editor: please replace the citation tags used in 441 referencing Internet-Drafts with tags of the form RFCnnnn where 442 possible.]] 444 7.1. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 449 [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671, 450 December 2003. 452 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 453 Road Map", RFC 4510, June 2006. 455 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 456 4511, June 2006. 458 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 459 Models", RFC 4512, June 2006. 461 [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol 462 (LDAP) entryUUID Operational Attribute", RFC 4530, June 463 2006. 465 [X.500] International Telecommunication Union - 466 Telecommunication Standardization Sector, "The Directory 467 -- Overview of concepts, models and services," 468 X.500(1993) (also ISO/IEC 9594-1:1994). 470 7.2. Informative References 472 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 473 (IANA) Considerations for the Lightweight Directory 474 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006. 476 Intellectual Property 478 The IETF takes no position regarding the validity or scope of any 479 Intellectual Property Rights or other rights that might be claimed to 480 pertain to the implementation or use of the technology described in 481 this document or the extent to which any license under such rights 482 might or might not be available; nor does it represent that it has 483 made any independent effort to identify any such rights. Information 484 on the procedures with respect to rights in RFC documents can be found 485 in BCP 78 and BCP 79. 487 Copies of IPR disclosures made to the IETF Secretariat and any 488 assurances of licenses to be made available, or the result of an 489 attempt made to obtain a general license or permission for the use of 490 such proprietary rights by implementers or users of this specification 491 can be obtained from the IETF on-line IPR repository at 492 http://www.ietf.org/ipr. 494 The IETF invites any interested party to bring to its attention any 495 copyrights, patents or patent applications, or other proprietary 496 rights that may cover technology that may be required to implement 497 this standard. Please address the information to the IETF at 498 ietf-ipr@ietf.org. 500 Full Copyright 501 Copyright (C) The IETF Trust (2008). 503 This document is subject to the rights, licenses and restrictions 504 contained in BCP 78, and except as set forth therein, the authors 505 retain all their rights. 507 This document and the information contained herein are provided on an 508 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 509 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 510 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 511 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 512 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 513 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.