idnits 2.17.1 draft-zeilenga-ldap-noop-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 241. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 245), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 June 2006) is 6508 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'U12' is mentioned on line 77, but not defined == Missing Reference: 'Roadmap' is mentioned on line 133, but not defined Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 25 June 2006 6 The LDAP No-Op Control 7 9 Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the IESG for consideration as a Standard Track 13 document. Distribution of this memo is unlimited. Technical 14 discussion of this document will take place on the IETF LDAP 15 Extensions mailing list . Please send editorial 16 comments directly to the author . 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he or she becomes aware 21 will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright (C) The Internet Society (2006). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 45 This document defines the Lightweight Directory Access Protocol (LDAP) 46 No-Op control which can be used to disable the normal effect of an 47 operation. The control can be used to discover how a server might 48 react to a particular update request without updating the directory. 50 1. Overview 52 It is often desirable to be able to determine if a directory operation 53 [RFC4511] would successful complete or not without having the normal 54 effect of the operation take place. For example, an administrative 55 client might want to verify that new user could update their entry 56 (and not other entries) without the directory actually being updated. 57 The mechanism could be used to build more sophisticated security 58 auditing tools. 60 This document defines the Lightweight Directory Access Protocol (LDAP) 61 [RFC4510] No-Op control extension. The presence of the No-Op control 62 in an operation request message disables its normal effect upon the 63 directory which operation would otherwise have. Instead of updating 64 the directory and returning the normal indication of success, the 65 server does not update the directory and indicates so by returning the 66 noOperation resultCode (introduced below). 68 For example, when the No-Op control is present in a LDAP modify 69 operation [RFC4511], the server is do all processing necessary to 70 perform the operation without actually updating the directory. If it 71 detects an error during this processing, it returns a non-success 72 (other than noOperation) resultCode as it normally would. Otherwise, 73 it returns the noOperation. In either case, the directory is left 74 unchanged. 76 This No-Op control is not intended to be to an "effective access" 77 mechanism [RFC2820, U12]. 79 1.1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in BCP 14 [RFC2119]. 85 DN stands for Distinguished Name. 86 DSA stands for Directory System Agent. 87 DSE stands for DSA-specific entry. 89 2. No-Op Control 91 The No-Op control is an LDAP Control [RFC4511] whose controlType is 92 IANA-ASSIGNED-OID and controlValue is absent. Clients MUST provide a 93 criticality value of TRUE to prevent unintended modification of the 94 directory. 96 The control is appropriate for request messages of LDAP Add, Delete, 97 Modify and ModifyDN operations [RFC4511]. The control is also 98 appropriate for requests of extended operations which update the 99 directory (or other data stores), such as Password Modify Extended 100 Operation [RFC3062]. There is no corresponding response control. 102 When the control is attached to an LDAP request, the server does all 103 normal processing possible for the operation without modification of 104 the directory. That is, when the control is attached to an LDAP 105 request, the directory SHALL NOT be updated and the response SHALL NOT 106 have a resultCode of success (0). 108 A result code other than noOperation (IANA-ASSIGNED-CODE) means that 109 the server is unable or unwilling to complete the processing for the 110 reason indicated by the result code. A result code of noOperation 111 (IANA-ASSIGNED-CODE) indicates that the server discovered no reason 112 why the operation would fail if submitted without the No-Op control. 113 It is noted that there may be reasons why the operation may fail which 114 are only discoverable when submitting without the No-Op control. 116 Servers SHOULD indicate their support for this control by providing 117 IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute type 118 [RFC4512] in their root DSE entry. A server MAY choose to advertise 119 this extension only when the client is authorized to use this 120 operation. 122 3. Security Considerations 124 The No-Op control mechanism allows directory administrators and users 125 to verify that access control and other administrative policy controls 126 are properly configured. The mechanism may also lead to the 127 development (and deployment) of more effective security auditing 128 tools. 130 Implementors of this LDAP extension should be familiar with security 131 considerations applicable to the LDAP operations [RFC4511] extended by 132 this control, as well as general LDAP security considerations 133 [Roadmap]. 135 4. IANA Considerations 137 4.1. Object Identifier 139 It is requested that IANA assign an LDAP Object Identifier [RFC4520] 140 to identify the LDAP No-Op Control defined in this document. 142 Subject: Request for LDAP Object Identifier Registration 143 Person & email address to contact for further information: 144 Kurt Zeilenga 145 Specification: RFC XXXX 146 Author/Change Controller: IESG 147 Comments: 148 Identifies the LDAP No-Op Control 150 4.2 LDAP Protocol Mechanism 152 Registration of this protocol mechanism is requested [RFC4520]. 154 Subject: Request for LDAP Protocol Mechanism Registration 155 Object Identifier: IANA-ASSIGNED-OID 156 Description: No-Op Control 157 Person & email address to contact for further information: 158 Kurt Zeilenga 159 Usage: Control 160 Specification: RFC XXXX 161 Author/Change Controller: IESG 162 Comments: none 164 4.3 LDAP Result Code 166 Assignment of an LDAP Result Code called 'noOperation' is requested. 168 Subject: LDAP Result Code Registration 169 Person & email address to contact for further information: 170 Kurt Zeilenga 171 Result Code Name: noOperation 172 Specification: RFC XXXX 173 Author/Change Controller: IESG 174 Comments: none 176 5. Author's Address 178 Kurt D. Zeilenga 179 OpenLDAP Foundation 180 Email: Kurt@OpenLDAP.org 182 6. References 184 [[Note to the RFC Editor: please replace the citation tags used in 185 referencing Internet-Drafts with tags of the form RFCnnnn where 186 possible.]] 188 6.1. Normative References 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 193 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 194 Road Map", RFC 4510, June 2006. 196 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 197 4511, June 2006. 199 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 200 Models", RFC 4512, June 2006. 202 6.2. Informative References 204 [X.500] International Telecommunication Union - 205 Telecommunication Standardization Sector, "The Directory 206 -- Overview of concepts, models and services," 207 X.500(1993) (also ISO/IEC 9594-1:1994). 209 [RFC2820] Stokes, E., et. al., "Access Control Requirements for 210 LDAP", RFC 2820, May 2000. 212 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 213 RFC 3062, February 2000. 215 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 216 (IANA) Considerations for the Lightweight Directory 217 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006. 219 Intellectual Property 221 The IETF takes no position regarding the validity or scope of any 222 Intellectual Property Rights or other rights that might be claimed to 223 pertain to the implementation or use of the technology described in 224 this document or the extent to which any license under such rights 225 might or might not be available; nor does it represent that it has 226 made any independent effort to identify any such rights. Information 227 on the procedures with respect to rights in RFC documents can be found 228 in BCP 78 and BCP 79. 230 Copies of IPR disclosures made to the IETF Secretariat and any 231 assurances of licenses to be made available, or the result of an 232 attempt made to obtain a general license or permission for the use of 233 such proprietary rights by implementers or users of this specification 234 can be obtained from the IETF on-line IPR repository at 235 http://www.ietf.org/ipr. 237 The IETF invites any interested party to bring to its attention any 238 copyrights, patents or patent applications, or other proprietary 239 rights that may cover technology that may be required to implement 240 this standard. Please address the information to the IETF at 241 ietf-ipr@ietf.org. 243 Full Copyright 245 Copyright (C) The Internet Society (2006). 247 This document is subject to the rights, licenses and restrictions 248 contained in BCP 78, and except as set forth therein, the authors 249 retain all their rights. 251 This document and the information contained herein are provided on an 252 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 253 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 254 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 255 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 256 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 257 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.