git.sur5r.net Git - openldap/blob - doc/drafts/draft-zeilenga-ldap-noop-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                                28 October 2005
  10
  11
  12
  13                           The LDAP No-Op Control
  14                     <draft-zeilenga-ldap-noop-07.txt>
  15
  16
  17 Status of this Memo
  18
  19   This document is intended to be, after appropriate review and
  20   revision, submitted to the IESG for consideration as a Standard Track
  21   document.  Distribution of this memo is unlimited.  Technical
  22   discussion of this document will take place on the IETF LDAP
  23   Extensions mailing list <ldapext@ietf.org>.  Please send editorial
  24   comments directly to the author <Kurt@OpenLDAP.org>.
  25
  26   By submitting this Internet-Draft, each author represents that any
  27   applicable patent or other IPR claims of which he or she is aware have
  28   been or will be disclosed, and any of which he or she becomes aware
  29   will be disclosed, in accordance with Section 6 of BCP 79.
  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
  58 Zeilenga                   LDAP No-Op Control                   [Page 1]
  59 \f
  60 INTERNET-DRAFT         draft-zeilenga-ldap-noop-07       28 October 2005
  61
  62
  63 Abstract
  64
  65   This document defines the Lightweight Directory Access Protocol (LDAP)
  66   No-Op control which can be used to disable the normal effect of an
  67   operation.  The control can be used to discover how a server might
  68   react to a particular update request without updating the directory.
  69
  70
  71 1.  Overview
  72
  73   It is often desirable to be able to determine if a directory operation
  74   [Protocol] would successful complete or not without having the normal
  75   effect of the operation take place.  For example, an administrative
  76   client might want to verify that new user could update their entry
  77   (and not other entries) without the directory actually being updated.
  78   The mechanism could be used to build more sophisticated security
  79   auditing tools.
  80
  81   This document defines the Lightweight Directory Access Protocol (LDAP)
  82   [Roadmap] No-Op control extension.  The presence of the No-Op control
  83   in an operation request message disables its normal effect upon the
  84   directory which operation would otherwise have.  Instead of updating
  85   the directory and returning the normal indication of success, the
  86   server does not update the directory and indicates so by returning the
  87   noOperation resultCode (introduced below).
  88
  89   For example, when the No-Op control is present in a LDAP modify
  90   operation [Protocol], the server is do all processing necessary to
  91   perform the operation without actually updating the directory.  If it
  92   detects an error during this processing, it returns a non-success
  93   (other than noOperation) resultCode as it normally would.  Otherwise,
  94   it returns the noOperation.  In either case, the directory is left
  95   unchanged.
  96
  97   This No-Op control is not intended to be to an "effective access"
  98   mechanism [RFC2820, U12].
  99
 100
 101 1.1.  Terminology
 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   DN stands for Distinguished Name.
 108   DSA stands for Directory System Agent.
 109   DSE stands for DSA-specific entry.
 110
 111
 112
 113
 114 Zeilenga                   LDAP No-Op Control                   [Page 2]
 115 \f
 116 INTERNET-DRAFT         draft-zeilenga-ldap-noop-07       28 October 2005
 117
 118
 119 2.  No-Op Control
 120
 121   The No-Op control is an LDAP Control [Protocol] whose controlType is
 122   IANA-ASSIGNED-OID and controlValue is absent.  Clients MUST provide a
 123   criticality value of TRUE to prevent unintended modification of the
 124   directory.
 125
 126   The control is appropriate for request messages of LDAP Add, Delete,
 127   Modify and ModifyDN operations [Protocol].  The control is also
 128   appropriate for requests of extended operations which update the
 129   directory (or other data stores), such as Password Modify Extended
 130   Operation [RFC3062].  There is no corresponding response control.
 131
 132   When the control is attached to an LDAP request, the server does all
 133   normal processing possible for the operation without modification of
 134   the directory.  That is, when the control is attached to an LDAP
 135   request, the directory SHALL NOT be updated and the response SHALL NOT
 136   have a resultCode of success (0).
 137
 138   A result code other than noOperation (IANA-ASSIGNED-CODE) means that
 139   the server is unable or unwilling to complete the processing for the
 140   reason indicated by the result code.  A result code of noOperation
 141   (IANA-ASSIGNED-CODE) indicates that the server discovered no reason
 142   why the operation would fail if submitted without the No-Op control.
 143   It is noted that there may be reasons why the operation may fail which
 144   are only discoverable when submitting without the No-Op control.
 145
 146   Servers SHOULD indicate their support for this control by providing
 147   IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute type
 148   [Models] in their root DSE entry.  A server MAY choose to advertise
 149   this extension only when the client is authorized to use this
 150   operation.
 151
 152
 153 3.  Security Considerations
 154
 155   The No-Op control mechanism allows directory administrators and users
 156   to verify that access control and other administrative policy controls
 157   are properly configured.  The mechanism may also lead to the
 158   development (and deployment) of more effective security auditing
 159   tools.
 160
 161   Implementors of this LDAP extension should be familiar with security
 162   considerations applicable to the LDAP operations [Protocol] extended
 163   by this control, as well as general LDAP security considerations
 164   [Roadmap].
 165
 166
 167
 168
 169
 170 Zeilenga                   LDAP No-Op Control                   [Page 3]
 171 \f
 172 INTERNET-DRAFT         draft-zeilenga-ldap-noop-07       28 October 2005
 173
 174
 175 4.  IANA Considerations
 176
 177 4.1.  Object Identifier
 178
 179   It is requested that IANA assign an LDAP Object Identifier [BCP64bis]
 180   to identify the LDAP No-Op Control defined in this document.
 181
 182       Subject: Request for LDAP Object Identifier Registration
 183       Person & email address to contact for further information:
 184           Kurt Zeilenga <kurt@OpenLDAP.org>
 185       Specification: RFC XXXX
 186       Author/Change Controller: IESG
 187       Comments:
 188           Identifies the LDAP No-Op Control
 189
 190
 191 4.2  LDAP Protocol Mechanism
 192
 193   Registration of this protocol mechanism is requested [RFC3383].
 194
 195   Subject: Request for LDAP Protocol Mechanism Registration
 196   Object Identifier: IANA-ASSIGNED-OID
 197   Description: No-Op 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 4.3  LDAP Result Code
 207
 208   Assignment of an LDAP Result Code called 'noOperation' is requested.
 209
 210       Subject: LDAP Result Code Registration
 211       Person & email address to contact for further information:
 212           Kurt Zeilenga <kurt@OpenLDAP.org>
 213       Result Code Name: noOperation
 214       Specification: RFC XXXX
 215       Author/Change Controller: IESG
 216       Comments:  none
 217
 218
 219 5.  Author's Address
 220
 221   Kurt D. Zeilenga
 222   OpenLDAP Foundation
 223
 224
 225
 226 Zeilenga                   LDAP No-Op Control                   [Page 4]
 227 \f
 228 INTERNET-DRAFT         draft-zeilenga-ldap-noop-07       28 October 2005
 229
 230
 231   Email: Kurt@OpenLDAP.org
 232
 233
 234 6. References
 235
 236   [[Note to the RFC Editor: please replace the citation tags used in
 237   referencing Internet-Drafts with tags of the form RFCnnnn where
 238   possible.]]
 239
 240
 241 6.1. Normative References
 242
 243   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 244                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 245
 246   [Protocol]    Sermersheim, J. (editor), "LDAP: The Protocol",
 247                 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
 248
 249   [Roadmap]     Zeilenga, K. (editor), "LDAP: Technical Specification
 250                 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
 251                 progress.
 252
 253   [Models]      Zeilenga, K. (editor), "LDAP: Directory Information
 254                 Models", draft-ietf-ldapbis-models-xx.txt, a work in
 255                 progress.
 256
 257
 258 6.2. Informative References
 259
 260   [X.500]       International Telecommunication Union -
 261                 Telecommunication Standardization Sector, "The Directory
 262                 -- Overview of concepts, models and services,"
 263                 X.500(1993) (also ISO/IEC 9594-1:1994).
 264
 265   [RFC2820]     Stokes, E., et. al., "Access Control Requirements for
 266                 LDAP", RFC 2820, May 2000.
 267
 268   [RFC3062]     Zeilenga, K., "LDAP Password Modify Extended Operation",
 269                 RFC 3062, February 2000.
 270
 271   [BCP64bis]    Zeilenga, K., "IANA Considerations for LDAP",
 272                 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
 273
 274
 275
 276 Intellectual Property Rights
 277
 278   The IETF takes no position regarding the validity or scope of any
 279
 280
 281
 282 Zeilenga                   LDAP No-Op Control                   [Page 5]
 283 \f
 284 INTERNET-DRAFT         draft-zeilenga-ldap-noop-07       28 October 2005
 285
 286
 287   Intellectual Property Rights or other rights that might be claimed to
 288   pertain to the implementation or use of the technology described in
 289   this document or the extent to which any license under such rights
 290   might or might not be available; nor does it represent that it has
 291   made any independent effort to identify any such rights.  Information
 292   on the procedures with respect to rights in RFC documents can be found
 293   in BCP 78 and BCP 79.
 294
 295   Copies of IPR disclosures made to the IETF Secretariat and any
 296   assurances of licenses to be made available, or the result of an
 297   attempt made to obtain a general license or permission for the use of
 298   such proprietary rights by implementers or users of this specification
 299   can be obtained from the IETF on-line IPR repository at
 300   http://www.ietf.org/ipr.
 301
 302   The IETF invites any interested party to bring to its attention any
 303   copyrights, patents or patent applications, or other proprietary
 304   rights that may cover technology that may be required to implement
 305   this standard.  Please address the information to the IETF at
 306   ietf-ipr@ietf.org.
 307
 308
 309
 310 Full Copyright
 311
 312   Copyright (C) The Internet Society (2005).
 313
 314   This document is subject to the rights, licenses and restrictions
 315   contained in BCP 78, and except as set forth therein, the authors
 316   retain all their rights.
 317
 318   This document and the information contained herein are provided on an
 319   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 320   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 321   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 322   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 323   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 324   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Zeilenga                   LDAP No-Op Control                   [Page 6]
 339 \f