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

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