+++ /dev/null
-
- Internet-Draft E. Stokes
- LDAP Extensions WG D. Byrne
- Intended Category: Informational IBM
- Expires: 25 December 1999 B. Blakley
- Dascom
- P. Behera
- Netscape
- 25 June 1999
-
- Access Control Requirements for LDAP
- <draft-ietf-ldapext-acl-reqts-02.txt>
-
- STATUS OF THIS MEMO
-
- This document is an Internet-Draft and is in full
- conformance with all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet
- Engineering Task Force (IETF), its areas, and its working
- groups. Note that other groups may also distribute
- working documents as Internet-Drafts. Internet-Drafts are
- draft documents valid for a maximum of six months and may
- be updated, replaced, or obsoleted by other documents at
- any time. It is inappropriate to use Internet- Drafts as
- reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be
- accessed at http://www.ietf.org/shadow.html.
-
- Comments and suggestions on this document are encouraged.
- Comments on this document should be sent to the LDAPEXT
- working group discussion list:
-
- ietf-ldapext@netscape.com
-
- COPYRIGHT NOTICE
- Copyright (C) The Internet Society (1997). All Rights
- Reserved.
-
-
-
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 1]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- 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 RFC 2119
- terminology is used in this document.
-
-
-
- 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.
-
-
- 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
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 2]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- 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.
-
- 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
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 3]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- 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.
-
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 4]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- 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 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
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 5]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- 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.
-
- 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
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 6]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- 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.
-
- 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.
-
-
-
-
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 7]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- 5. Glossary
-
- This glossary is intended to aid the novice not versed in
- depth about access control. It contains a list [2] of
- terms and their definitions that are commonly used in
- discussing access control.
-
- 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.
-
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 8]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- Credentials - Data that serve to establish the claimed
- identity of a security subject relative to a given
- security domain.
-
- 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
-
- [1] Steve Kille, Tim Howes, M. Wahl, "Lightweight
- Directory Access Protocol (v3)", RFC 2251, August 1997.
-
- [2] ECMA, "Security in Open Systems: A Security
- Framework" ECMA TR/46, July 1988
-
-
- AUTHOR(S) ADDRESS
-
- Bob Blakley Ellen Stokes
- Dascom IBM
- 5515 Balcones Drive 11400 Burnet Rd
- Austin, TX 78731 Austin, TX 78758
- USA USA
- mail-to: blakley@dascom.com mail-to: stokes@austin.ibm.com
- phone: +1 512 458 4037 ext 5012 phone: +1 512 838 3725
- fax: +1 512 458 2377 fax: +1 512 838 0156
-
-
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 9]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- Debbie Byrne Prasanta Behera
- IBM Netscape
- 11400 Burnet Rd 501 Ellis Street
- Austin, TX 78758 Mountain View, CA 94043
- USA USA
- mail-to: djbyrne@us.ibm.com mail-to: prasanta@netscape.com
- phone: +1 512 838 1930 phone: +1 650 937 4948
- fax: +1 512 838 8597 fax: +1 650 528-4164
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 10]
-\f
-
-
-
-
- Internet-Draft ACI Requirements 25 June 1999
-
-
-
- 7. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999).á 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Stokes, etal Expires 25 December 1999 [Page 11]
-\f
-
projects / openldap / commitdiff