RFC 4532

Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation

📅 published June 2006, from ietf

RFC 4532: Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation 🦋

okay bestie, let's get into RFC 4532 💅 It's from the Network Working Group, written by K. Zeilenga of the OpenLDAP Foundation. It's a Standards Track doc dated June 2006. The title block doesn't list anything it obsoletes or updates, so there's no drama there ✨

Status of This Memo ✨

This is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🎀 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 💜 Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2006). 💖

Abstract 🧚

This spec gives LDAP clients a way to get the authorization identity the server has linked to the user or application entity 🫶 The mechanism is an LDAP extended operation called the LDAP "Who am I?" operation ✨

1. Background and Intent of Use 🌸

Okay so this is the LDAP [RFC4510] operation clients use to get the primary authorization identity, in its primary form, that the server associated with the user or application entity 💅 It's called the "Who am I?" operation 🦋

This spec is meant to replace the 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 the security layers that the Bind operation itself sets up 🙈 You can set up security layers with StartTLS [RFC4511][RFC4513] before the Bind, but it's often desirable to use the security layers established by the Bind operation instead 🔥 An extended operation sent after a Bind operation is protected by those Bind-established security layers 🛡️

There are other times you'd want the authorization identity the server associated with the client, separate from the Bind operation 👑 For example, the "Who am I?" operation can be augmented with a Proxied Authorization Control [RFC4370] to find the authorization identity the server associates with the identity asserted in that 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 the server considers primary 💅 In this spec, "the authorization identity" and "the authzId" are generally read as "the primary authorization identity" and "the primary authzId", respectively.

1.1. Conventions Used in This Document 📖

Here's the key word situation, bestie 🔑 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] 💀 Those are the big-deal words, so read them carefully 🫶

2. The "Who am I?" Operation 🎀

The "Who am I?" operation is an LDAP Extended Operation [RFC4511] identified by the whoamiOID Object Identifier (OID) 🧚 This section breaks down 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

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 gives us a mechanism, a whoami Request, for the client to ask the server to return the authorization identity it currently associates with the client 💖 It also has a mechanism, a whoami Response, for the server to answer that request 🫶

Servers show they support 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 Bind operation 🚫 If 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 those 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 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 💀

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 its 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.
  • [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.

8.2. Informative References 🌙

Intellectual Property ✨

okay so the IETF is like, "we're not picking a side on whether any IP rights apply to this tech 🙅‍♀️, and we're not saying we checked for any either 🤷‍♀️." 💅 whether there's a license out there is a whole separate drama. the rules for rights in RFC docs live in BCP 78 and BCP 79, so go read those if you're curious 📚

copies of IPR disclosures sent to the IETF Secretariat, plus any license promises, or the results of trying to get a general license or permission for implementers or users to use these proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🦋

and the IETF is literally begging for tips 🥺 if you know of any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to build this standard, tell them at ietf-ipr@ietf.org. bestie, speak up!! 📣💖

Acknowledgement 🫶

so the RFC Editor function? it's funded by the IETF Administrative Support Activity (IASA). the people keeping these docs running get backed by IASA, which is honestly so iconic of them 👑🌸

📦 where this page comes from