+++ /dev/null
-
-
-
-
-
-
-Network Working Group E. Stokes
-Request for Comments: 2820 D. Byrne
-Category: Informational IBM
- B. Blakley
- Dascom
- P. Behera
- Netscape
- May 2000
-
-
- Access Control Requirements for LDAP
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
- This document describes the fundamental requirements of an access
- control list (ACL) model for the Lightweight Directory Application
- Protocol (LDAP) directory service. It is intended to be a gathering
- place for access control requirements needed to provide authorized
- access to and interoperability between directories.
-
- The keywords "MUST", "SHOULD", and "MAY" used in this document are to
- be interpreted as described in [bradner97].
-
-1. Introduction
-
- The ability to securely access (replicate and distribute) directory
- information throughout the network is necessary for successful
- deployment. LDAP's acceptance as an access protocol for directory
- information is driving the need to provide an access control model
- definition for LDAP directory content among servers within an
- enterprise and the Internet. Currently LDAP does not define an
- access control model, but is needed to ensure consistent secure
- access across heterogeneous LDAP implementations. The requirements
- for access control are critical to the successful deployment and
- acceptance of LDAP in the market place.
-
- The RFC 2119 terminology is used in this document.
-
-
-
-
-Stokes, et al. Informational [Page 1]
-\f
-RFC 2820 Access Control Requirements for LDAP May 2000
-
-
-2. Objectives
-
- The major objective is to provide a simple, but secure, highly
- efficient access control model for LDAP while also providing the
- appropriate flexibility to meet the needs of both the Internet and
- enterprise environments and policies.
-
- This generally leads to several general requirements that are
- discussed below.
-
-3. Requirements
-
- This section is divided into several areas of requirements: general,
- semantics/policy, usability, and nested groups (an unresolved issue).
- The requirements are not in any priority order. Examples and
- explanatory text is provided where deemed necessary. Usability is
- perhaps the one set of requirements that is generally overlooked, but
- must be addressed to provide a secure system. Usability is a security
- issue, not just a nice design goal and requirement. If it is
- impossible to set and manage a policy for a secure situation that a
- human can understand, then what was set up will probably be non-
- secure. We all need to think of usability as a functional security
- requirement.
-
-3.1 General
-
- G1. Model SHOULD be general enough to support extensibility to add
- desirable features in the future.
-
- G2. When in doubt, safer is better, especially when establishing
- 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, particularly in cases
- where they are re-created for the purpose of assigning them 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 (e.g.
- individual user entry in ACL SHOULD take precedence over group entry)
- for the evaluation of an ACL.
-
-
-
-Stokes, et al. Informational [Page 2]
-\f
-RFC 2820 Access Control Requirements for LDAP May 2000
-
-
- S3. Multiple policies of equal specificity SHOULD be combined in
- some easily-understood way (e.g. union or intersection). This is
- best understood by example. Suppose user A belongs to 3 groups and
- those 3 groups are listed on the ACL. Also suppose that the
- permissions for each of those groups are not identical. Each group is
- of equal specificity (e.g. each group is listed on the ACL) and the
- policy for granting user A access (given the example) SHOULD be
- combined in some easily understood way, such as by intersection or
- union. For example, an intersection policy here may yield a more
- limited access for user A than a union policy.
-
- 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 his organization cannot
- administer (e.g. groups whose membership is administered by another
- organization).
-
- S6. Access policy SHOULD NOT be expressed in terms of attributes
- which are easily forged (e.g. IP addresses). There may be valid
- reasons for enabling access based on attributes that are easily
- forged and the behavior/implications of doing that should be
- documented.
-
- S7. Humans (including administrators) SHOULD NOT be required to
- manage access policy on the basis of attributes which are not
- "human-readable" (e.g. 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 (e.g. explicit denial, implicit denial).
-
- S9. The system MUST be able (semantically) to support either
- default-grant or default-deny semantics (not simultaneously).
-
- S10. The system MUST be able to support either union semantics or
- intersection semantics for aggregate subjects (not simultaneously).
-
- 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
-
-
-
-Stokes, et al. Informational [Page 3]
-\f
-RFC 2820 Access Control Requirements for LDAP May 2000
-
-
- privilege attribute to one subject MUST NOT implicitly grant the 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: An
- ACL's "scope" is defined as the set of directory objects governed by
- the policy it defines; 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 are in different subtrees.
- Applying a single policy to multiple directory entries SHOULD NOT
- require creation and storage of multiple copies of the policy data.
- The system SHOULD NOT require a specific implementation (e.g. nested
- groups, 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.
-
- U3. It SHOULD NOT be possible via ACL administration to lock all
- users, including all administrators, out of 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. Management of 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, another
- attribute is added to an entry. That attribute may fall outside the
- grouping covered by the ACL and hence require additional
- administration where the desired affect is indeed 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 in the alias. You SHOULD be able
- to control access to the alias name.
-
-
-
-
-Stokes, et al. Informational [Page 4]
-\f
-RFC 2820 Access Control Requirements for LDAP May 2000
-
-
- 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. Administrator 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. Administrator 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 "effective access" of any user,
- group, or role to any entry's attributes. This aids the administrator
- in setting the correct 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
- allows for the partitioning of the entire directory tree for policy
- administration, but still allows a single policy to be defined for
- the entire tree independent of partitioning. (Partition in this
- context 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 subordinate partition. An
- administrator MUST be able to configure whether delegated access
- control information from superior partitions is to be accepted or
- not.
-
- U14. It MUST be possible to authorize users to traverse directory
- structure even if they are not authorized to examine or modify some
- traversed entries; it MUST also be possible to prohibit this. The
- tree structure MUST be able to be protected from view if so desired
- by the administrator.
-
- 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
- referring to a single individual MUST be easy to understand.
-
- U17. Administrator 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/where that new ACL is derived from.
-
-
-
-
-Stokes, et al. Informational [Page 5]
-\f
-RFC 2820 Access Control Requirements for LDAP May 2000
-
-
- U18. It SHOULD be possible for the administrator to configure the
- access control system to permit users to grant additional access
- control rights for entries which they create.
-
-4. Security Considerations
-
- Access control is a security consideration. This documents addresses
- the requirements.
-
-5. Glossary
-
- This glossary is intended to aid the novice not versed in depth about
- access control. It contains a list of terms and their definitions
- that are commonly used in discussing access control [emca].
-
- Access control - The prevention of use of a resource by unidentified
- and/or unauthorized entities in any other that an authorized manner.
-
- Access control list - A set of control attributes. It is a list,
- associated with a security object or a group of security objects.
- The list contains the names of security subjects and the type of
- access that may be granted.
-
- Access control policy - A set of rules, part of a security policy, by
- which human users, or their representatives, are authenticated and by
- which access by these users to applications and other services and
- security objects is granted or denied.
-
- Access context - The context, in terms of such variables as location,
- time of day, level of security of the underlying associations, etc.,
- in which an access to a security object is made.
-
- Authorization - The granting of access to a security object.
-
- Authorization policy - A set of rules, part of an access control
- policy, by which access by security subjects to security objects is
- granted or denied. An authorization policy may be defined in terms
- of access control lists, capabilities, or attributes assigned to
- security subjects, security objects, or both.
-
- Control attributes - Attributes, associated with a security object
- that, when matched against the privilege attributes of a security
- subject, are used to grant or deny access to the security object. An
- access control list or list of rights or time of day range are
- examples of control attributes.
-
- Credentials - Data that serve to establish the claimed identity of a
- security subject relative to a given security domain.
-
-
-
-Stokes, et al. Informational [Page 6]
-\f
-RFC 2820 Access Control Requirements for LDAP May 2000
-
-
- Privilege attributes - Attributes, associated with a security subject
- that, when matched against control attributes of a security object,
- are used to grant or deny access to that subject. Group and role
- memberships are examples of privilege attributes.
-
- Security attributes - A general term covering both privilege
- attributes and control attributes. The use of security attributes is
- defined by a security policy.
-
- Security object - An entity in a passive role to which a security
- policy applies.
-
- Security policy - A general term covering both access control
- policies and authorization policies.
-
- Security subject - An entity in an active role to which a security
- policy applies.
-
-6. References
-
- [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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stokes, et al. Informational [Page 7]
-\f
-RFC 2820 Access Control Requirements for LDAP May 2000
-
-
-7. Authors' Addresses
-
- 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
-
-
-
-
-
-
-
-Stokes, et al. Informational [Page 8]
-\f
-RFC 2820 Access Control Requirements for LDAP May 2000
-
-
-8. Full Copyright Statement
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stokes, et al. Informational [Page 9]
-\f
projects / openldap / commitdiff