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

   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 \f
  60 RFC 4370           LDAP Proxied Authorization Control      February 2006
  61
  62
  63 2.  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
  70 3.  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
 105 4.  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
 114 Weltman                     Standards Track                     [Page 2]
 115 \f
 116 RFC 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
 129 5.  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
 143 6.  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
 153 7.  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
 170 Weltman                     Standards Track                     [Page 3]
 171 \f
 172 RFC 4370           LDAP Proxied Authorization Control      February 2006
 173
 174
 175 8.  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
 208 Author'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
 226 Weltman                     Standards Track                     [Page 4]
 227 \f
 228 RFC 4370           LDAP Proxied Authorization Control      February 2006
 229
 230
 231 Full 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
 247 Intellectual 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
 271 Acknowledgement
 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
 282 Weltman                     Standards Track                     [Page 5]
 283 \f