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