From: Kurt Zeilenga Date: Fri, 16 Jun 2000 06:48:35 +0000 (+0000) Subject: Published as RFC 2820 X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~2614 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=2531452c21e80babcb397f59e54b8ef5ee59d707;p=openldap Published as RFC 2820 --- diff --git a/doc/drafts/draft-ietf-ldapext-acl-reqts-xx.txt b/doc/drafts/draft-ietf-ldapext-acl-reqts-xx.txt deleted file mode 100644 index 4c93ea3c03..0000000000 --- a/doc/drafts/draft-ietf-ldapext-acl-reqts-xx.txt +++ /dev/null @@ -1,632 +0,0 @@ - - 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 - - - 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] - - - - - - 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] - - - - - - 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] - - - - - - 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] - - - - - - 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] - - - - - - 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] - - - - - - 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] - - - - - - 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] - - - - - - 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] - - - - - - 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] - - - - - - 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] - -