git.sur5r.net Git - openldap/blob - doc/rfc/rfc3829.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         R. Weltman
   8 Request for Comments: 3829                                America Online
   9 Category: 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
  17 Status 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
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2004).
  26
  27 Abstract
  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
  35 1.  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
  58 Weltman, et al.              Informational                      [Page 1]
  59 \f
  60 RFC 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
  67 2.  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
  76 3.  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
  86 4.  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
 114 Weltman, et al.              Informational                      [Page 2]
 115 \f
 116 RFC 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
 141 5.  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
 155 6.  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
 170 Weltman, et al.              Informational                      [Page 3]
 171 \f
 172 RFC 3829          Authorization Identity Bind Control          July 2004
 173
 174
 175 7.  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
 182 8.  References
 183
 184 8.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
 211 8.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
 226 Weltman, et al.              Informational                      [Page 4]
 227 \f
 228 RFC 3829          Authorization Identity Bind Control          July 2004
 229
 230
 231 9.  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
 282 Weltman, et al.              Informational                      [Page 5]
 283 \f
 284 RFC 3829          Authorization Identity Bind Control          July 2004
 285
 286
 287 10.  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
 301 Intellectual 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
 325 Acknowledgement
 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
 338 Weltman, et al.              Informational                      [Page 6]
 339 \f