From 7f0a047c370896b98f60e097020679b429366cfa Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Sat, 11 Feb 2006 04:08:23 +0000 Subject: [PATCH] Add RFC 4370 --- doc/drafts/draft-weltman-ldapv3-proxy-xx.txt | 295 ------------------- doc/rfc/INDEX | 1 + doc/rfc/rfc4370.txt | 283 ++++++++++++++++++ include/ldap.h | 2 +- 4 files changed, 285 insertions(+), 296 deletions(-) delete mode 100644 doc/drafts/draft-weltman-ldapv3-proxy-xx.txt create mode 100644 doc/rfc/rfc4370.txt diff --git a/doc/drafts/draft-weltman-ldapv3-proxy-xx.txt b/doc/drafts/draft-weltman-ldapv3-proxy-xx.txt deleted file mode 100644 index fe6b871f4f..0000000000 --- a/doc/drafts/draft-weltman-ldapv3-proxy-xx.txt +++ /dev/null @@ -1,295 +0,0 @@ - - -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] - -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] - -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] - -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] - -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] - \ No newline at end of file diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX index e05168ee84..4929ee1903 100644 --- a/doc/rfc/INDEX +++ b/doc/rfc/INDEX @@ -49,6 +49,7 @@ rfc3876.txt Returning Matched Values with LDAP (PS) 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: diff --git a/doc/rfc/rfc4370.txt b/doc/rfc/rfc4370.txt new file mode 100644 index 0000000000..8a8aa14f53 --- /dev/null +++ b/doc/rfc/rfc4370.txt @@ -0,0 +1,283 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + diff --git a/include/ldap.h b/include/ldap.h index 1ca22a7f4d..5c7e0b121a 100644 --- a/include/ldap.h +++ b/include/ldap.h @@ -205,7 +205,7 @@ typedef struct ldapcontrol { /* 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 */ -- 2.39.5