RFC 6171

The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control

📅 published March 2011, from ietf

The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control 💖

  • RFC: 6171 🎀
  • Author: K. Zeilenga (Kurt D. Zeilenga), Isode Limited ✨
  • Category: Standards Track 🔥
  • Date: March 2011 🌸
  • ISSN: 2070-1721 🦋
  • Obsoletes/Updates: the header doesn't list anything it obsoletes or updates 🫶

Abstract

okay so this doc defines the LDAP Don't Use Copy control extension 💅 It lets a client say "hey, don't use copied info to answer me." It's based on the X.511 dontUseCopy service control option, so it's giving X.500 family vibes 🧚

Status of This Memo

This is an Internet Standards Track document. 🌈

It's a product of the Internet Engineering Task Force (IETF) 🎀 It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑 For more on Internet Standards, check Section 2 of RFC 5741.

Info about the current status, errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6171 💜

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 📜

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 🙈

1. Background and Intended Usage 🎀

okay so this doc defines the Lightweight Directory Access Protocol (LDAP) [RFC4510] Don't Use Copy control extension 💖 A request can carry this control to say that copied (replicated or cached) information [X.500] is not be used in providing service. It's based on the X.511 [X.511] dontUseCopy service control option, so it's the same family 🧚

The Don't Use Copy control is for when the client needs the service to run on original (master) information [X.500] 🫶 If the control isn't there, the server is free to use copied (non-authoritative) information when it serves the request ✨

Here's an example, bestie. A client wants an authoritative answer to "is this particular user a member of this group?" 👑 It could send a compare request [RFC4511] with the Don't Use Copy control, where the entry is the Distinguished Name (DN) of the group, the ava.attributeDesc is 'member', and the ava.assertionValue is the DN of the user 🦋 If the server can reach the original (master) information, either directly or through chaining, it runs the operation against that original info and returns compareTrue or compareFalse (or an error) 💅 If it can't reach the original information, the server is obligated to either return a referral or an error 😭

This control isn't meant to be used generally (like, not on every LDAP interrogation operation). It's only for when it's needed to make sure directory apps behave properly 🙈 In general, directory apps ought to be designed to use copied information well 🌸

2. Terminology 🧚

DSA stands for Directory System Agent (or server). DSE stands for DSA-Specific Entry. 💜

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 RFC 2119 [RFC2119]. 📜

3. The Don't Use Copy Control 🔥

The Don't Use Copy control is an LDAP Control [RFC4511] whose controlType is 1.3.6.1.1.22 and whose controlValue is absent. The criticality MUST be TRUE. There is no corresponding response control. 💅

The control is appropriate for LDAP interrogation operations, including Compare and Search operations [RFC4511]. It's inappropriate for all other operations, including Abandon, Bind, Delete, Modify, ModifyDN, StartTLS, and Unbind operations [RFC4511]. 🙈

When the control is attached to an LDAP request, the requested operation MUST NOT be performed on copied information. That is, the requested operation MUST be performed on original information. 🚨

If original (master) information for the target or base object of the operation isn't available (either locally or through chaining), the server MUST either return a referral directing the client to a server believed to be better able to service the request, or return an appropriate result code (e.g., unwillingToPerform). 😭

Note that a referral, if returned, isn't necessarily to the server holding the original (master) information. Also, an authoritative answer might not be available to the client for any number of reasons 🌸

When the client chases a referral to a server (as referenced by an LDAP URL) in the server response in order to get an authoritative response, the client MUST provide the dontUseCopy control with the interrogation request it makes to the referred to server. LDAP allows return of other kinds of URIs too, but the syntax and semantics of those are left to future specifications, and so are the particulars of how to act upon them 🦋

Servers implementing this technical specification SHOULD publish the object identifier 1.3.6.1.1.22 as a value of the 'supportedControl' attribute [RFC4512] in their root DSE. A server MAY choose to advertise this extension only when the client is authorized to use it. 🫶

4. Security Considerations 🚨

This control is meant to be provided where providing service using copied information might lead to unexpected application behavior 🧚

Use of the Don't Use Copy control may let an attacker perform or amplify a denial-of-service attack by making the server use extra resources, for example when the server chooses to chain the request instead of returning a referral. Servers that are capable of that chaining can mitigate this threat by limiting chaining to a particular group of authenticated entities 💀

LDAP is frequently used to store and distribute security-sensitive information, including access control and security policy information. Failing to use the Don't Use Copy control may thus let an attacker gain unauthorized access by allowing reliance on stale data. This one is seriously important, bestie 😭🔥

5. IANA Considerations 🌈

5.1. Object Identifier

IANA has assigned an LDAP Object Identifier [RFC4520] to identify the LDAP Don't Use Copy Control defined in this document. 👑

   Subject: Request for LDAP Object Identifier Registration
   Person & email address to contact for further information:
       Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
   Specification: RFC 6171
   Author/Change Controller: IESG
   Comments:
       Identifies the LDAP Don't Use Copy Control

5.2. LDAP Protocol Mechanism

IANA has registered this protocol mechanism [RFC4520] as follows. 🍓

   Subject: Request for LDAP Protocol Mechanism Registration
   Object Identifier: 1.3.6.1.1.22
   Description: Don't Use Copy Control
   Person & email address to contact for further information:
       Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
   Usage: Control
   Specification: RFC 6171
   Author/Change Controller: IESG
   Comments: none

6. Acknowledgements 🫶

The author thanks Ben Campbell, Phillip Hallam-Baker, and Ted Hardie for providing review and specific suggestions. Iconic reviewers 👑

7. References 📚

7.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [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.
  • [RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.

7.2. Informative References

  • [X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
  • [X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
  • [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

Author's Address 💌

Kurt D. Zeilenga Isode Limited

EMail: Kurt.Zeilenga@Isode.COM

📦 where this page comes from