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