1 2 3 4 5 6 7Network Working Group K. Zeilenga 8Request for Comments: 3673 OpenLDAP Foundation 9Category: Standards Track December 2003 10 11 12 Lightweight Directory Access Protocol version 3 (LDAPv3): 13 All Operational Attributes 14 15Status of this Memo 16 17 This document specifies an Internet standards track protocol for the 18 Internet community, and requests discussion and suggestions for 19 improvements. Please refer to the current edition of the "Internet 20 Official Protocol Standards" (STD 1) for the standardization state 21 and status of this protocol. Distribution of this memo is unlimited. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (2003). All Rights Reserved. 26 27Abstract 28 29 The Lightweight Directory Access Protocol (LDAP) supports a mechanism 30 for requesting the return of all user attributes but not all 31 operational attributes. This document describes an LDAP extension 32 which clients may use to request the return of all operational 33 attributes. 34 351. Overview 36 37 X.500 [X.500] provides a mechanism for clients to request all 38 operational attributes be returned with entries provided in response 39 to a search operation. This mechanism is often used by clients to 40 discover which operational attributes are present in an entry. 41 42 This documents extends the Lightweight Directory Access Protocol 43 (LDAP) [RFC3377] to provide a simple mechanism which clients may use 44 to request the return of all operational attributes. The mechanism 45 is designed for use with existing general purpose LDAP clients 46 (including web browsers which support LDAP URLs) and existing LDAP 47 APIs. 48 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in BCP 14 [RFC2119]. 52 53 54 55 56 57 58Zeilenga Standards Track [Page 1] 59 60RFC 3673 LDAPv3: All Operational Attributes December 2003 61 62 632. All Operational Attributes 64 65 The presence of the attribute description "+" (ASCII 43) in the list 66 of attributes in a Search Request [RFC2251] SHALL signify a request 67 for the return of all operational attributes. 68 69 As with all search requests, client implementors should note that 70 results may not include all requested attributes due to access 71 controls or other restrictions. Client implementors should also note 72 that certain operational attributes may be returned only if requested 73 by name even when "+" is present. This is because some operational 74 attributes are very expensive to return. 75 76 Servers supporting this feature SHOULD publish the Object Identifier 77 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures' 78 [RFC3674] attribute in the root DSE. 79 803. Interoperability Considerations 81 82 This mechanism is specifically designed to allow users to request all 83 operational attributes using existing LDAP clients. In particular, 84 the mechanism is designed to be compatible with existing general 85 purpose LDAP clients including those supporting LDAP URLs [RFC2255]. 86 87 The addition of this mechanism to LDAP is not believed to cause any 88 significant interoperability issues (this has been confirmed through 89 testing). Servers which have yet to implement this specification 90 should ignore the "+" as an unrecognized attribute description per 91 [RFC2251, Section 4.5.1]. From the client's perspective, a server 92 which does not return all operational attributes when "+" is 93 requested should be viewed as having other restrictions. 94 95 It is also noted that this mechanism is believed to require no 96 modification of existing LDAP APIs. 97 984. Security Considerations 99 100 This document provides a general mechanism which clients may use to 101 discover operational attributes. Prior to the introduction of this 102 mechanism, operational attributes were only returned when requested 103 by name. Some might have viewed this as obscurity feature. However, 104 this feature offers a false sense of security as the attributes were 105 still transferable. 106 107 Implementations SHOULD implement appropriate access controls 108 mechanisms to restricts access to operational attributes. 109 110 111 112 113 114Zeilenga Standards Track [Page 2] 115 116RFC 3673 LDAPv3: All Operational Attributes December 2003 117 118 1195. IANA Considerations 120 121 This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the 122 feature described above. This OID was assigned [ASSIGN] by OpenLDAP 123 Foundation, under its IANA-assigned private enterprise allocation 124 [PRIVATE], for use in this specification. 125 126 Registration of this feature has been completed by IANA [RFC3674], 127 [RFC3383]. 128 129 Subject: Request for LDAP Protocol Mechanism Registration 130 131 Object Identifier: 1.3.6.1.4.1.4203.1.5.1 132 133 Description: All Op Attrs 134 135 Person & email address to contact for further information: 136 Kurt Zeilenga <kurt@openldap.org> 137 138 Usage: Feature 139 140 Specification: RFC3673 141 142 Author/Change Controller: IESG 143 144 Comments: none 145 1466. Acknowledgment 147 148 The "+" mechanism is believed to have been first suggested by Bruce 149 Greenblatt in a November 1998 post to the IETF LDAPext Working Group 150 mailing list. 151 1527. Intellectual Property Statement 153 154 The IETF takes no position regarding the validity or scope of any 155 intellectual property or other rights that might be claimed to 156 pertain to the implementation or use of the technology described in 157 this document or the extent to which any license under such rights 158 might or might not be available; neither does it represent that it 159 has made any effort to identify any such rights. Information on the 160 IETF's procedures with respect to rights in standards-track and 161 standards-related documentation can be found in BCP-11. Copies of 162 claims of rights made available for publication and any assurances of 163 licenses to be made available, or the result of an attempt made to 164 obtain a general license or permission for the use of such 165 proprietary rights by implementors or users of this specification can 166 be obtained from the IETF Secretariat. 167 168 169 170Zeilenga Standards Track [Page 3] 171 172RFC 3673 LDAPv3: All Operational Attributes December 2003 173 174 175 The IETF invites any interested party to bring to its attention any 176 copyrights, patents or patent applications, or other proprietary 177 rights which may cover technology that may be required to practice 178 this standard. Please address the information to the IETF Executive 179 Director. 180 1818. References 182 1838.1. Normative References 184 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 187 188 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 189 Access Protocol (v3)", RFC 2251, December 1997. 190 191 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 192 Protocol (v3): Technical Specification", RFC 3377, 193 September 2002. 194 195 [RFC3674] Zeilenga, K., "Feature Discovery in Lightweight Directory 196 Access Protocol (LDAP)", RFC 3674, December 2003. 197 1988.2. Informative References 199 200 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, 201 December 1997. 202 203 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 204 Considerations for the Lightweight Directory Access 205 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 206 207 [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, 208 Models and Service", 1993. 209 210 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 211 http://www.openldap.org/foundation/oid-delegate.txt. 212 213 [PRIVATE] IANA, "Private Enterprise Numbers", 214 http://www.iana.org/assignments/enterprise-numbers. 215 2169. Author's Address 217 218 Kurt D. Zeilenga 219 OpenLDAP Foundation 220 221 EMail: Kurt@OpenLDAP.org 222 223 224 225 226Zeilenga Standards Track [Page 4] 227 228RFC 3673 LDAPv3: All Operational Attributes December 2003 229 230 23110. Full Copyright Statement 232 233 Copyright (C) The Internet Society (2003). All Rights Reserved. 234 235 This document and translations of it may be copied and furnished to 236 others, and derivative works that comment on or otherwise explain it 237 or assist in its implementation may be prepared, copied, published 238 and distributed, in whole or in part, without restriction of any 239 kind, provided that the above copyright notice and this paragraph are 240 included on all such copies and derivative works. However, this 241 document itself may not be modified in any way, such as by removing 242 the copyright notice or references to the Internet Society or other 243 Internet organizations, except as needed for the purpose of 244 developing Internet standards in which case the procedures for 245 copyrights defined in the Internet Standards process must be 246 followed, or as required to translate it into languages other than 247 English. 248 249 The limited permissions granted above are perpetual and will not be 250 revoked by the Internet Society or its successors or assignees. 251 252 This document and the information contained herein is provided on an 253 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 254 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 255 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 256 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 257 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 258 259Acknowledgement 260 261 Funding for the RFC Editor function is currently provided by the 262 Internet Society. 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282Zeilenga Standards Track [Page 5] 283 284