1 2 3 4 5 6 7Network Working Group R. Weltman 8Request for Comments: 3829 America Online 9Category: Informational M. Smith 10 Pearl Crescent, LLC 11 M. Wahl 12 July 2004 13 14 Lightweight Directory Access Protocol (LDAP) 15 Authorization Identity Request and Response Controls 16 17Status of this Memo 18 19 This memo provides information for the Internet community. It does 20 not specify an Internet standard of any kind. Distribution of this 21 memo is unlimited. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (2004). 26 27Abstract 28 29 This document extends the Lightweight Directory Access Protocol 30 (LDAP) bind operation with a mechanism for requesting and returning 31 the authorization identity it establishes. Specifically, this 32 document defines the Authorization Identity Request and Response 33 controls for use with the Bind operation. 34 351. Introduction 36 37 This document defines support for the Authorization Identity Request 38 Control and the Authorization Identity Response Control for 39 requesting and returning the authorization established in a bind 40 operation. The Authorization Identity Request Control may be 41 submitted by a client in a bind request if authenticating with 42 version 3 of the Lightweight Directory Access Protocol (LDAP) 43 protocol [LDAPv3]. In the LDAP server's bind response, it may then 44 include an Authorization Identity Response Control. The response 45 control contains the identity assumed by the client. This is useful 46 when there is a mapping step or other indirection during the bind, so 47 that the client can be told what LDAP identity was granted. Client 48 authentication with certificates is the primary situation where this 49 applies. Also, some Simple Authentication and Security Layer [SASL] 50 authentication mechanisms may not involve the client explicitly 51 providing a DN, or may result in an authorization identity which is 52 different from the authentication identity provided by the client 53 [AUTH]. 54 55 56 57 58Weltman, et al. Informational [Page 1] 59 60RFC 3829 Authorization Identity Bind Control July 2004 61 62 63 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 64 used in this document are to be interpreted as described in 65 [RFCKeyWords]. 66 672. Publishing support for the Authorization Identity Request Control 68 and the Authorization Identity Response Control 69 70 Support for the Authorization Identity Request Control and the 71 Authorization Identity Response Control is indicated by the presence 72 of the Object Identifiers (OIDs) 2.16.840.1.113730.3.4.16 and 73 2.16.840.1.113730.3.4.15, respectively, in the supportedControl 74 attribute [LDAPATTRS] of a server's root DSA-specific Entry (DSE). 75 763. Authorization Identity Request Control 77 78 This control MAY be included in any bind request which specifies 79 protocol version 3, as part of the controls field of the LDAPMessage 80 as defined in [LDAPPROT]. In a multi-step bind operation, the client 81 MUST provide the control with each bind request. 82 83 The controlType is "2.16.840.1.113730.3.4.16" and the controlValue is 84 absent. 85 864. Authorization Identity Response Control 87 88 This control MAY be included in any final bind response where the 89 first bind request of the bind operation included an Authorization 90 Identity Request Control as part of the controls field of the 91 LDAPMessage as defined in [LDAPPROT]. 92 93 The controlType is "2.16.840.1.113730.3.4.15". If the bind request 94 succeeded and resulted in an identity (not anonymous), the 95 controlValue contains the authorization identity (authzId), as 96 defined in [AUTH] section 9, granted to the requestor. If the bind 97 request resulted in an anonymous association, the controlValue field 98 is a string of zero length. If the bind request resulted in more 99 than one authzId, the primary authzId is returned in the controlValue 100 field. 101 102 The control is only included in a bind response if the resultCode for 103 the bind operation is success. 104 105 If the server requires confidentiality protections to be in place 106 prior to use of this control (see Security Considerations), the 107 server reports failure to have adequate confidentiality protections 108 in place by returning the confidentialityRequired result code. 109 110 111 112 113 114Weltman, et al. Informational [Page 2] 115 116RFC 3829 Authorization Identity Bind Control July 2004 117 118 119 If the client has insufficient access rights to the requested 120 authorization information, the server reports this by returning the 121 insufficientAccessRights result code. 122 123 Identities presented by a client as part of the authentication 124 process may be mapped by the server to one or more authorization 125 identities. The bind response control can be used to retrieve the 126 primary authzId. 127 128 For example, during client authentication with certificates [AUTH], a 129 client may possess more than one certificate and may not be able to 130 determine which one was ultimately selected for authentication to the 131 server. The subject DN field in the selected certificate may not 132 correspond exactly to a DN in the directory, but rather have gone 133 through a mapping process controlled by the server. Upon completing 134 the certificate-based authentication, the client may issue a SASL 135 [SASL] bind request, specifying the EXTERNAL mechanism and including 136 an Authorization Identity Request Control. The bind response MAY 137 include an Authorization Identity Response Control indicating the DN 138 in the server's Directory Information Tree (DIT) which the 139 certificate was mapped to. 140 1415. Alternative Approach with Extended Operation 142 143 The LDAP "Who am I?" [AUTHZID] extended operation provides a 144 mechanism to query the authorization identity associated with a bound 145 connection. Using an extended operation, as opposed to a bind 146 response control, allows a client to learn the authorization identity 147 after the bind has established integrity and data confidentiality 148 protections. The disadvantages of the extended operation approach 149 are coordination issues between "Who am I?" requests, bind requests, 150 and other requests, and that an extra operation is required to learn 151 the authorization identity. For multithreaded or high bandwidth 152 server application environments, the bind response approach may be 153 preferable. 154 1556. Security Considerations 156 157 The Authorization Identity Request and Response Controls are subject 158 to standard LDAP security considerations. The controls may be passed 159 over a secure as well as over an insecure channel. They are not 160 protected by security layers negotiated by the bind operation. 161 162 The response control allows for an additional authorization identity 163 to be passed. In some deployments, these identities may contain 164 confidential information which require privacy protection. In such 165 deployments, a security layer should be established prior to issuing 166 a bind request with an Authorization Identity Request Control. 167 168 169 170Weltman, et al. Informational [Page 3] 171 172RFC 3829 Authorization Identity Bind Control July 2004 173 174 1757. IANA Considerations 176 177 The OIDs 2.16.840.1.113730.3.4.16 and 2.16.840.1.113730.3.4.15 are 178 reserved for the Authorization Identity Request and Response 179 Controls, respectively. The Authorization Identity Request Control 180 has been registered as an LDAP Protocol Mechanism [IANALDAP]. 181 1828. References 183 1848.1. Normative References 185 186 [LDAPv3] Hodges, J. and R. Morgan, "Lightweight Directory Access 187 Protocol (v3): Technical Specification", RFC 3377, 188 September 2002. 189 190 [LDAPPROT] Wahl, M., Howes, T. and S. Kille, "Lightweight 191 Directory Access Protocol (v3)", RFC 2251, December 192 1997. 193 194 [RFCKeyWords] Bradner, S., "Key Words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, March 1997. 196 197 [AUTH] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, 198 "Authentication Methods for LDAP", RFC 2829, May 2000. 199 200 [SASL] Myers, J., "Simple Authentication and Security Layer 201 (SASL)", RFC 2222, October 1997. 202 203 [LDAPATTRS] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 204 "Lightweight Directory Access Protocol (v3): Attribute 205 Syntax Definitions", RFC 2252, December 1997. 206 207 [IANALDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access 208 Protocol (v3): Technical Specification", RFC 3377, 209 September 2002. 210 2118.2. Informative References 212 213 [AUTHZID] Zeilenga, K., "LDAP 'Who am I?' Operation", Work in 214 Progress, April 2002. 215 216 217 218 219 220 221 222 223 224 225 226Weltman, et al. Informational [Page 4] 227 228RFC 3829 Authorization Identity Bind Control July 2004 229 230 2319. Author's Addresses 232 233 Rob Weltman 234 America Online 235 360 W. Caribbean Drive 236 Sunnyvale, CA 94089 237 USA 238 239 Phone: +1 650 937-3194 240 EMail: robw@worldspot.com 241 242 243 Mark Smith 244 Pearl Crescent, LLC 245 447 Marlpool Drive 246 Saline, MI 48176 247 USA 248 249 Phone: +1 734 944-2856 250 EMail: mcs@pearlcrescent.com 251 252 253 Mark Wahl 254 PO Box 90626 255 Austin, TX 78709-0626 256 USA 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282Weltman, et al. Informational [Page 5] 283 284RFC 3829 Authorization Identity Bind Control July 2004 285 286 28710. Full Copyright Statement 288 289 Copyright (C) The Internet Society (2004). This document is subject 290 to the rights, licenses and restrictions contained in BCP 78, and 291 except as set forth therein, the authors retain all their rights. 292 293 This document and the information contained herein are provided on an 294 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 295 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 296 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 297 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 298 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 299 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 300 301Intellectual Property 302 303 The IETF takes no position regarding the validity or scope of any 304 Intellectual Property Rights or other rights that might be claimed to 305 pertain to the implementation or use of the technology described in 306 this document or the extent to which any license under such rights 307 might or might not be available; nor does it represent that it has 308 made any independent effort to identify any such rights. Information 309 on the procedures with respect to rights in RFC documents can be 310 found in BCP 78 and BCP 79. 311 312 Copies of IPR disclosures made to the IETF Secretariat and any 313 assurances of licenses to be made available, or the result of an 314 attempt made to obtain a general license or permission for the use of 315 such proprietary rights by implementers or users of this 316 specification can be obtained from the IETF on-line IPR repository at 317 http://www.ietf.org/ipr. 318 319 The IETF invites any interested party to bring to its attention any 320 copyrights, patents or patent applications, or other proprietary 321 rights that may cover technology that may be required to implement 322 this standard. Please address the information to the IETF at ietf- 323 ipr@ietf.org. 324 325Acknowledgement 326 327 Funding for the RFC Editor function is currently provided by the 328 Internet Society. 329 330 331 332 333 334 335 336 337 338Weltman, et al. Informational [Page 6] 339 340