mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2024-12-15 03:01:09 +08:00
Code Issues Packages Projects Releases Wiki Activity
07826e4d4c
openldap/doc/drafts/draft-ietf-ldapext-acl-reqts-xx.txt
Kurt Zeilenga 8efde985e2 draft-ietf-ldapext-acl-reqts-02.txt
1999-08-18 20:12:03 +00:00

633 lines
22 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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]
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).<2E> 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.<2E> 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]
Reference in New Issue View Git Blame Copy Permalink