1 2 3 4 5 6 7Network Working Group R. Weltman 8Request for Comments: 4370 Yahoo!, Inc. 9Category: Standards Track February 2006 10 11 12 Lightweight Directory Access Protocol (LDAP) 13 Proxied Authorization Control 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 (2006). 26 27Abstract 28 29 This document defines the Lightweight Directory Access Protocol 30 (LDAP) Proxy Authorization Control. The Proxy Authorization Control 31 allows a client to request that an operation be processed under a 32 provided authorization identity instead of under the current 33 authorization identity associated with the connection. 34 351. Introduction 36 37 Proxy authorization allows a client to request that an operation be 38 processed under a provided authorization identity instead of under 39 the current authorization identity associated with the connection. 40 This document defines support for proxy authorization using the 41 Control mechanism [RFC2251]. The Lightweight Directory Access 42 Protocol [LDAPV3] supports the use of the Simple Authentication and 43 Security Layer [SASL] for authentication and for supplying an 44 authorization identity distinct from the authentication identity, 45 where the authorization identity applies to the whole LDAP session. 46 The Proxy Authorization Control provides a mechanism for specifying 47 an authorization identity on a per-operation basis, benefiting 48 clients that need to perform operations efficiently on behalf of 49 multiple users. 50 51 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 52 used in this document are to be interpreted as described in 53 [KEYWORDS]. 54 55 56 57 58Weltman Standards Track [Page 1] 59 60RFC 4370 LDAP Proxied Authorization Control February 2006 61 62 632. Publishing Support for the Proxy Authorization Control 64 65 Support for the Proxy Authorization Control is indicated by the 66 presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in 67 the supportedControl attribute [RFC2252] of a server's root 68 DSA-specific Entry (DSE). 69 703. Proxy Authorization Control 71 72 A single Proxy Authorization Control may be included in any search, 73 compare, modify, add, delete, or modify Distinguished Name (DN) or 74 extended operation request message. The exception is any extension 75 that causes a change in authentication, authorization, or data 76 confidentiality [RFC2829], such as Start TLS [LDAPTLS] as part of the 77 controls field of the LDAPMessage, as defined in [RFC2251]. 78 79 The controlType of the proxy authorization control is 80 "2.16.840.1.113730.3.4.18". 81 82 The criticality MUST be present and MUST be TRUE. This requirement 83 protects clients from submitting a request that is executed with an 84 unintended authorization identity. 85 86 Clients MUST include the criticality flag and MUST set it to TRUE. 87 Servers MUST reject any request containing a Proxy Authorization 88 Control without a criticality flag or with the flag set to FALSE with 89 a protocolError error. These requirements protect clients from 90 submitting a request that is executed with an unintended 91 authorization identity. 92 93 The controlValue SHALL be present and SHALL either contain an authzId 94 [AUTH] representing the authorization identity for the request or be 95 empty if an anonymous association is to be used. 96 97 The mechanism for determining proxy access rights is specific to the 98 server's proxy authorization policy. 99 100 If the requested authorization identity is recognized by the server, 101 and the client is authorized to adopt the requested authorization 102 identity, the request will be executed as if submitted by the proxy 103 authorization identity; otherwise, the result code 123 is returned. 104 1054. Implementation Considerations 106 107 One possible interaction of proxy authorization and normal access 108 control is illustrated here. During evaluation of a search request, 109 an entry that would have been returned for the search (if submitted 110 by the proxy authorization identity directly) may not be returned if 111 112 113 114Weltman Standards Track [Page 2] 115 116RFC 4370 LDAP Proxied Authorization Control February 2006 117 118 119 the server finds that the requester does not have the right to assume 120 the requested identity for searching the entry, even if the entry is 121 within the scope of a search request under a base DN that does imply 122 such rights. This means that fewer results, or no results, may be 123 returned than would be if the proxy authorization identity issued the 124 request directly. An example of such a case may be a system with 125 fine-grained access control, where the proxy right requester has 126 proxy rights at the top of a search tree, but not at or below a point 127 or points within the tree. 128 1295. Security Considerations 130 131 The Proxy Authorization Control method is subject to general LDAP 132 security considerations [RFC2251] [AUTH] [LDAPTLS]. The control may 133 be passed over a secure channel as well as over an insecure channel. 134 135 The control allows for an additional authorization identity to be 136 passed. In some deployments, these identities may contain 137 confidential information that requires privacy protection. 138 139 Note that the server is responsible for determining if a proxy 140 authorization request is to be honored. "Anonymous" users SHOULD NOT 141 be allowed to assume the identity of others. 142 1436. IANA Considerations 144 145 The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy 146 Authorization Control. It has been registered as an LDAP Protocol 147 Mechanism [RFC3383]. 148 149 A result code (123) has been assigned by the IANA for the case where 150 the server does not execute a request using the proxy authorization 151 identity. 152 1537. Acknowledgements 154 155 Mark Smith, formerly of Netscape Communications Corp., Mark Wahl, 156 formerly of Sun Microsystems, Inc., Kurt Zeilenga of OpenLDAP 157 Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have 158 contributed with reviews of this document. 159 160 161 162 163 164 165 166 167 168 169 170Weltman Standards Track [Page 3] 171 172RFC 4370 LDAP Proxied Authorization Control February 2006 173 174 1758. Normative References 176 177 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 180 [LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access 181 Protocol (v3): Technical Specification", RFC 3377, 182 September 2002. 183 184 [SASL] Myers, J., "Simple Authentication and Security Layer 185 (SASL)", RFC 2222, October 1997. 186 187 [AUTH] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, 188 "Authentication Methods for LDAP", RFC 2829, May 2000. 189 190 [LDAPTLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight 191 Directory Access Protocol (v3): Extension for Transport 192 Layer Security", RFC 2830, May 2000. 193 194 [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 195 Access Protocol (v3)", RFC 2251, December 1997. 196 197 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, 198 "Lightweight Directory Access Protocol (v3): Attribute 199 Syntax Definitions", RFC 2252, December 1997. 200 201 [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, 202 "Authentication Methods for LDAP", RFC 2829, May 2000. 203 204 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 205 Considerations for the Lightweight Directory Access 206 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 207 208Author's Address 209 210 Rob Weltman 211 Yahoo!, Inc. 212 701 First Avenue 213 Sunnyvale, CA 94089 214 USA 215 216 Phone: +1 408 349-5504 217 EMail: robw@worldspot.com 218 219 220 221 222 223 224 225 226Weltman Standards Track [Page 4] 227 228RFC 4370 LDAP Proxied Authorization Control February 2006 229 230 231Full Copyright Statement 232 233 Copyright (C) The Internet Society (2006). 234 235 This document is subject to the rights, licenses and restrictions 236 contained in BCP 78, and except as set forth therein, the authors 237 retain all their rights. 238 239 This document and the information contained herein are provided on an 240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 241 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 242 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 243 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 244 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 245 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 246 247Intellectual Property 248 249 The IETF takes no position regarding the validity or scope of any 250 Intellectual Property Rights or other rights that might be claimed to 251 pertain to the implementation or use of the technology described in 252 this document or the extent to which any license under such rights 253 might or might not be available; nor does it represent that it has 254 made any independent effort to identify any such rights. Information 255 on the procedures with respect to rights in RFC documents can be 256 found in BCP 78 and BCP 79. 257 258 Copies of IPR disclosures made to the IETF Secretariat and any 259 assurances of licenses to be made available, or the result of an 260 attempt made to obtain a general license or permission for the use of 261 such proprietary rights by implementers or users of this 262 specification can be obtained from the IETF on-line IPR repository at 263 http://www.ietf.org/ipr. 264 265 The IETF invites any interested party to bring to its attention any 266 copyrights, patents or patent applications, or other proprietary 267 rights that may cover technology that may be required to implement 268 this standard. Please address the information to the IETF at 269 ietf-ipr@ietf.org. 270 271Acknowledgement 272 273 Funding for the RFC Editor function is provided by the IETF 274 Administrative Support Activity (IASA). 275 276 277 278 279 280 281 282Weltman Standards Track [Page 5] 283 284