+++ /dev/null
-
-
-INTERNET-DRAFT Rob Weltman
-Intended Category: Standards Track Yahoo!, Inc.
- June 2005
-
- LDAP Proxied Authorization Control
- draft-weltman-ldapv3-proxy-13.txt
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- This document defines the Lightweight Directory Access Protocol
- (LDAP) Proxy Authorization Control. The Proxy Authorization Control
- allows a client to request that an operation be processed under a
- provided authorization identity instead of as the current
- authorization identity associated with the connection.
-
-
-1. Introduction
-
- Proxy authorization allows a client to request that an operation be
- processed under a provided authorization identity instead of as the
- current authorization identity associated with the connection. This
- document defines support for proxy authorization using the Control
- mechanism [RFC 2251]. The Lightweight Directory Access Protocol
- [LDAPV3] supports the use of the Simple Authentication and Security
- Layer [SASL] for authentication and for supplying an authorization
- identity distinct from the authentication identity, where the
- authorization identity applies to the whole LDAP session. The Proxy
- Authorization Control provides a mechanism for specifying an
-
-Expires December 2005 [Page 1]
-\f
-PROXIED AUTHORIZATION CONTROL June 2005
-
-
- authorization identity on a per operation basis, benefiting clients
- that need to efficiently perform operations on behalf of multiple
- users.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
- used in this document are to be interpreted as described in
- [KEYWORDS].
-
-
-2. Publishing support for the Proxy Authorization Control
-
- Support for the Proxy Authorization Control is indicated by the
- presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in
- the supportedControl attribute [RFC 2252] of a server's root DSE.
-
-
-3. Proxy Authorization Control
-
- A single Proxy Authorization Control may be included in any search,
- compare, modify, add, delete, modify DN or extended operation request
- message with the exception of any extension that causes a change in
- authentication, authorization, or data confidentiality [RFC 2829],
- such as Start TLS [LDAPTLS] as part of the controls field of the
- LDAPMessage, as defined in [RFC 2251].
-
- The controlType of the proxy authorization control is
- "2.16.840.1.113730.3.4.18".
-
- The criticality MUST be present and MUST be TRUE. This requirement
- protects clients from submitting a request that is executed with an
- unintended authorization identity.
-
- Clients MUST include the criticality flag and MUST set it to TRUE.
- Servers MUST reject any request containing a Proxy Authorization
- Control without a criticality flag or with the flag set to FALSE with
- a protocolError error. These requirements protect clients from
- submitting a request that is executed with an unintended
- authorization identity.
-
- The controlValue SHALL be present and contain either an authzId
- [AUTH] representing the authorization identity for the request or
- empty if an anonymous association is to be used.
-
- The mechanism for determining proxy access rights is specific to the
- server's proxy authorization policy.
-
- If the requested authorization identity is recognized by the server,
- and the client is authorized to adopt the requested authorization
- identity, the request will be executed as if submitted by the proxy
- authorization identity, otherwise the result code TBD is returned.
- [Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced
- with an IANA assigned LDAP Result Code (see RFC 3383 section 3.6]
-
-
-Expires December 2005 [Page 2]
-\f
-PROXIED AUTHORIZATION CONTROL June 2005
-
-
-
-4. Implementation Considerations
-
- One possible interaction of proxy authorization and normal access
- control is illustrated here for the case of search requests. During
- evaluation of a search request, an entry which would have been
- returned for the search if submitted by the proxy authorization
- identity directly may not be returned if the server finds that the
- requester does not have the right to assume the requested identity
- for searching the entry, even if the entry is within the scope of a
- search request under a base DN which does imply such rights. This
- means that fewer results, or no results, may be returned compared to
- the case where the proxy authorization identity issued the request
- directly. An example of such a case may be a system with fine-grained
- access control, where the proxy right requester has proxy rights at
- the top of a search tree, but not at or below a point or points
- within the tree.
-
-
-5. Security Considerations
-
- The Proxy Authorization Control method is subject to general LDAP
- security considerations [RFC 2251] [AUTH] [LDAPTLS]. The control may
- be passed over a secure as well as over an insecure channel.
-
- The control allows for an additional authorization identity to be
- passed. In some deployments, these identities may contain
- confidential information which require privacy protection.
-
- Note that the server is responsible for determining if a proxy
- authorization request is to be honored. "Anonymous" users SHOULD NOT
- be allowed to assume the identity of others.
-
-
-6. IANA Considerations
-
- The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy
- Authorization Control. It is to be registered as an LDAP Protocol
- Mechanism [RFC 3383].
-
- A result code for the case where the server does not execute a
- request using the proxy authorization identity is to be assigned by
- the IANA.
-
-
-7. Copyright
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
-
-Expires December 2005 [Page 3]
-\f
-PROXIED AUTHORIZATION CONTROL June 2005
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
-
-8. Normative References
-
-
- [KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate
- Requirement Levels", draft-bradner-key-words-03.txt, January,
- 1997.
-
- [LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377, September
- 2002.
-
- [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",
- RFC 2222, October 1997
-
- [AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
- Methods for LDAP", RFC 2829, May 2000
-
- [LDAPTLS] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer Security",
- RFC 2830, May 2000
-
- [RFC 2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions",
- RFC 2252, December 1997
-
-Expires December 2005 [Page 4]
-\f
-PROXIED AUTHORIZATION CONTROL June 2005
-
-
-
- [RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
- "Authentication Methods for LDAP", RFC 2829, May 2000
-
- [RFC 3383] K. Zeilenga, "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access Protocol
- (LDAP)", RFC 3383, September 2002
-
-9. Author's Address
-
- Rob Weltman
- Yahoo!, Inc
- 701 First Avenue
- Sunnyvale, CA 94089
- USA
- +1 408 349-5504
- robw@worldspot.com
-
-
-10. Acknowledgements
-
- Mark Smith, formerly of Netscape Communications Corp., Mark Wahl,
- formerly of Sun Microsystems, Inc, Kurt Zeilenga of OpenLDAP
- Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have
- contributed with reviews of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires December 2005 [Page 5]
-\f
\ No newline at end of file
rfc3909.txt LDAP Cancel Operation (PS)
rfc3928.txt LDAP Client Update Protocol (PS)
rfc4013.txt SASLprep (PS)
+rfc4370.txt LDAP Proxied Authorization Control (PS)
rfc4373.txt LBURP (I)
Legend:
--- /dev/null
+
+
+
+
+
+
+Network Working Group R. Weltman
+Request for Comments: 4370 Yahoo!, Inc.
+Category: Standards Track February 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Proxied Authorization Control
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAP) Proxy Authorization Control. The Proxy Authorization Control
+ allows a client to request that an operation be processed under a
+ provided authorization identity instead of under the current
+ authorization identity associated with the connection.
+
+1. Introduction
+
+ Proxy authorization allows a client to request that an operation be
+ processed under a provided authorization identity instead of under
+ the current authorization identity associated with the connection.
+ This document defines support for proxy authorization using the
+ Control mechanism [RFC2251]. The Lightweight Directory Access
+ Protocol [LDAPV3] supports the use of the Simple Authentication and
+ Security Layer [SASL] for authentication and for supplying an
+ authorization identity distinct from the authentication identity,
+ where the authorization identity applies to the whole LDAP session.
+ The Proxy Authorization Control provides a mechanism for specifying
+ an authorization identity on a per-operation basis, benefiting
+ clients that need to perform operations efficiently on behalf of
+ multiple users.
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ used in this document are to be interpreted as described in
+ [KEYWORDS].
+
+
+
+
+Weltman Standards Track [Page 1]
+\f
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+2. Publishing Support for the Proxy Authorization Control
+
+ Support for the Proxy Authorization Control is indicated by the
+ presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in
+ the supportedControl attribute [RFC2252] of a server's root
+ DSA-specific Entry (DSE).
+
+3. Proxy Authorization Control
+
+ A single Proxy Authorization Control may be included in any search,
+ compare, modify, add, delete, or modify Distinguished Name (DN) or
+ extended operation request message. The exception is any extension
+ that causes a change in authentication, authorization, or data
+ confidentiality [RFC2829], such as Start TLS [LDAPTLS] as part of the
+ controls field of the LDAPMessage, as defined in [RFC2251].
+
+ The controlType of the proxy authorization control is
+ "2.16.840.1.113730.3.4.18".
+
+ The criticality MUST be present and MUST be TRUE. This requirement
+ protects clients from submitting a request that is executed with an
+ unintended authorization identity.
+
+ Clients MUST include the criticality flag and MUST set it to TRUE.
+ Servers MUST reject any request containing a Proxy Authorization
+ Control without a criticality flag or with the flag set to FALSE with
+ a protocolError error. These requirements protect clients from
+ submitting a request that is executed with an unintended
+ authorization identity.
+
+ The controlValue SHALL be present and SHALL either contain an authzId
+ [AUTH] representing the authorization identity for the request or be
+ empty if an anonymous association is to be used.
+
+ The mechanism for determining proxy access rights is specific to the
+ server's proxy authorization policy.
+
+ If the requested authorization identity is recognized by the server,
+ and the client is authorized to adopt the requested authorization
+ identity, the request will be executed as if submitted by the proxy
+ authorization identity; otherwise, the result code 123 is returned.
+
+4. Implementation Considerations
+
+ One possible interaction of proxy authorization and normal access
+ control is illustrated here. During evaluation of a search request,
+ an entry that would have been returned for the search (if submitted
+ by the proxy authorization identity directly) may not be returned if
+
+
+
+Weltman Standards Track [Page 2]
+\f
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+ the server finds that the requester does not have the right to assume
+ the requested identity for searching the entry, even if the entry is
+ within the scope of a search request under a base DN that does imply
+ such rights. This means that fewer results, or no results, may be
+ returned than would be if the proxy authorization identity issued the
+ request directly. An example of such a case may be a system with
+ fine-grained access control, where the proxy right requester has
+ proxy rights at the top of a search tree, but not at or below a point
+ or points within the tree.
+
+5. Security Considerations
+
+ The Proxy Authorization Control method is subject to general LDAP
+ security considerations [RFC2251] [AUTH] [LDAPTLS]. The control may
+ be passed over a secure channel as well as over an insecure channel.
+
+ The control allows for an additional authorization identity to be
+ passed. In some deployments, these identities may contain
+ confidential information that requires privacy protection.
+
+ Note that the server is responsible for determining if a proxy
+ authorization request is to be honored. "Anonymous" users SHOULD NOT
+ be allowed to assume the identity of others.
+
+6. IANA Considerations
+
+ The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy
+ Authorization Control. It has been registered as an LDAP Protocol
+ Mechanism [RFC3383].
+
+ A result code (123) has been assigned by the IANA for the case where
+ the server does not execute a request using the proxy authorization
+ identity.
+
+7. Acknowledgements
+
+ Mark Smith, formerly of Netscape Communications Corp., Mark Wahl,
+ formerly of Sun Microsystems, Inc., Kurt Zeilenga of OpenLDAP
+ Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have
+ contributed with reviews of this document.
+
+
+
+
+
+
+
+
+
+
+
+Weltman Standards Track [Page 3]
+\f
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+8. Normative References
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [AUTH] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [LDAPTLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+Author's Address
+
+ Rob Weltman
+ Yahoo!, Inc.
+ 701 First Avenue
+ Sunnyvale, CA 94089
+ USA
+
+ Phone: +1 408 349-5504
+ EMail: robw@worldspot.com
+
+
+
+
+
+
+
+
+Weltman Standards Track [Page 4]
+\f
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Weltman Standards Track [Page 5]
+\f
/* LDAP Controls */
/* standard track controls */
#define LDAP_CONTROL_MANAGEDSAIT "2.16.840.1.113730.3.4.2" /* RFC 3296 */
-#define LDAP_CONTROL_PROXY_AUTHZ "2.16.840.1.113730.3.4.18" /* RFC TBD */
+#define LDAP_CONTROL_PROXY_AUTHZ "2.16.840.1.113730.3.4.18" /* RFC 4370 */
#define LDAP_CONTROL_SUBENTRIES "1.3.6.1.4.1.4203.1.10.1" /* RFC 3672 */
#define LDAP_CONTROL_VALUESRETURNFILTER "1.2.826.0.1.334810.2.3"/* RFC 3876 */
projects / openldap / commitdiff