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                      Isode Limited
   9 Expires in six months                               14 February 2007
  10
  11
  12
  13                           The LDAP No-Op Control
  14                     <draft-zeilenga-ldap-noop-10.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.Zeilenga@Isode.COM>.
  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 IETF Trust (2007).  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-10      14 February 2007
  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   [RFC4511] 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   [RFC4510] 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 [RFC4511], 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-10      14 February 2007
 117
 118
 119 2.  No-Op Control
 120
 121   The No-Op control is an LDAP Control [RFC4511] 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 [RFC4511].  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   [RFC4512] 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 [RFC4511] extended by
 163   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-10      14 February 2007
 173
 174
 175 4.  IANA Considerations
 176
 177 4.1.  Object Identifier
 178
 179   It is requested that IANA assign an LDAP Object Identifier [RFC4520]
 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.Zeilenga@Isode.COM>
 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 [RFC4520].
 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.Zeilenga@Isode.COM>
 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.Zeilenga@Isode.COM>
 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   Isode Limited
 223
 224
 225
 226 Zeilenga                   LDAP No-Op Control                   [Page 4]
 227 \f
 228 INTERNET-DRAFT         draft-zeilenga-ldap-noop-10      14 February 2007
 229
 230
 231   Email: Kurt.Zeilenga@Isode.COM
 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   [RFC4510]     Zeilenga, K. (editor), "LDAP: Technical Specification
 247                 Road Map", RFC 4510, June 2006.
 248
 249   [RFC4511]     Sermersheim, J. (editor), "LDAP: The Protocol", RFC
 250                 4511, June 2006.
 251
 252   [RFC4512]     Zeilenga, K. (editor), "LDAP: Directory Information
 253                 Models", RFC 4512, June 2006.
 254
 255
 256 6.2. Informative References
 257
 258   [X.500]       International Telecommunication Union -
 259                 Telecommunication Standardization Sector, "The Directory
 260                 -- Overview of concepts, models and services,"
 261                 X.500(1993) (also ISO/IEC 9594-1:1994).
 262
 263   [RFC2820]     Stokes, E., et. al., "Access Control Requirements for
 264                 LDAP", RFC 2820, May 2000.
 265
 266   [RFC3062]     Zeilenga, K., "LDAP Password Modify Extended Operation",
 267                 RFC 3062, February 2000.
 268
 269   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
 270                 (IANA) Considerations for the Lightweight Directory
 271                 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006.
 272
 273
 274
 275 Intellectual Property
 276
 277   The IETF takes no position regarding the validity or scope of any
 278   Intellectual Property Rights or other rights that might be claimed to
 279
 280
 281
 282 Zeilenga                   LDAP No-Op Control                   [Page 5]
 283 \f
 284 INTERNET-DRAFT         draft-zeilenga-ldap-noop-10      14 February 2007
 285
 286
 287   pertain to the implementation or use of the technology described in
 288   this document or the extent to which any license under such rights
 289   might or might not be available; nor does it represent that it has
 290   made any independent effort to identify any such rights.  Information
 291   on the procedures with respect to rights in RFC documents can be found
 292   in BCP 78 and BCP 79.
 293
 294   Copies of IPR disclosures made to the IETF Secretariat and any
 295   assurances of licenses to be made available, or the result of an
 296   attempt made to obtain a general license or permission for the use of
 297   such proprietary rights by implementers or users of this specification
 298   can be obtained from the IETF on-line IPR repository at
 299   http://www.ietf.org/ipr.
 300
 301   The IETF invites any interested party to bring to its attention any
 302   copyrights, patents or patent applications, or other proprietary
 303   rights that may cover technology that may be required to implement
 304   this standard.  Please address the information to the IETF at
 305   ietf-ipr@ietf.org.
 306
 307
 308
 309 Full Copyright
 310
 311   Copyright (C) The IETF Trust (2007).
 312
 313   This document is subject to the rights, licenses and restrictions
 314   contained in BCP 78, and except as set forth therein, the authors
 315   retain all their rights.
 316
 317   This document and the information contained herein are provided on an
 318   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 319   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 320   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 321   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 322   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 323   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Zeilenga                   LDAP No-Op Control                   [Page 6]
 339 \f