1 2 3 4 5 6 7INTERNET-DRAFT Kurt D. Zeilenga 8Intended Category: Standard Track Isode Limited 9Expires in six months 14 February 2007 10 11 12 13 The LDAP No-Op Control 14 <draft-zeilenga-ldap-noop-10.txt> 15 16 17Status of this Memo 18 19 This document is intended to be, after appropriate review and 20 revision, submitted to the IESG for consideration as a Standard Track 21 document. Distribution of this memo is unlimited. Technical 22 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 By submitting this Internet-Draft, each author represents that any 27 applicable patent or other IPR claims of which he or she is aware have 28 been or will be disclosed, and any of which he or she becomes aware 29 will be disclosed, in accordance with Section 6 of BCP 79. 30 31 Internet-Drafts are working documents of the Internet Engineering Task 32 Force (IETF), its areas, and its working groups. Note that other 33 groups may also distribute working documents as Internet-Drafts. 34 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference material 38 or to cite them other than as "work in progress." 39 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. 42 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 45 46 47 Copyright (C) The IETF Trust (2007). All Rights Reserved. 48 49 Please see the Full Copyright section near the end of this document 50 for more information. 51 52 53 54 55 56 57 58Zeilenga LDAP No-Op Control [Page 1] 59 60INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007 61 62 63Abstract 64 65 This document defines the Lightweight Directory Access Protocol (LDAP) 66 No-Op control which can be used to disable the normal effect of an 67 operation. The control can be used to discover how a server might 68 react to a particular update request without updating the directory. 69 70 711. Overview 72 73 It is often desirable to be able to determine if a directory operation 74 [RFC4511] would successful complete or not without having the normal 75 effect of the operation take place. For example, an administrative 76 client might want to verify that new user could update their entry 77 (and not other entries) without the directory actually being updated. 78 The mechanism could be used to build more sophisticated security 79 auditing tools. 80 81 This document defines the Lightweight Directory Access Protocol (LDAP) 82 [RFC4510] No-Op control extension. The presence of the No-Op control 83 in an operation request message disables its normal effect upon the 84 directory which operation would otherwise have. Instead of updating 85 the directory and returning the normal indication of success, the 86 server does not update the directory and indicates so by returning the 87 noOperation resultCode (introduced below). 88 89 For example, when the No-Op control is present in a LDAP modify 90 operation [RFC4511], the server is do all processing necessary to 91 perform the operation without actually updating the directory. If it 92 detects an error during this processing, it returns a non-success 93 (other than noOperation) resultCode as it normally would. Otherwise, 94 it returns the noOperation. In either case, the directory is left 95 unchanged. 96 97 This No-Op control is not intended to be to an "effective access" 98 mechanism [RFC2820, U12]. 99 100 1011.1. Terminology 102 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in BCP 14 [RFC2119]. 106 107 DN stands for Distinguished Name. 108 DSA stands for Directory System Agent. 109 DSE stands for DSA-specific entry. 110 111 112 113 114Zeilenga LDAP No-Op Control [Page 2] 115 116INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007 117 118 1192. No-Op Control 120 121 The No-Op control is an LDAP Control [RFC4511] whose controlType is 122 IANA-ASSIGNED-OID and controlValue is absent. Clients MUST provide a 123 criticality value of TRUE to prevent unintended modification of the 124 directory. 125 126 The control is appropriate for request messages of LDAP Add, Delete, 127 Modify and ModifyDN operations [RFC4511]. The control is also 128 appropriate for requests of extended operations which update the 129 directory (or other data stores), such as Password Modify Extended 130 Operation [RFC3062]. There is no corresponding response control. 131 132 When the control is attached to an LDAP request, the server does all 133 normal processing possible for the operation without modification of 134 the directory. That is, when the control is attached to an LDAP 135 request, the directory SHALL NOT be updated and the response SHALL NOT 136 have a resultCode of success (0). 137 138 A result code other than noOperation (IANA-ASSIGNED-CODE) means that 139 the server is unable or unwilling to complete the processing for the 140 reason indicated by the result code. A result code of noOperation 141 (IANA-ASSIGNED-CODE) indicates that the server discovered no reason 142 why the operation would fail if submitted without the No-Op control. 143 It is noted that there may be reasons why the operation may fail which 144 are only discoverable when submitting without the No-Op control. 145 146 Servers SHOULD indicate their support for this control by providing 147 IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute type 148 [RFC4512] in their root DSE entry. A server MAY choose to advertise 149 this extension only when the client is authorized to use this 150 operation. 151 152 1533. Security Considerations 154 155 The No-Op control mechanism allows directory administrators and users 156 to verify that access control and other administrative policy controls 157 are properly configured. The mechanism may also lead to the 158 development (and deployment) of more effective security auditing 159 tools. 160 161 Implementors of this LDAP extension should be familiar with security 162 considerations applicable to the LDAP operations [RFC4511] extended by 163 this control, as well as general LDAP security considerations 164 [Roadmap]. 165 166 167 168 169 170Zeilenga LDAP No-Op Control [Page 3] 171 172INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007 173 174 1754. IANA Considerations 176 1774.1. Object Identifier 178 179 It is requested that IANA assign an LDAP Object Identifier [RFC4520] 180 to identify the LDAP No-Op Control defined in this document. 181 182 Subject: Request for LDAP Object Identifier Registration 183 Person & email address to contact for further information: 184 Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> 185 Specification: RFC XXXX 186 Author/Change Controller: IESG 187 Comments: 188 Identifies the LDAP No-Op Control 189 190 1914.2 LDAP Protocol Mechanism 192 193 Registration of this protocol mechanism is requested [RFC4520]. 194 195 Subject: Request for LDAP Protocol Mechanism Registration 196 Object Identifier: IANA-ASSIGNED-OID 197 Description: No-Op Control 198 Person & email address to contact for further information: 199 Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> 200 Usage: Control 201 Specification: RFC XXXX 202 Author/Change Controller: IESG 203 Comments: none 204 205 2064.3 LDAP Result Code 207 208 Assignment of an LDAP Result Code called 'noOperation' is requested. 209 210 Subject: LDAP Result Code Registration 211 Person & email address to contact for further information: 212 Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> 213 Result Code Name: noOperation 214 Specification: RFC XXXX 215 Author/Change Controller: IESG 216 Comments: none 217 218 2195. Author's Address 220 221 Kurt D. Zeilenga 222 Isode Limited 223 224 225 226Zeilenga LDAP No-Op Control [Page 4] 227 228INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007 229 230 231 Email: Kurt.Zeilenga@Isode.COM 232 233 2346. References 235 236 [[Note to the RFC Editor: please replace the citation tags used in 237 referencing Internet-Drafts with tags of the form RFCnnnn where 238 possible.]] 239 240 2416.1. Normative References 242 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 245 246 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 247 Road Map", RFC 4510, June 2006. 248 249 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 250 4511, June 2006. 251 252 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 253 Models", RFC 4512, June 2006. 254 255 2566.2. Informative References 257 258 [X.500] International Telecommunication Union - 259 Telecommunication Standardization Sector, "The Directory 260 -- Overview of concepts, models and services," 261 X.500(1993) (also ISO/IEC 9594-1:1994). 262 263 [RFC2820] Stokes, E., et. al., "Access Control Requirements for 264 LDAP", RFC 2820, May 2000. 265 266 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 267 RFC 3062, February 2000. 268 269 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 270 (IANA) Considerations for the Lightweight Directory 271 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006. 272 273 274 275Intellectual Property 276 277 The IETF takes no position regarding the validity or scope of any 278 Intellectual Property Rights or other rights that might be claimed to 279 280 281 282Zeilenga LDAP No-Op Control [Page 5] 283 284INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007 285 286 287 pertain to the implementation or use of the technology described in 288 this document or the extent to which any license under such rights 289 might or might not be available; nor does it represent that it has 290 made any independent effort to identify any such rights. Information 291 on the procedures with respect to rights in RFC documents can be found 292 in BCP 78 and BCP 79. 293 294 Copies of IPR disclosures made to the IETF Secretariat and any 295 assurances of licenses to be made available, or the result of an 296 attempt made to obtain a general license or permission for the use of 297 such proprietary rights by implementers or users of this specification 298 can be obtained from the IETF on-line IPR repository at 299 http://www.ietf.org/ipr. 300 301 The IETF invites any interested party to bring to its attention any 302 copyrights, patents or patent applications, or other proprietary 303 rights that may cover technology that may be required to implement 304 this standard. Please address the information to the IETF at 305 ietf-ipr@ietf.org. 306 307 308 309Full Copyright 310 311 Copyright (C) The IETF Trust (2007). 312 313 This document is subject to the rights, licenses and restrictions 314 contained in BCP 78, and except as set forth therein, the authors 315 retain all their rights. 316 317 This document and the information contained herein are provided on an 318 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 319 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 320 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 321 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 322 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338Zeilenga LDAP No-Op Control [Page 6] 339 340