From: Kurt Zeilenga Date: Wed, 18 Aug 1999 20:12:03 +0000 (+0000) Subject: draft-ietf-ldapext-acl-reqts-02.txt X-Git-Tag: TWEB_OL_BASE~172 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=8efde985e23489f50c8c98315ac91726ab475f20;p=openldap draft-ietf-ldapext-acl-reqts-02.txt --- diff --git a/doc/drafts/draft-ietf-ldapext-acl-reqts-xx.txt b/doc/drafts/draft-ietf-ldapext-acl-reqts-xx.txt new file mode 100644 index 0000000000..4c93ea3c03 --- /dev/null +++ b/doc/drafts/draft-ietf-ldapext-acl-reqts-xx.txt @@ -0,0 +1,632 @@ + + 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] + +