mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-12-27 01:59:38 -05:00
Add RFC 4370
This commit is contained in:
Kurt Zeilenga
parent
cc475f4bbe
commit
7f0a047c37
4 changed files with 285 additions and 296 deletions
|
|
@ -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]
|
||||
|
||||
|
|
@ -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:
|
||||
|
|
|
|||
283
doc/rfc/rfc4370.txt
Normal file
283
doc/rfc/rfc4370.txt
Normal file
|
|
@ -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]
|
||||
|
||||
|
|
@ -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 */
|
||||
|
|
|
|||
Loading…
Reference in a new issue