summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4532.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4532.txt')
-rw-r--r--doc/rfc/rfc4532.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4532.txt b/doc/rfc/rfc4532.txt
new file mode 100644
index 0000000..277b3b7
--- /dev/null
+++ b/doc/rfc/rfc4532.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4532 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ "Who am I?" Operation
+
+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 specification provides a mechanism for Lightweight Directory
+ Access Protocol (LDAP) clients to obtain the authorization identity
+ the server has associated with the user or application entity. This
+ mechanism is specified as an LDAP extended operation called the LDAP
+ "Who am I?" operation.
+
+1. Background and Intent of Use
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) [RFC4510] operation that clients can use to obtain the primary
+ authorization identity, in its primary form, that the server has
+ associated with the user or application entity. The operation is
+ called the "Who am I?" operation.
+
+ This specification is intended to replace the existing Authorization
+ Identity Controls [RFC3829] mechanism, which uses Bind request and
+ response controls to request and return the authorization identity.
+ Bind controls are not protected by security layers established by the
+ Bind operation that includes them. While it is possible to establish
+ security layers using StartTLS [RFC4511][RFC4513] prior to the Bind
+ operation, it is often desirable to use security layers established
+ by the Bind operation. An extended operation sent after a Bind
+ operation is protected by the security layers established by the Bind
+ operation.
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+ There are other cases where it is desirable to request the
+ authorization identity that the server associated with the client
+ separately from the Bind operation. For example, the "Who am I?"
+ operation can be augmented with a Proxied Authorization Control
+ [RFC4370] to determine the authorization identity that the server
+ associates with the identity asserted in the Proxied Authorization
+ Control. The "Who am I?" operation can also be used prior to the
+ Bind operation.
+
+ Servers often associate multiple authorization identities with the
+ client, and each authorization identity may be represented by
+ multiple authzId [RFC4513] strings. This operation requests and
+ returns the authzId that the server considers primary. In the
+ specification, the term "the authorization identity" and "the
+ authzId" are generally to be read as "the primary authorization
+ identity" and the "the primary authzId", respectively.
+
+1.1. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. The "Who am I?" Operation
+
+ The "Who am I?" operation is defined as an LDAP Extended Operation
+ [RFC4511] identified by the whoamiOID Object Identifier (OID). This
+ section details the syntax of the operation's whoami request and
+ response messages.
+
+ whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
+
+2.1. The whoami Request
+
+ The whoami request is an ExtendedRequest with a requestName field
+ containing the whoamiOID OID and an absent requestValue field. For
+ example, a whoami request could be encoded as the sequence of octets
+ (in hex):
+
+ 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
+ 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+2.2. The whoami Response
+
+ The whoami response is an ExtendedResponse where the responseName
+ field is absent and the response field, if present, is empty or an
+ authzId [RFC4513]. For example, a whoami response returning the
+ authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
+ would be encoded as the sequence of octets (in hex):
+
+ 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
+ 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
+ 4e 45 54
+
+3. Operational Semantics
+
+ The "Who am I?" operation provides a mechanism, a whoami Request, for
+ the client to request that the server return the authorization
+ identity it currently associates with the client. It also provides a
+ mechanism, a whoami Response, for the server to respond to that
+ request.
+
+ Servers indicate their support for this extended operation by
+ providing a whoamiOID object identifier as a value of the
+ 'supportedExtension' attribute type in their root DSE. The server
+ SHOULD advertise this extension only when the client is willing and
+ able to perform this operation.
+
+ If the server is willing and able to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with a success resultCode. If the server is treating
+ the client as an anonymous entity, the response field is present but
+ empty. Otherwise, the server provides the authzId [RFC4513]
+ representing the authorization identity it currently associates with
+ the client in the response field.
+
+ If the server is unwilling or unable to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with an appropriate non-success resultCode (such as
+ operationsError, protocolError, confidentialityRequired,
+ insufficientAccessRights, busy, unavailable, unwillingToPerform, or
+ other) and an absent response field.
+
+ As described in [RFC4511] and [RFC4513], an LDAP session has an
+ "anonymous" association until the client has been successfully
+ authenticated using the Bind operation. Clients MUST NOT invoke the
+ "Who am I?" operation while any Bind operation is in progress,
+ including between two Bind requests made as part of a multi-stage
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+ Bind operation. Where a whoami Request is received in violation of
+ this absolute prohibition, the server should return a whoami Response
+ with an operationsError resultCode.
+
+4. Extending the "Who am I?" Operation with Controls
+
+ Future specifications may extend the "Who am I?" operation using the
+ control mechanism [RFC4511]. When extended by controls, the "Who am
+ I?" operation requests and returns the authorization identity the
+ server associates with the client in a particular context indicated
+ by the controls.
+
+4.1. Proxied Authorization Control
+
+ The Proxied Authorization Control [RFC4370] is used by clients to
+ request that the operation it is attached to operate under the
+ authorization of an assumed identity. The client provides the
+ identity to assume in the Proxied Authorization request control. If
+ the client is authorized to assume the requested identity, the server
+ executes the operation as if the requested identity had issued the
+ operation.
+
+ As servers often map the asserted authzId to another identity
+ [RFC4513], it is desirable to request that the server provide the
+ authzId it associates with the assumed identity.
+
+ When a Proxied Authorization Control is be attached to the "Who am
+ I?" operation, the operation requests the return of the authzId the
+ server associates with the identity asserted in the Proxied
+ Authorization Control. The authorizationDenied (123) result code is
+ used to indicate that the server does not allow the client to assume
+ the asserted identity.
+
+5. Security Considerations
+
+ Identities associated with users may be sensitive information. When
+ they are, security layers [RFC4511][RFC4513] should be established to
+ protect this information. This mechanism is specifically designed to
+ allow security layers established by a Bind operation to protect the
+ integrity and/or confidentiality of the authorization identity.
+
+ Servers may place access control or other restrictions upon the use
+ of this operation. As stated in Section 3, the server SHOULD
+ advertise this extension when it is willing and able to perform the
+ operation.
+
+ As with any other extended operations, general LDAP security
+ considerations [RFC4510] apply.
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+6. IANA Considerations
+
+ The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am
+ I?" extended operation. This OID was assigned [ASSIGN] by the
+ OpenLDAP Foundation, under its IANA-assigned private enterprise
+ allocation [PRIVATE], for use in this specification.
+
+ Registration of this protocol mechanism [RFC4520] has been completed
+ by the IANA.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.11.3
+ Description: Who am I?
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Extended Operation
+ Specification: RFC 4532
+ Author/Change Controller: IESG
+ Comments: none
+
+7. Acknowledgement
+
+ This document borrows from prior work in this area, including
+ "Authentication Response Control" [RFC3829] by Rob Weltman, Mark
+ Smith, and Mark Wahl.
+
+ The LDAP "Who am I?" operation takes it's name from the UNIX
+ whoami(1) command. The whoami(1) command displays the effective user
+ ID.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP)
+ Proxied Authorization Control", RFC 4370, February 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+8.2. Informative References
+
+ [RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory
+ Access Protocol (LDAP) Authorization Identity Request and
+ Response Controls", RFC 3829, July 2004.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4532 LDAP "Who am I?" Operation June 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).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+