RFC 2820

Access Control Requirements for LDAP

📅 published May 2000, from ietf

RFC 2820: Access Control Requirements for LDAP 🎀

Okay bestie, let's get into this one. RFC 2820 is an Informational doc from May 2000 (💅 not a standard, just vibes and requirements). Four people wrote it: E. Stokes and D. Byrne from IBM, B. Blakley from Dascom, and P. Behera from Netscape. The title block doesn't list any "Obsoletes" or "Updates" lines, so it isn't replacing or changing any other RFC. 🫶

Status of this Memo ✨

This memo gives info to the Internet community. It is not an Internet standard of any kind, and you can share it freely with no limits. 🦋

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🌸

So this doc is about the basics of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP), which is a directory service. It's meant to be a one-stop collection of the access control requirements you'd need for authorized access and for making different directories work together. 🧚

The keywords "MUST", "SHOULD", and "MAY" in this document are to be read as described in [bradner97]. 🔑

1. Introduction 💖

Okay so, being able to securely access (replicate and distribute) directory info across the whole network is literally necessary for LDAP to work at all. 😭 LDAP is catching on as the way to access directory info, so there's a big push for an access control model for directory content, both between servers inside one organization and across the Internet. The tea is that LDAP doesn't define an access control model yet, and it needs one so that LDAP implementations from different vendors can all keep access consistently secure. These requirements are critical for LDAP to actually succeed and get adopted out in the market. 👑

The RFC 2119 terminology is used in this document. 🎀

2. Objectives 🧚

The main goal is a model that's simple, secure, and super efficient, while still being flexible enough for both Internet and enterprise setups and their different policies. 💅

That leads to several general requirements, which we'll cover below. ✨

3. Requirements 📋

Here's the lineup: general, semantics/policy, usability, and nested groups (which is still an unresolved issue, so that's a whole saga 🙈). The requirements aren't in any priority order. Examples and explanations show up wherever they're needed. Usability is honestly the one that gets overlooked the most, but it has to be handled if you want a secure system. Usability is a security issue, not just a nice design goal. If nobody can set and manage a policy for a secure situation in a way a human can understand, then whatever got set up will probably end up non-secure. 😬 Everyone needs to treat usability as a functional security requirement, periodt. 💅

3.1. General 🌈

G1. Model SHOULD be general enough to support extensibility, so it can add cool features later. ✨

G2. When in doubt, safer is better, especially when setting defaults. 🛡️

G3. ACL administration SHOULD be part of the LDAP protocol. Access control information MUST be an LDAP attribute. 🍓

G4. Object reuse protection SHOULD be provided and MUST NOT inhibit implementation of object reuse. The directory SHOULD support policy controlling the re-creation of deleted DNs, especially when they're being re-created so they can be assigned to a subject other than the owner of the deleted DN. 🙈

3.2. Semantics / Policy 💜

S1. Omitted as redundant; see U8. 🫠

S2. More specific policies MUST override less specific ones (for example, an individual user entry in the ACL SHOULD take precedence over a group entry) when an ACL is evaluated. 👑

S3. Multiple policies of equal specificity SHOULD be combined in some easy-to-understand way (for example, union or intersection). This is easiest to get with an example. Say user A belongs to 3 groups, and all 3 groups are on the ACL. Also say the permissions for those groups aren't all the same. Each group has equal specificity (since each one is listed on the ACL), and the policy for letting user A in (in this example) SHOULD be combined in an easy-to-understand way, like intersection or union. For instance, an intersection policy here might give user A more limited access than a union policy would. 🦋

S4. Newly created directory entries SHOULD be subject to a secure default policy. 🔒

S5. Access policy SHOULD NOT be expressed in terms of attributes which the directory administrator or their organization can't administer (for example, groups whose membership is run by some other organization). 🙅‍♀️

S6. Access policy SHOULD NOT be expressed in terms of attributes which are easily forged (for example, IP addresses). There may be valid reasons for enabling access based on attributes that are easily forged, and the behavior and implications of doing that should be documented. 🕵️‍♀️

S7. Humans (including administrators) SHOULD NOT be required to manage access policy based on attributes that aren't "human-readable" (for example, IP addresses). 🧠

S8. It MUST be possible to deny a subject the right to invoke a directory operation. The system SHOULD NOT require a specific implementation of denial (for example, explicit denial or implicit denial). 🚫

S9. The system MUST be able (semantically) to support either default-grant or default-deny semantics, but not both at the same time. 🎭

S10. The system MUST be able to support either union semantics or intersection semantics for aggregate subjects, but not both at the same time. 🧩

S11. Absence of policy SHOULD be interpretable as grant or deny. Deny takes precedence over grant among entries of equal specificity. ⚖️

S12. ACL policy resolution MUST NOT depend on the order of entries in the ACL. 🔀

S13. Rights management MUST have no side effects. Granting a subject one right to an object MUST NOT implicitly grant the same or any other subject a different right to the same object. Granting a privilege attribute to one subject MUST NOT implicitly grant that same privilege attribute to any other subject. Granting a privilege attribute to one subject MUST NOT implicitly grant a different privilege attribute to the same or any other subject. 🧨

Definition time! An ACL's "scope" is the set of directory objects governed by the policy it defines, and this set of objects is a sub-tree of the directory. Changing the policy asserted by an ACL (by changing one or more of its entries) MUST NOT implicitly change the policy governed by an ACL in a different scope. 🌳

S14. It SHOULD be possible to apply a single policy to multiple directory entries, even if those entries sit in different subtrees. Applying a single policy to multiple directory entries SHOULD NOT require creating and storing multiple copies of the policy data. The system SHOULD NOT require a specific implementation (for example, nested groups or named ACLs) of support for policy sharing. 🤝

3.3. Usability (Manageability) 🎀

U1. When in doubt, simpler is better, both at the interface and in the implementation. 💖

U2. Subjects MUST be drawn from the "natural" LDAP namespace; they should be DNs (distinguished names). 🏷️

U3. It SHOULD NOT be possible via ACL administration to lock out all users, including all administrators, from the directory. 🔐

U4. Administrators SHOULD NOT be required to evaluate arbitrary Boolean predicates in order to create or understand policy. 🧮

U5. Administrators SHOULD be able to administer access to directories and their attributes based on their sensitivity, without having to understand the semantics of individual schema elements and their attributes (see U9). 🌷

U6. Managing access to resources in an entire subtree SHOULD require only one ACL (at the subtree root). Note that this makes access control based explicitly on attribute types very hard, unless you constrain the types of entries in subtrees. For example, say another attribute gets added to an entry. That attribute might fall outside the grouping covered by the ACL, which means it needs extra administration if the goal is a different ACL. Access control information specified in one administrative area MUST NOT have jurisdiction in another area. You SHOULD NOT be able to control access to the aliased entry through the alias. You SHOULD be able to control access to the alias name. 🪞

U7. Override of subtree policy MUST be supported on a per-directory-entry basis. 🎯

U8. Control of access to individual directory entry attributes (not just the whole directory entry) MUST be supported. 🔍

U9. Administrators MUST be able to coarsen access policy granularity by grouping attributes with similar access sensitivities. 🧺

U10. Control of access on a per-user granularity MUST be supported. 👤

U11. Administrators MUST be able to aggregate users (for example, by assigning them to groups or roles) to simplify administration. 👯‍♀️

U12. It MUST be possible to review the "effective access" of any user, group, or role to any entry's attributes. This helps the administrator set the right policy. 👀

U13. A single administrator SHOULD be able to define policy for the entire directory tree. An administrator MUST be able to delegate policy administration for specific subtrees to other users. This lets you partition the whole directory tree for policy administration, but still lets a single policy be defined for the entire tree regardless of partitioning. (Partition here means scope of administration.) An administrator MUST be able to create new partitions at any point in the directory tree, and MUST be able to merge a superior and a subordinate partition. An administrator MUST be able to configure whether delegated access control information from superior partitions is accepted or not. 🗂️

U14. It MUST be possible to authorize users to traverse the directory structure even if they aren't authorized to examine or modify some of the entries they pass through; it MUST also be possible to prohibit this. The tree structure MUST be able to be protected from view if the administrator wants that. 🌲

U15. It MUST be possible to create publicly readable entries, which may be read even by unauthenticated clients. 🌍

U16. The model for combining multiple access control list entries that refer to a single individual MUST be easy to understand. 🧠✨

U17. Administrators MUST be able to determine where inherited policy information comes from, that is, where ACLs are located and which ACLs were applied. Where inheritance of ACLs is applied, it must be able to be shown how and where that new ACL is derived from. 🗺️

U18. It SHOULD be possible for the administrator to configure the access control system to let users grant additional access control rights for entries they create. 🎁

4. Security Considerations 🔥

Access control is a security consideration, and this doc addresses the requirements. Security is not a vibe you can skip. 🔥

5. Glossary ✨

okay bestie, this part is basically a little dictionary for access control 📖💅 it's for newbies who haven't gone deep on it yet, and it lists the terms people use when they talk about it [emca]. let's gooo 🦋

  • Access control - stopping a resource from being used by entities that are unidentified and/or unauthorized, in any other that an authorized manner. 🙈
  • Access control list - a set of control attributes. it's a list tied to one security object or a group of them, and it holds the names of security subjects plus the kind of access they might be given. 📝
  • Access control policy - a set of rules (part of a security policy) that authenticates human users, or their representatives, and decides whether those users get access to applications, other services, and security objects. 🔐
  • Access context - the context in which access to a security object happens. think location, time of day, how secure the underlying associations are, etc. 🌍
  • Authorization - giving access to a security object. ✅
  • Authorization policy - a set of rules (part of an access control policy) that decides whether security subjects can reach security objects. it can be defined using access control lists, capabilities, or attributes given to security subjects, security objects, or both. 👑
  • Control attributes - attributes on a security object that get matched against a security subject's privilege attributes to grant or deny access. an access control list, a list of rights, or a time of day range are all examples. ⏰
  • Credentials - data that establishes a security subject's claimed identity inside a given security domain. 🪪
  • Privilege attributes - attributes on a security subject that get matched against a security object's control attributes to grant or deny access. group and role memberships are examples. 🎀
  • Security attributes - the general term covering both privilege attributes and control attributes. how they're used is defined by a security policy. 🧚
  • Security object - an entity in a passive role that a security policy applies to. 🌸
  • Security policy - the general term covering both access control policies and authorization policies. 💜
  • Security subject - an entity in an active role that a security policy applies to. 🦋

6. References ✨

okay these are the receipts 🧾 everything the doc leans on is listed here:

[ldap]      Kille, S., Howes, T. and M. Wahl, "Lightweight Directory
            Access Protocol (v3)", RFC 2251, August 1997.

[ecma]      ECMA, "Security in Open Systems: A Security Framework"
            ECMA TR/46, July 1988.

[bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

7. Authors' Addresses ✨

the squad behind this doc 🫶 with their contact info, exactly as they were listed:

Bob Blakley
Dascom
5515 Balcones Drive
Austin, TX 78731
USA

Phone: +1 512 458 4037  ext 5012
Fax:   +1 512 458 2377
EMail: blakley@dascom.com


Ellen Stokes
IBM
11400 Burnet Rd
Austin, TX 78758
USA

Phone: +1 512 838 3725
Fax:   +1 512 838 0156
EMail: stokes@austin.ibm.com


Debbie Byrne
IBM
11400 Burnet Rd
Austin, TX 78758
USA

Phone: +1 512 838 1930
Fax:   +1 512 838 8597
EMail: djbyrne@us.ibm.com


Prasanta Behera
Netscape
501 Ellis Street
Mountain View, CA 94043
USA

Phone: +1 650 937 4948
Fax:   +1 650 528-4164
EMail: prasanta@netscape.com

this part is the legal stuff 📜 kinda boring but it matters, so here it is in full:

Copyright (C) The Internet Society (2000). All Rights Reserved.

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.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from