From: Kurt Zeilenga Date: Thu, 20 Dec 2001 18:21:55 +0000 (+0000) Subject: Req't documents should be born historic... X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~588 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=c84b2b5cfd646e7011ad3fffc96eef78d26b4567;p=openldap Req't documents should be born historic... --- diff --git a/doc/rfc/rfc2820.txt b/doc/rfc/rfc2820.txt deleted file mode 100644 index 0a519f7bda..0000000000 --- a/doc/rfc/rfc2820.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] -