]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4528.txt
Remove many (but not all) references to slurpd(8).
[openldap] / doc / rfc / rfc4528.txt
1
2
3
4
5
6
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 4528                           OpenLDAP Foundation
9 Category: Standards Track                                      June 2006
10
11
12               Lightweight Directory Access Protocol (LDAP)
13                            Assertion Control
14
15
16 Status of This Memo
17
18    This document specifies an Internet standards track protocol for the
19    Internet community, and requests discussion and suggestions for
20    improvements.  Please refer to the current edition of the "Internet
21    Official Protocol Standards" (STD 1) for the standardization state
22    and status of this protocol.  Distribution of this memo is unlimited.
23
24 Copyright Notice
25
26    Copyright (C) The Internet Society (2006).
27
28 Abstract
29
30    This document defines the Lightweight Directory Access Protocol
31    (LDAP) Assertion Control, which allows a client to specify that a
32    directory operation should only be processed if an assertion applied
33    to the target entry of the operation is true.  It can be used to
34    construct "test and set", "test and clear", and other conditional
35    operations.
36
37 Table of Contents
38
39    1. Overview ........................................................2
40    2. Terminology .....................................................2
41    3. The Assertion Control ...........................................2
42    4. Security Considerations .........................................3
43    5. IANA Considerations .............................................4
44       5.1. Object Identifier ..........................................4
45       5.2. LDAP Protocol Mechanism ....................................4
46       5.3. LDAP Result Code ...........................................4
47    6. Acknowledgements ................................................5
48    7. References ......................................................5
49       7.1. Normative References .......................................5
50       7.2. Informative References .....................................5
51
52
53
54
55
56
57
58 Zeilenga                    Standards Track                     [Page 1]
59 \f
60 RFC 4528                 LDAP Assertion Control                June 2006
61
62
63 1.  Overview
64
65    This document defines the Lightweight Directory Access Protocol
66    (LDAP) [RFC4510] assertion control.  The assertion control allows the
67    client to specify a condition that must be true for the operation to
68    be processed normally.  Otherwise, the operation is not performed.
69    For instance, the control can be used with the Modify operation
70    [RFC4511] to perform atomic "test and set" and "test and clear"
71    operations.
72
73    The control may be attached to any update operation to support
74    conditional addition, deletion, modification, and renaming of the
75    target object.  The asserted condition is evaluated as an integral
76    part the operation.
77
78    The control may also be used with the search operation.  Here, the
79    assertion is applied to the base object of the search before
80    searching for objects that match the search scope and filter.
81
82    The control may also be used with the compare operation.  Here, it
83    extends the compare operation to allow a more complex assertion.
84
85 2. Terminology
86
87    Protocol elements are described using ASN.1 [X.680] with implicit
88    tags.  The term "BER-encoded" means the element is to be encoded
89    using the Basic Encoding Rules [X.690] under the restrictions
90    detailed in Section 5.1 of [RFC4511].
91
92    DSA stands for Directory System Agent (or server).
93    DSE stands for DSA-specific Entry.
94
95    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
96    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
97    and "OPTIONAL" are to be interpreted as described in BCP 14
98    [RFC2119].
99
100 3.  The Assertion Control
101
102    The assertion control is an LDAP Control [RFC4511] whose controlType
103    is 1.3.6.1.1.12 and whose controlValue is a BER-encoded Filter
104    [Protocol, Section 4.5.1].  The criticality may be TRUE or FALSE.
105    There is no corresponding response control.
106
107    The control is appropriate for both LDAP interrogation and update
108    operations [RFC4511], including Add, Compare, Delete, Modify,
109    ModifyDN (rename), and Search.  It is inappropriate for Abandon,
110    Bind, Unbind, and StartTLS operations.
111
112
113
114 Zeilenga                    Standards Track                     [Page 2]
115 \f
116 RFC 4528                 LDAP Assertion Control                June 2006
117
118
119    When the control is attached to an LDAP request, the processing of
120    the request is conditional on the evaluation of the Filter as applied
121    against the target of the operation.  If the Filter evaluates to
122    TRUE, then the request is processed normally.  If the Filter
123    evaluates to FALSE or Undefined, then assertionFailed (122)
124    resultCode is returned, and no further processing is performed.
125
126    For Add, Compare, and ModifyDN operations, the target is indicated by
127    the entry field in the request.  For Modify operations, the target is
128    indicated by the object field.  For Delete operations, the target is
129    indicated by the DelRequest type.  For Compare operations and all
130    update operations, the evaluation of the assertion MUST be performed
131    as an integral part of the operation.  That is, the evaluation of the
132    assertion and the normal processing of the operation SHALL be done as
133    one atomic action.
134
135    For Search operations, the target is indicated by the baseObject
136    field, and the evaluation is done after "finding" but before
137    "searching" [RFC4511].  Hence, no entries or continuations references
138    are returned if the assertion fails.
139
140    Servers implementing this technical specification SHOULD publish the
141    object identifier 1.3.6.1.1.12 as a value of the 'supportedControl'
142    attribute [RFC4512] in their root DSE.  A server MAY choose to
143    advertise this extension only when the client is authorized to use
144    it.
145
146    Other documents may specify how this control applies to other LDAP
147    operations.  In doing so, they must state how the target entry is
148    determined.
149
150 4.  Security Considerations
151
152    The filter may, like other components of the request, contain
153    sensitive information.  When it does, this information should be
154    appropriately protected.
155
156    As with any general assertion mechanism, the mechanism can be used to
157    determine directory content.  Hence, this mechanism SHOULD be subject
158    to appropriate access controls.
159
160    Some assertions may be very complex, requiring significant time and
161    resources to evaluate.  Hence, this mechanism SHOULD be subject to
162    appropriate administrative controls.
163
164
165
166
167
168
169
170 Zeilenga                    Standards Track                     [Page 3]
171 \f
172 RFC 4528                 LDAP Assertion Control                June 2006
173
174
175    Security considerations for the base operations [RFC4511] extended by
176    this control, as well as general LDAP security considerations
177    [RFC4510], generally apply to implementation and use of this
178    extension.
179
180 5.  IANA Considerations
181
182 5.1.  Object Identifier
183
184    The IANA has assigned an LDAP Object Identifier [RFC4520] to identify
185    the LDAP Assertion Control defined in this document.
186
187        Subject: Request for LDAP Object Identifier Registration
188        Person & email address to contact for further information:
189            Kurt Zeilenga <kurt@OpenLDAP.org>
190        Specification: RFC 4528
191        Author/Change Controller: IESG
192        Comments:
193            Identifies the LDAP Assertion Control
194
195 5.2.  LDAP Protocol Mechanism
196
197    Registration of this protocol mechanism [RFC4520] is requested.
198
199        Subject: Request for LDAP Protocol Mechanism Registration
200        Object Identifier: 1.3.6.1.1.12
201        Description: Assertion Control
202        Person & email address to contact for further information:
203            Kurt Zeilenga <kurt@openldap.org>
204        Usage: Control
205        Specification: RFC 4528
206        Author/Change Controller: IESG
207        Comments: none
208
209 5.3.  LDAP Result Code
210
211    The IANA has assigned an LDAP Result Code [RFC4520] called
212    'assertionFailed' (122).
213
214        Subject: LDAP Result Code Registration
215        Person & email address to contact for further information:
216            Kurt Zeilenga <kurt@OpenLDAP.org>
217        Result Code Name: assertionFailed
218        Specification: RFC 4528
219        Author/Change Controller: IESG
220        Comments:  none
221
222
223
224
225
226 Zeilenga                    Standards Track                     [Page 4]
227 \f
228 RFC 4528                 LDAP Assertion Control                June 2006
229
230
231 6.  Acknowledgements
232
233    The assertion control concept is attributed to Morteza Ansari.
234
235 7.  References
236
237 7.1.  Normative References
238
239    [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
240                  Requirement Levels", BCP 14, RFC 2119, March 1997.
241
242    [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
243                  Protocol (LDAP): Technical Specification Road Map", RFC
244                  4510, June 2006.
245
246    [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
247                  Protocol (LDAP): The Protocol", RFC 4511, June 2006.
248
249    [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
250                  (LDAP): Directory Information Models", RFC 4512, June
251                  2006.
252
253    [X.680]       International Telecommunication Union -
254                  Telecommunication Standardization Sector, "Abstract
255                  Syntax Notation One (ASN.1) - Specification of Basic
256                  Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
257
258    [X.690]       International Telecommunication Union -
259                  Telecommunication Standardization Sector,
260                  "Specification of ASN.1 encoding rules: Basic Encoding
261                  Rules (BER), Canonical Encoding Rules (CER), and
262                  Distinguished Encoding Rules (DER)", X.690(2002) (also
263                  ISO/IEC 8825-1:2002).
264
265 7.2.  Informative References
266
267    [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
268                  (IANA) Considerations for the Lightweight Directory
269                  Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
270
271 Author's Address
272
273    Kurt D. Zeilenga
274    OpenLDAP Foundation
275
276    EMail: Kurt@OpenLDAP.org
277
278
279
280
281
282 Zeilenga                    Standards Track                     [Page 5]
283 \f
284 RFC 4528                 LDAP Assertion Control                June 2006
285
286
287 Full Copyright Statement
288
289    Copyright (C) The Internet Society (2006).
290
291    This document is subject to the rights, licenses and restrictions
292    contained in BCP 78, and except as set forth therein, the authors
293    retain all their rights.
294
295    This document and the information contained herein are provided on an
296    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
297    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
298    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
299    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
300    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
301    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
302
303 Intellectual Property
304
305    The IETF takes no position regarding the validity or scope of any
306    Intellectual Property Rights or other rights that might be claimed to
307    pertain to the implementation or use of the technology described in
308    this document or the extent to which any license under such rights
309    might or might not be available; nor does it represent that it has
310    made any independent effort to identify any such rights.  Information
311    on the procedures with respect to rights in RFC documents can be
312    found in BCP 78 and BCP 79.
313
314    Copies of IPR disclosures made to the IETF Secretariat and any
315    assurances of licenses to be made available, or the result of an
316    attempt made to obtain a general license or permission for the use of
317    such proprietary rights by implementers or users of this
318    specification can be obtained from the IETF on-line IPR repository at
319    http://www.ietf.org/ipr.
320
321    The IETF invites any interested party to bring to its attention any
322    copyrights, patents or patent applications, or other proprietary
323    rights that may cover technology that may be required to implement
324    this standard.  Please address the information to the IETF at
325    ietf-ipr@ietf.org.
326
327 Acknowledgement
328
329    Funding for the RFC Editor function is provided by the IETF
330    Administrative Support Activity (IASA).
331
332
333
334
335
336
337
338 Zeilenga                    Standards Track                     [Page 6]
339 \f