idnits 2.17.1 draft-zeilenga-ldap-dontusecopy-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 January 2011) is 4852 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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 Isode Limited 4 Expires in six months 6 January 2011 6 The LDAP Don't Use Copy 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 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 Abstract 41 This document defines the Lightweight Directory Access Protocol (LDAP) 42 Don't Use Copy control extension which allows a client to specify that 43 copied information should not be used in providing service. This 44 control is based upon the X.511 dontUseCopy service control option. 46 1. Background and Intended Usage 48 This document defines the Lightweight Directory Access Protocol (LDAP) 49 [RFC4510] Don't Use Copy control extension. The control may be 50 attached to request messages to indicate that copied (replicated or 51 cached) information [X.500] is not be used in providing service. This 52 control is based upon the X.511 [X.511] dontUseCopy service control 53 option. 55 The Don't Use Copy control is intended to be used where the client 56 requires the service be provided using original (master) information 57 [X.500]. In absence of this control, the server is free to make use 58 of copied information in providing the requested service. 60 For instance, a client might desire to have an authoritative answer to 61 a question of whether or not a particular user is a member of a group. 62 To ask this question of a server, the client might issue a compare 63 request [RFC4511], with the Don't Use Copy control, where the entry 64 parameter is the Distinguished Name (DN) of the group, the 65 ava.attributeDesc is 'member', and the ava.assertionValue is the DN of 66 the user the client desires to know is or isn't a member of the group. 67 If the server has access to the original (master) information directly 68 or through chaining, it performs the operation against the original 69 (master) information and return compareTrue or compareFalse (or an 70 error). If the server does not have access to the orignal 71 information, the server is obligated to either return a referral or an 72 error. 74 It is noted that a referral, if returned, is not necessarily to the 75 server holding the original (master) information. It is also noted 76 that an authoritative answer to the question might not be available to 77 the client for any number of reasons. 79 Where the client chases a referral to a server as referenced by an 80 LDAP URL in the server response in order to obtain an authorative 81 response , the client MUST provide the dontUseCopy control with the 82 interrogation request it makes to the referred to server. While LDAP 83 allows return of other kinds of URIs, the syntax and semantics of 84 other kinds of URIs, as well the particulars of acting upon such other 85 kinds of URIs, to future specifications. This document also leaves 86 the particulars of how to act upon other kinds of URIs to future 87 specifications. It is noted that in absence of some assurance that 88 only authoratitive information is used in producing an answer, the 89 client ought to assume non-authorative information is used. 91 It is not intended that this control be used generally (e.g., for all 92 LDAP interrogation operations) but only as required to ensure proper 93 directory application behavior. In general, directory applications 94 ought to designed to well use copied information. 96 2. Terminology 98 DSA stands for Directory System Agent (or server). 99 DSE stands for DSA-specific Entry. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 3. The Don't Use Copy Control 107 The Don't Use Copy control is an LDAP Control [RFC4511] whose 108 controlType is IANA-ASSIGNED-OID and controlValue is absent. The 109 criticality MUST be TRUE. There is no corresponding response control. 111 The control is appropriate for LDAP interrogation operations, 112 including Compare and Search operations [RFC4511]. It is 113 inappropriate for all other operations, including Abandon, Bind, 114 Delete, Modify, ModifyDN, StartTLS, and Unbind operations [RFC4511]. 116 When the control is attached to an LDAP request, the requested 117 operation MUST NOT be performed on copied information. That is, the 118 requested operation MUST be performed on original information. 120 If original (master) information for the target or base object of the 121 operation is not available (either locally or through chaining), the 122 server MUST either return a referral directing the client to a server 123 believed to be better able to service the request or return an 124 appropriate result code (e.g., unwillingToPerform). 126 Servers implementing this technical specification SHOULD publish the 127 object identifier IANA-ASSIGNED-OID as a value of the 128 'supportedControl' attribute [RFC4512] in their root DSE. A server 129 MAY choose to advertise this extension only when the client is 130 authorized to use it. 132 4. Security Considerations 134 This control is intended to be provided where providing service using 135 copied information might lead to unexpected application behavior. 137 Use of the Don't Use Copy control may permit an attacker to perform or 138 amplify a Denial of Service attack by causing additional server 139 resources to be employed, such as when the server chooses to chain the 140 request instead of returning a referral. Server capable of such 141 chaining can mitigate this threat by limiting chaining to a particular 142 group of authenticated entities. 144 LDAP is frequently used for storage and distribution of security 145 sensitive information, including access control and security policy 146 information. Failure to use the Don't Use Copy control may thus permit 147 an attacker to gain unauthorized access by allowing reliance on stale 148 data. 150 5. IANA Considerations 152 5.1. Object Identifier 154 It is requested that IANA assign upon Standards Action an LDAP Object 155 Identifier [RFC4520] to identify the LDAP Don't Use Copy Control 156 defined in this document. 158 Subject: Request for LDAP Object Identifier Registration 159 Person & email address to contact for further information: 160 Kurt Zeilenga 161 Specification: RFC XXXX 162 Author/Change Controller: IESG 163 Comments: 164 Identifies the LDAP Don't Use Copy Control 166 5.2 LDAP Protocol Mechanism 168 Registration of this protocol mechanism [RFC4520] is requested. 170 Subject: Request for LDAP Protocol Mechanism Registration 171 Object Identifier: IANA-ASSIGNED-OID 172 Description: Don't Use Copy Control 173 Person & email address to contact for further information: 174 Kurt Zeilenga 175 Usage: Control 176 Specification: RFC XXXX 177 Author/Change Controller: IESG 178 Comments: none 180 6. Acknowledgements 182 The author thanks Ben Campbell, Phillip Hallam-Baker, and Ted Hardie 183 for providing review and specific suggestions. 185 7. Author's Address 187 Kurt D. Zeilenga 188 Isode Limited 190 Email: Kurt.Zeilenga@Isode.COM 192 8. References 194 [[Note to the RFC Editor: please replace the citation tags used in 195 referencing Internet-Drafts with tags of the form RFCnnnn where 196 possible.]] 198 8.1. Normative References 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 203 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 204 Road Map", RFC 4510, June 2006. 206 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 207 4511, June 2006. 209 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 210 Models", RFC 4512, June 2006. 212 8.2. Informative References 214 [X.500] International Telecommunication Union - 215 Telecommunication Standardization Sector, "The Directory 216 -- Overview of concepts, models and services," 217 X.500(1993) (also ISO/IEC 9594-1:1994). 219 [X.511] International Telecommunication Union - 220 Telecommunication Standardization Sector, "The 221 Directory: Abstract Service Definition", X.511(1993) 222 (also ISO/IEC 9594-3:1993). 224 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 225 (IANA) Considerations for the Lightweight Directory 226 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006. 228 Full Copyright 230 Copyright (c) 2011 IETF Trust and the persons identified as the 231 document authors. All rights reserved. 233 This document is subject to BCP 78 and the IETF Trust's Legal 234 Provisions Relating to IETF Documents 235 (http://trustee.ietf.org/license-info) in effect on the date of 236 publication of this document. Please review these documents carefully, 237 as they describe your rights and restrictions with respect to this 238 document. Code Components extracted from this document must include 239 Simplified BSD License text as described in Section 4.e of the Trust 240 Legal Provisions and are provided without warranty as described in the 241 Simplified BSD License. 243 This document may contain material from IETF Documents or IETF 244 Contributions published or made publicly available before November 10, 245 2008. The person(s) controlling the copyright in some of this material 246 may not have granted the IETF Trust the right to allow modifications 247 of such material outside the IETF Standards Process. Without 248 obtaining an adequate license from the person(s) controlling the 249 copyright in such materials, this document may not be modified outside 250 the IETF Standards Process, and derivative works of it may not be 251 created outside the IETF Standards Process, except to format it for 252 publication as an RFC or to translate it into languages other than 253 English.