RFC 4370

RFC 4370: Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control 🎀

okay bestie, let's get the title block sorted first ✨ This is RFC 4370, a Standards Track document, written by Rob Weltman of Yahoo!, Inc. and published in February 2006 💅 It doesn't obsolete or update any other RFCs, so it's a fresh start 🌸 It's an actual standards track protocol for the Internet community, so the status is official, not just vibes 👑

Fun fact: the authors' names show up in a few different ways across the document (Rob Weltman, R. Weltman, Mark Wahl, Mark Smith), so keep your eyes peeled 🙈

Status of This Memo 🦋

This is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements 💜 If you want the current 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, so share it with everyone 🌈

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 lets a client ask that an operation be processed under a provided authorization identity, instead of under the current authorization identity tied to the connection 🔥

1. Introduction ✨

okay so proxy authorization lets a client say "run this operation as someone else" instead of as whoever is currently logged into the connection 💅 This document defines support for that using the Control mechanism [RFC2251] 🦋 LDAP [LDAPV3] can use the Simple Authentication and Security Layer [SASL] for authentication, and it can supply an authorization identity that's different from the authentication identity, but that identity applies to the whole LDAP session 🫶

The Proxy Authorization Control is the upgrade 😭 It lets you specify an authorization identity per operation, which is super helpful for clients that need to do stuff efficiently for lots of different 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 🎀

Here's how a server says it supports this control 🧚 If the Object Identifier (OID) "2.16.840.1.113730.3.4.18" shows up in the supportedControl attribute [RFC2252] of a server's root DSA-specific Entry (DSE), then it's supported 🌈

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 changes authentication, authorization, or data confidentiality [RFC2829], like Start TLS [LDAPTLS], when it's part of the controls field of the LDAPMessage defined in [RFC2251] 😭

The controlType is "2.16.840.1.113730.3.4.18" 🔥

The criticality MUST be present and MUST be TRUE 🚨 This is the big safety rule 💅 It stops clients from accidentally sending a request that runs as the wrong authorization identity 🫶

Clients MUST include the criticality flag and MUST set it to TRUE 🎀 Servers MUST reject any request that has a Proxy Authorization Control without a criticality flag, or with the flag set to FALSE, using a protocolError error 💀 Same energy as the rule above, because it keeps clients from running requests as an identity they never meant to use 🙈

The controlValue SHALL be present, and it SHALL either contain an authzId [AUTH] for the authorization identity of the request, or be empty if an anonymous association is going to be used ✨

How the server decides who gets proxy rights is up to the server's own proxy authorization policy 🧚

If the server recognizes the requested authorization identity, and the client is allowed to adopt it, the request runs as if the proxy authorization identity sent it directly 🔥 Otherwise, result code 123 comes back 💀

4. Implementation Considerations 🌸

Here's one way proxy authorization can interact with normal access control 👑 When a search runs, an entry that would have come back if the proxy authorization identity asked directly might NOT come back, if the server finds the requester doesn't have the right to assume that identity for searching it 😭 Even if the entry is within the scope of a search under a base DN that does imply those rights 🙈 So you might get fewer results, or none at all, compared to the proxy identity asking directly 💅

Like, picture a system with fine-grained access control: the proxy rights requester has them at the top of a search tree, but not at or below one or more points inside the tree 🌳 Iconic plot twist 🫠

5. Security Considerations 💀

The Proxy Authorization Control is subject to the general LDAP security considerations [RFC2251] [AUTH] [LDAPTLS] 🚨 The control can go over a secure channel or an insecure channel 🔐

The control lets an extra authorization identity get passed along 🧚 In some deployments, those identities might contain confidential info that needs privacy protection 🫶

Note that the server is responsible for deciding whether a proxy authorization request gets honored 👑 "Anonymous" users SHOULD NOT be allowed to assume the identity of others 💀 Absolutely not, bestie 🙅

6. IANA Considerations 🍓

The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy Authorization Control 🦋 It's been registered as an LDAP Protocol Mechanism [RFC3383] 💜

A result code (123) has been assigned by the IANA for when the server does not execute a request using the proxy authorization identity 🌈

7. Acknowledgements 🫶

Shoutout to the reviewers: 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 👑 They all gave reviews of this document, and honestly they deserve the flowers 💐

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

---

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, 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) 🌸