7 INTERNET-DRAFT Kurt D. Zeilenga
8 Intended Category: Standard Track OpenLDAP Foundation
9 Expires in six months 5 March 2006
13 The LDAP No-Op Control
14 <draft-zeilenga-ldap-noop-08.txt>
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@OpenLDAP.org>.
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.
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.
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."
40 The list of current Internet-Drafts can be accessed at
41 http://www.ietf.org/1id-abstracts.html
43 The list of Internet-Draft Shadow Directories can be accessed at
44 http://www.ietf.org/shadow.html
47 Copyright (C) The Internet Society (2006). All Rights Reserved.
49 Please see the Full Copyright section near the end of this document
58 Zeilenga LDAP No-Op Control [Page 1]
60 INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
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.
73 It is often desirable to be able to determine if a directory operation
74 [Protocol] 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
81 This document defines the Lightweight Directory Access Protocol (LDAP)
82 [Roadmap] 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).
89 For example, when the No-Op control is present in a LDAP modify
90 operation [Protocol], 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
97 This No-Op control is not intended to be to an "effective access"
98 mechanism [RFC2820, U12].
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].
107 DN stands for Distinguished Name.
108 DSA stands for Directory System Agent.
109 DSE stands for DSA-specific entry.
114 Zeilenga LDAP No-Op Control [Page 2]
116 INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
121 The No-Op control is an LDAP Control [Protocol] 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
126 The control is appropriate for request messages of LDAP Add, Delete,
127 Modify and ModifyDN operations [Protocol]. 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.
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).
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.
146 Servers SHOULD indicate their support for this control by providing
147 IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute type
148 [Models] in their root DSE entry. A server MAY choose to advertise
149 this extension only when the client is authorized to use this
153 3. Security Considerations
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
161 Implementors of this LDAP extension should be familiar with security
162 considerations applicable to the LDAP operations [Protocol] extended
163 by this control, as well as general LDAP security considerations
170 Zeilenga LDAP No-Op Control [Page 3]
172 INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
175 4. IANA Considerations
177 4.1. Object Identifier
179 It is requested that IANA assign an LDAP Object Identifier [BCP64bis]
180 to identify the LDAP No-Op Control defined in this document.
182 Subject: Request for LDAP Object Identifier Registration
183 Person & email address to contact for further information:
184 Kurt Zeilenga <kurt@OpenLDAP.org>
185 Specification: RFC XXXX
186 Author/Change Controller: IESG
188 Identifies the LDAP No-Op Control
191 4.2 LDAP Protocol Mechanism
193 Registration of this protocol mechanism is requested [RFC3383].
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@openldap.org>
201 Specification: RFC XXXX
202 Author/Change Controller: IESG
208 Assignment of an LDAP Result Code called 'noOperation' is requested.
210 Subject: LDAP Result Code Registration
211 Person & email address to contact for further information:
212 Kurt Zeilenga <kurt@OpenLDAP.org>
213 Result Code Name: noOperation
214 Specification: RFC XXXX
215 Author/Change Controller: IESG
226 Zeilenga LDAP No-Op Control [Page 4]
228 INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
231 Email: Kurt@OpenLDAP.org
236 [[Note to the RFC Editor: please replace the citation tags used in
237 referencing Internet-Drafts with tags of the form RFCnnnn where
241 6.1. Normative References
243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
244 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
246 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
247 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
249 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
250 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
253 [Models] Zeilenga, K. (editor), "LDAP: Directory Information
254 Models", draft-ietf-ldapbis-models-xx.txt, a work in
258 6.2. Informative References
260 [X.500] International Telecommunication Union -
261 Telecommunication Standardization Sector, "The Directory
262 -- Overview of concepts, models and services,"
263 X.500(1993) (also ISO/IEC 9594-1:1994).
265 [RFC2820] Stokes, E., et. al., "Access Control Requirements for
266 LDAP", RFC 2820, May 2000.
268 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
269 RFC 3062, February 2000.
271 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
272 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
276 Intellectual Property Rights
278 The IETF takes no position regarding the validity or scope of any
282 Zeilenga LDAP No-Op Control [Page 5]
284 INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
287 Intellectual Property Rights or other rights that might be claimed to
288 pertain to the implementation or use of the technology described in
289 this document or the extent to which any license under such rights
290 might or might not be available; nor does it represent that it has
291 made any independent effort to identify any such rights. Information
292 on the procedures with respect to rights in RFC documents can be found
293 in BCP 78 and BCP 79.
295 Copies of IPR disclosures made to the IETF Secretariat and any
296 assurances of licenses to be made available, or the result of an
297 attempt made to obtain a general license or permission for the use of
298 such proprietary rights by implementers or users of this specification
299 can be obtained from the IETF on-line IPR repository at
300 http://www.ietf.org/ipr.
302 The IETF invites any interested party to bring to its attention any
303 copyrights, patents or patent applications, or other proprietary
304 rights that may cover technology that may be required to implement
305 this standard. Please address the information to the IETF at
312 Copyright (C) The Internet Society (2006).
314 This document is subject to the rights, licenses and restrictions
315 contained in BCP 78, and except as set forth therein, the authors
316 retain all their rights.
318 This document and the information contained herein are provided on an
319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
321 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
322 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
323 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
338 Zeilenga LDAP No-Op Control [Page 6]