6 INTERNET-DRAFT Kurt D. Zeilenga
7 Intended Category: Standard Track OpenLDAP Foundation
8 Expires in six months 10 February 2005
12 The LDAP Assertion Control
13 <draft-zeilenga-ldap-assert-05.txt>
18 This document is intended to be, after appropriate review and
19 revision, submitted to the IESG for consideration as a Standard Track
20 document. Distribution of this memo is unlimited. Technical
21 discussion of this document will take place on the IETF LDAP
22 Extensions mailing list <ldapext@ietf.org>. Please send editorial
23 comments directly to the author <Kurt@OpenLDAP.org>.
25 By submitting this Internet-Draft, I accept the provisions of Section
26 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
27 applicable patent or other IPR claims of which I am aware have been
28 disclosed, or will be disclosed, and any of which I become aware will
29 be disclosed, in accordance with RFC 3668.
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 (2005). All Rights Reserved.
49 Please see the Full Copyright section near the end of this document
57 Zeilenga LDAP Assertion Control [Page 1]
59 INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
64 This document defines the Lightweight Directory Access Protocol (LDAP)
65 Assertion Control which allows a client to specify that a directory
66 operation should only be processed if an assertion applied to the
67 target entry of the operation is true. It can be used to construct
68 "test and set" and "test and clear" and other conditional operations.
73 This document defines the Lightweight Directory Access Protocol (LDAP)
74 [Roadmap] assertion control. The assertion control allows the client
75 to specify a condition which must be true for the operation to be
76 processed normally. Otherwise the operation fails. For instance, the
77 control can be used with the Modify operation [Protocol] to perform
78 atomic "test and set" and "test and clear" operations.
80 The control may be attached to any update operation to support
81 conditional addition, deletion, modification, and renaming of the
82 target object. The asserted condition is evaluated as an integral
85 The control may also be used with the search operation. Here the
86 assertion is applied to the base object of the search before searching
87 for objects matching the search scope and filter.
89 The control may also be used with the compare operation. Here it
90 extends the compare operation to allow a more complex assertion.
95 Protocol elements are described using ASN.1 [X.680] with implicit
96 tags. The term "BER-encoded" means the element is to be encoded using
97 the Basic Encoding Rules [X.690] under the restrictions detailed in
98 Section 5.2 of [Protocol].
100 DSA stands for Directory System Agent (or server).
101 DSE stands for DSA-specific Entry.
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].
108 3. The Assertion Control
113 Zeilenga LDAP Assertion Control [Page 2]
115 INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
118 The assertion control is an LDAP Control [Protocol] whose controlType
119 is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
120 [Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE.
121 There is no corresponding response control.
123 The control is appropriate for both LDAP interrogation and update
124 operations [Protocol] including Add, Compare, Delete, Modify, ModifyDN
125 (rename), and Search. It is inappropriate for Abandon, Bind nor
126 Unbind, and Start TLS operations.
128 When the control is attached to an LDAP request, the processing of the
129 request is conditional on the evaluation of the Filter as applied
130 against the target of the operation. If the Filter evaluates to TRUE,
131 then the request is processed normally. If the Filter evaluates to
132 FALSE or Undefined, then assertionFailed (IANA-ASSIGNED-CODE)
133 resultCode is returned and no further processing is performed.
135 For Add, Compare, and ModifyDN the target is indicated by the entry
136 field in the request. For Modify, the target is indicated by the
137 object field. For Delete, the target is indicated by the DelRequest
138 type. For the Compare operation and all update operations, the
139 evaluation of the assertion MUST be performed as an integral part of
140 the operation. That is, the evaluation of the assertion and the
141 normal processing of the operation SHALL be done as one atomic action.
143 For search operation, the target is indicated by the baseObject field
144 and the evaluation is done after "finding" but before "searching"
145 [Protocol]. Hence, no entries or continuations references are
146 returned if the assertion fails.
148 Servers implementing this technical specification SHOULD publish the
149 object identifier IANA-ASSIGNED-OID as a value of the
150 'supportedControl' attribute [Models] in their root DSE. A server MAY
151 choose to advertise this extension only when the client is authorized
154 Other documents may specify how this control applies to other LDAP
155 operations. In doing so, they must state how the target entry is
159 4. Security Considerations
161 The filter may, like other components of the request, contain
162 sensitive information. When so, this information should be
163 appropriately protected.
165 As with any general assertion mechanism, the mechanism can be used to
169 Zeilenga LDAP Assertion Control [Page 3]
171 INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
174 determine directory content. Hence, this mechanism SHOULD be subject
175 to appropriate access controls.
177 Some assertions may be very complex, requiring significant time and
178 resources to evaluate. Hence, this mechanism SHOULD be subject to
179 appropriate administrative controls.
181 Security considerations for the base operations [Protocol] extended by
182 this control, as well as general LDAP security considerations
183 [Roadmap], generally apply to implementation and use of this
187 5. IANA Considerations
189 5.1. Object Identifier
191 It is requested that IANA assign upon Standards Action an LDAP Object
192 Identifier [BCP64bis] to identify the LDAP Assertion Control defined
195 Subject: Request for LDAP Object Identifier Registration
196 Person & email address to contact for further information:
197 Kurt Zeilenga <kurt@OpenLDAP.org>
198 Specification: RFC XXXX
199 Author/Change Controller: IESG
201 Identifies the LDAP Assertion Control
203 5.2 LDAP Protocol Mechanism
205 Registration of this protocol mechanism [BCP64bis] is requested.
207 Subject: Request for LDAP Protocol Mechanism Registration
208 Object Identifier: IANA-ASSIGNED-OID
209 Description: Assertion Control
210 Person & email address to contact for further information:
211 Kurt Zeilenga <kurt@openldap.org>
213 Specification: RFC XXXX
214 Author/Change Controller: IESG
220 Assignment of an LDAP Result Code [BCP64bis] called 'assertionFailed'
225 Zeilenga LDAP Assertion Control [Page 4]
227 INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
230 Subject: LDAP Result Code Registration
231 Person & email address to contact for further information:
232 Kurt Zeilenga <kurt@OpenLDAP.org>
233 Result Code Name: assertionFailed
234 Specification: RFC XXXX
235 Author/Change Controller: IESG
241 The assertion control concept is attributed to Morteza Ansari.
249 Email: Kurt@OpenLDAP.org
254 [[Note to the RFC Editor: please replace the citation tags used in
255 referencing Internet-Drafts with tags of the form RFCnnnn where
259 8.1. Normative References
261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
262 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
264 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
265 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
268 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
269 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
271 [Models] Zeilenga, K. (editor), "LDAP: Directory Information
272 Models", draft-ietf-ldapbis-models-xx.txt, a work in
276 8.2. Informative References
281 Zeilenga LDAP Assertion Control [Page 5]
283 INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
286 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
287 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
291 Intellectual Property Rights
293 The IETF takes no position regarding the validity or scope of any
294 Intellectual Property Rights or other rights that might be claimed to
295 pertain to the implementation or use of the technology described in
296 this document or the extent to which any license under such rights
297 might or might not be available; nor does it represent that it has
298 made any independent effort to identify any such rights. Information
299 on the procedures with respect to rights in RFC documents can be found
300 in BCP 78 and BCP 79.
302 Copies of IPR disclosures made to the IETF Secretariat and any
303 assurances of licenses to be made available, or the result of an
304 attempt made to obtain a general license or permission for the use of
305 such proprietary rights by implementers or users of this specification
306 can be obtained from the IETF on-line IPR repository at
307 http://www.ietf.org/ipr.
309 The IETF invites any interested party to bring to its attention any
310 copyrights, patents or patent applications, or other proprietary
311 rights that may cover technology that may be required to implement
312 this standard. Please address the information to the IETF at
319 Copyright (C) The Internet Society (2005). This document is subject
320 to the rights, licenses and restrictions contained in BCP 78, and
321 except as set forth therein, the authors retain all their rights.
323 This document and the information contained herein are provided on an
324 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
325 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
326 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
327 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
328 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
329 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
337 Zeilenga LDAP Assertion Control [Page 6]