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                            10 February 2005
   9
  10
  11
  12                         The LDAP Assertion Control
  13                    <draft-zeilenga-ldap-assert-05.txt>
  14
  15
  16 Status of this Memo
  17
  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>.
  24
  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.
  30
  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.
  34
  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."
  39
  40   The list of current Internet-Drafts can be accessed at
  41   http://www.ietf.org/1id-abstracts.html
  42
  43   The list of Internet-Draft Shadow Directories can be accessed at
  44   http://www.ietf.org/shadow.html
  45
  46
  47   Copyright (C) The Internet Society (2005).  All Rights Reserved.
  48
  49   Please see the Full Copyright section near the end of this document
  50   for more information.
  51
  52
  53
  54
  55
  56
  57 Zeilenga                 LDAP Assertion Control                 [Page 1]
  58 \f
  59 INTERNET-DRAFT        draft-zeilenga-ldap-assert-05     10 February 2005
  60
  61
  62 Abstract
  63
  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.
  69
  70
  71 1.  Overview
  72
  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.
  79
  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
  83   part the operation.
  84
  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.
  88
  89   The control may also be used with the compare operation.  Here it
  90   extends the compare operation to allow a more complex assertion.
  91
  92
  93 2. Terminology
  94
  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].
  99
 100   DSA stands for Directory System Agent (or server).
 101   DSE stands for DSA-specific Entry.
 102
 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].
 106
 107
 108 3.  The Assertion Control
 109
 110
 111
 112
 113 Zeilenga                 LDAP Assertion Control                 [Page 2]
 114 \f
 115 INTERNET-DRAFT        draft-zeilenga-ldap-assert-05     10 February 2005
 116
 117
 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.
 122
 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.
 127
 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.
 134
 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.
 142
 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.
 147
 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
 152   to use it.
 153
 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
 156   determined.
 157
 158
 159 4.  Security Considerations
 160
 161   The filter may, like other components of the request, contain
 162   sensitive information.  When so, this information should be
 163   appropriately protected.
 164
 165   As with any general assertion mechanism, the mechanism can be used to
 166
 167
 168
 169 Zeilenga                 LDAP Assertion Control                 [Page 3]
 170 \f
 171 INTERNET-DRAFT        draft-zeilenga-ldap-assert-05     10 February 2005
 172
 173
 174   determine directory content.  Hence, this mechanism SHOULD be subject
 175   to appropriate access controls.
 176
 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.
 180
 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
 184   extension.
 185
 186
 187 5.  IANA Considerations
 188
 189 5.1.  Object Identifier
 190
 191   It is requested that IANA assign upon Standards Action an LDAP Object
 192   Identifier [BCP64bis] to identify the LDAP Assertion Control defined
 193   in this document.
 194
 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
 200       Comments:
 201           Identifies the LDAP Assertion Control
 202
 203 5.2  LDAP Protocol Mechanism
 204
 205   Registration of this protocol mechanism [BCP64bis] is requested.
 206
 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>
 212       Usage: Control
 213       Specification: RFC XXXX
 214       Author/Change Controller: IESG
 215       Comments: none
 216
 217
 218 5.3  LDAP Result Code
 219
 220   Assignment of an LDAP Result Code [BCP64bis] called 'assertionFailed'
 221   is requested.
 222
 223
 224
 225 Zeilenga                 LDAP Assertion Control                 [Page 4]
 226 \f
 227 INTERNET-DRAFT        draft-zeilenga-ldap-assert-05     10 February 2005
 228
 229
 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
 236       Comments:  none
 237
 238
 239 6.  Acknowledgments
 240
 241   The assertion control concept is attributed to Morteza Ansari.
 242
 243
 244 7.  Author's Address
 245
 246   Kurt D. Zeilenga
 247   OpenLDAP Foundation
 248
 249   Email: Kurt@OpenLDAP.org
 250
 251
 252 8. References
 253
 254   [[Note to the RFC Editor: please replace the citation tags used in
 255   referencing Internet-Drafts with tags of the form RFCnnnn where
 256   possible.]]
 257
 258
 259 8.1. Normative References
 260
 261   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 262                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 263
 264   [Roadmap]     Zeilenga, K. (editor), "LDAP: Technical Specification
 265                 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
 266                 progress.
 267
 268   [Protocol]    Sermersheim, J. (editor), "LDAP: The Protocol",
 269                 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
 270
 271   [Models]      Zeilenga, K. (editor), "LDAP: Directory Information
 272                 Models", draft-ietf-ldapbis-models-xx.txt, a work in
 273                 progress.
 274
 275
 276 8.2. Informative References
 277
 278
 279
 280
 281 Zeilenga                 LDAP Assertion Control                 [Page 5]
 282 \f
 283 INTERNET-DRAFT        draft-zeilenga-ldap-assert-05     10 February 2005
 284
 285
 286   [BCP64bis]    Zeilenga, K., "IANA Considerations for LDAP",
 287                 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
 288
 289
 290
 291 Intellectual Property Rights
 292
 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.
 301
 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.
 308
 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
 313   ietf-ipr@ietf.org.
 314
 315
 316
 317 Full Copyright
 318
 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.
 322
 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.
 330
 331
 332
 333
 334
 335
 336
 337 Zeilenga                 LDAP Assertion Control                 [Page 6]
 338 \f
 339
 340