git.sur5r.net Git - openldap/blob - doc/drafts/draft-zeilenga-ldap-assert-xx.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                      Kurt D. Zeilenga
   8 Intended Category: Standard Track                OpenLDAP Foundation
   9 Expires in six months                                25 October 2003
  10
  11
  12                         The LDAP Assertion Control
  13                    <draft-zeilenga-ldap-assert-01.txt>
  14
  15
  16 Status of this Memo
  17
  18   This document is an Internet-Draft and is in full conformance with all
  19   provisions of Section 10 of RFC2026.
  20
  21   This document is intended to be, after appropriate review and
  22   revision, submitted to the IESG for consideration as a Standard Track
  23   document.  Distribution of this memo is unlimited.  Technical
  24   discussion of this document will take place on the IETF LDAP
  25   Extensions mailing list <ldapext@ietf.org>.  Please send editorial
  26   comments directly to the author <Kurt@OpenLDAP.org>.
  27
  28   Internet-Drafts are working documents of the Internet Engineering Task
  29   Force (IETF), its areas, and its working groups.  Note that other
  30   groups may also distribute working documents as Internet-Drafts.
  31   Internet-Drafts are draft documents valid for a maximum of six months
  32   and may be updated, replaced, or obsoleted by other documents at any
  33   time.  It is inappropriate to use Internet-Drafts as reference
  34   material or to cite them other than as ``work in progress.''
  35
  36   The list of current Internet-Drafts can be accessed at
  37   <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
  38   Internet-Draft Shadow Directories can be accessed at
  39   <http://www.ietf.org/shadow.html>.
  40
  41   Copyright (C) The Internet Society (2003).  All Rights Reserved.
  42
  43   Please see the Full Copyright section near the end of this document
  44   for more information.
  45
  46
  47 Abstract
  48
  49   This document defines the Lightweight Directory Access Protocol (LDAP)
  50   Assertion Control which allows a client to specify that a directory
  51   operation should only be processed if an assertion applied to the
  52   target entry of the operation is true.  It can be used to construct
  53   "test and set" and "test and clear" and other conditional operations.
  54
  55
  56
  57
  58 Zeilenga                 LDAP Assertion Control                 [Page 1]
  59 \f
  60 INTERNET-DRAFT        draft-zeilenga-ldap-assert-01      25 October 2003
  61
  62
  63 1.  Overview
  64
  65   This document defines the Lightweight Directory Access Protocol (LDAP)
  66   [RFC3377] assertion control.  The assertion control allows the client
  67   to specify a condition which must be true for the operation to be
  68   processed normally.  Otherwise the operation fails.
  69
  70   The control can be used with the Modify operation [RFC2251] to perform
  71   atomic "test and set" and "test and clear" operations as the asserted
  72   condition is evaluated as an integral part the operation.  The control
  73   may be attached to other update operations to support conditional add,
  74   delete, and renaming of objects.
  75
  76   The control may also be used with the search operation.  Here the
  77   assertion is applied to the base object of the search before searching
  78   for objects matching the search scope and filter.
  79
  80   The control may also be used with the compare operation.  Here it
  81   extends the compare operation to allow a more complex assertion.
  82
  83
  84 2. Terminology
  85
  86   Protocol elements are described using ASN.1 [X.680] with implicit
  87   tags.  The term "BER-encoded" means the element is to be encoded using
  88   the Basic Encoding Rules [X.690] under the restrictions detailed in
  89   Section 5.1 of [RFC2251].
  90
  91   DSA stands for Directory System Agent (or server).
  92   DSE stands for DSA-specific Entry.
  93
  94   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  95   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  96   document are to be interpreted as described in BCP 14 [RFC2119].
  97
  98
  99 3.  The Assertion Control
 100
 101   The assertion control is an LDAP Control [RFC2251] whose controlType
 102   is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
 103   [RFC2251, Section 4.5.1].  The criticality may be TRUE or FALSE.
 104   There is no corresponding response control.
 105
 106   The control is appropriate for both LDAP interrogation and update
 107   operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
 108   (rename), and Search.  It is inappropriate for Abandon, Bind nor
 109   Unbind operations.  It is also inappropriate for the Start TLS
 110   [RFC2830] operation.
 111
 112
 113
 114 Zeilenga                 LDAP Assertion Control                 [Page 2]
 115 \f
 116 INTERNET-DRAFT        draft-zeilenga-ldap-assert-01      25 October 2003
 117
 118
 119   When the control is attached to an LDAP request, the processing of the
 120   request is conditional on the evaluation of the Filter as applied
 121   against the target of the operation.  If the Filter evaluates to TRUE,
 122   then the request is processed normally.  If the Filter evaluates to
 123   FALSE or Undefined, then assertionFailed (IANA-ASSIGNED-CODE)
 124   resultCode is returned and no further processing is performed.
 125
 126   For Add, Compare, and ModifyDN the target is indicated by the entry
 127   field in the request.  For Modify, the target is indicated by the
 128   object field.  For Delete, the target is indicated by the DelRequest
 129   type.  For the Compare operation and all update operations, the
 130   evaluation of the assertion MUST be performed as an integral part of
 131   the operation.  That is, the evaluation of the assertion and the
 132   normal processing of the operation SHALL be done as one atomic action.
 133
 134   For search operation, the target is indicated by the baseObject field
 135   and the evaluation is done after "finding" but before "searching"
 136   [RFC2251].  Hence, if the evaluation fails, no entries or
 137   continuations references are returned.
 138
 139   Servers implementing this technical specification SHOULD publish the
 140   object identifier IANA-ASSIGNED-OID as a value of the
 141   'supportedControl' attribute [RFC2252] in their root DSE.  A server
 142   MAY choose to advertise this extension only when the client is
 143   authorized to use it.
 144
 145   Other documents may specify how this control applies to other LDAP
 146   operations.  In doing so, they must state how the target entry is
 147   determined.
 148
 149
 150 4.  Security Considerations
 151
 152   The filter may, like other components of the request, contain
 153   sensitive information.  When so, 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, the 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, the mechanism SHOULD be subject to
 162   appropriate administrative controls.
 163
 164   All security considerations for the base operations [RFC2251] to which
 165   this control is attached to apply, as do general LDAP security
 166   considerations [RFC3377].
 167
 168
 169
 170 Zeilenga                 LDAP Assertion Control                 [Page 3]
 171 \f
 172 INTERNET-DRAFT        draft-zeilenga-ldap-assert-01      25 October 2003
 173
 174
 175 5.  IANA Considerations
 176
 177 5.1.  Object Identifier
 178
 179   It is requested that IANA assign upon Standards Action an LDAP Object
 180   Identifier [RFC3383] to identify the LDAP Assertion Control defined in
 181   this document.
 182
 183       Subject: Request for LDAP Object Identifier Registration
 184       Person & email address to contact for further information:
 185           Kurt Zeilenga <kurt@OpenLDAP.org>
 186       Specification: RFC XXXX
 187       Author/Change Controller: IESG
 188       Comments:
 189           Identifies the LDAP Assertion Control
 190
 191 5.2  LDAP Protocol Mechanism
 192
 193   Registration of this protocol mechanism [RFC3383] is requested.
 194
 195       Subject: Request for LDAP Protocol Mechanism Registration
 196       Object Identifier: IANA-ASSIGNED-OID
 197       Description: Assertion Control
 198       Person & email address to contact for further information:
 199           Kurt Zeilenga <kurt@openldap.org>
 200       Usage: Control
 201       Specification: RFC XXXX
 202       Author/Change Controller: IESG
 203       Comments: none
 204
 205
 206 5.3  LDAP Result Code
 207
 208   Assignment of an LDAP Result Code [RFC3383] called 'assertionFailed'
 209   is requested.
 210
 211       Subject: LDAP Result Code Registration
 212       Person & email address to contact for further information:
 213           Kurt Zeilenga <kurt@OpenLDAP.org>
 214       Result Code Name: assertionFailed
 215       Specification: RFC XXXX
 216       Author/Change Controller: IESG
 217       Comments:  none
 218
 219
 220 6.  Acknowledgments
 221
 222   The assertion control concept is attributed to Morteza Ansari.
 223
 224
 225
 226 Zeilenga                 LDAP Assertion Control                 [Page 4]
 227 \f
 228 INTERNET-DRAFT        draft-zeilenga-ldap-assert-01      25 October 2003
 229
 230
 231 7.  Author's Address
 232
 233   Kurt D. Zeilenga
 234   OpenLDAP Foundation
 235   <Kurt@OpenLDAP.org>
 236
 237
 238 8. Normative References
 239
 240   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 241                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 242
 243   [RFC2251]     Wahl, M., T. Howes and S. Kille, "Lightweight Directory
 244                 Access Protocol (v3)", RFC 2251, December 1997.
 245
 246   [RFC2252]     Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
 247                 "Lightweight Directory Access Protocol (v3):  Attribute
 248                 Syntax Definitions", RFC 2252, December 1997.
 249
 250   [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
 251                 Protocol (v3): Technical Specification", RFC 3377,
 252                 September 2002.
 253
 254
 255 9. Informative References
 256
 257   [RFC3383]     Zeilenga, K., "IANA Considerations for LDAP", BCP 64
 258                 (also RFC 3383), September 2002.
 259
 260
 261
 262 Intellectual Property Rights
 263
 264   The IETF takes no position regarding the validity or scope of any
 265   intellectual property or other rights that might be claimed to pertain
 266   to the implementation or use of the technology described in this
 267   document or the extent to which any license under such rights might or
 268   might not be available; neither does it represent that it has made any
 269   effort to identify any such rights.  Information on the IETF's
 270   procedures with respect to rights in standards-track and
 271   standards-related documentation can be found in BCP-11.  Copies of
 272   claims of rights made available for publication and any assurances of
 273   licenses to be made available, or the result of an attempt made to
 274   obtain a general license or permission for the use of such proprietary
 275   rights by implementors or users of this specification can be obtained
 276   from the IETF Secretariat.
 277
 278   The IETF invites any interested party to bring to its attention any
 279
 280
 281
 282 Zeilenga                 LDAP Assertion Control                 [Page 5]
 283 \f
 284 INTERNET-DRAFT        draft-zeilenga-ldap-assert-01      25 October 2003
 285
 286
 287   copyrights, patents or patent applications, or other proprietary
 288   rights which may cover technology that may be required to practice
 289   this standard.  Please address the information to the IETF Executive
 290   Director.
 291
 292
 293
 294 Full Copyright
 295
 296   Copyright (C) The Internet Society (2003). All Rights Reserved.
 297
 298   This document and translations of it may be copied and furnished to
 299   others, and derivative works that comment on or otherwise explain it
 300   or assist in its implmentation may be prepared, copied, published and
 301   distributed, in whole or in part, without restriction of any kind,
 302   provided that the above copyright notice and this paragraph are
 303   included on all such copies and derivative works.  However, this
 304   document itself may not be modified in any way, such as by removing
 305   the copyright notice or references to the Internet Society or other
 306   Internet organizations, except as needed for the  purpose of
 307   developing Internet standards in which case the procedures for
 308   copyrights defined in the Internet Standards process must be followed,
 309   or as required to translate it into languages other than English.
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Zeilenga                 LDAP Assertion Control                 [Page 6]
 339 \f