[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Comments on Access Control Requirements draft
I read through the Access Control Requirements draft
(draft-stokes-ldapext-acl-reqts-00.txt) and have a number of comments.
Since we didn't get to discuss the draft at the LDAPEXT meeting, I'm
posting them to the list.
I've copied sections 3-5 of the draft below, with my comments inserted.
The lines that start in column 1 are my comments.
Rick Huber
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
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.
Stokes, Byrne, Blakley, Behera [Page 3]
Internet-Draft ACL Requirements 16 October 1997
G2. When in doubt, safer is better, especially when
establishing defaults.
G3. ACL administration SHOULD be part of the LDAP
protocol.
And ACL information SHOULD be stored in the LDAP tree and not in some
separate database.
G4. Object reuse protection SHOULD be provided and MUST
NOT inhibit implementation of object reuse. Object reuse
addresses the use of residual data. Space (memory or
disk) may be allocated and then freed, and when that
space is freed, precautions must be taken to ensure that
the data that space occupied is not accessible to future
processes using that space (reallocated) since that data
may be sensitive and any unauthorized reuse may
compromise the system. So, for example, before space is
freed, it is zeroed out. Another example in the
directory/ACL system is the re-use of DNs. Say, DN1 is
created and then at a later date deleted. The recreation
of DN1 (and given to a different person) must be
protected (or in many cases recreation prohibited)
because there may be stale ACLs that still exist and
certainly the person given the recreation of DN1 must not
have access to that data.
Should there also be a U series requirement for a tool to help find stale
ACL entries?
3.2 Semantics / Policy
S1. Policy MUST be administrable on a per-object
granularity.
But U8 says per-attribute access control MUST be supported, which is
finer granularity than per-object. In light of U8, is S1 needed?
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.
I agree with the sentiment, but the definition of "more specific" can
get very involved. This will have to be worked very carefully.
Consider two ACLs. One controls access to "the homePhone attribute of
every object in subtree S" and the other controls access to "all
attributes of the DNs that are members of group X". If group X contains
an object which is also in subtree S, which ACL entry is more specific?
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
Stokes, Byrne, Blakley, Behera [Page 4]
Internet-Draft ACL Requirements 16 October 1997
for user A than a union policy.
S4. Newly created directory entries SHOULD be subject to
a secure default policy.
S5. Access SHOULD NOT be enabled on the basis of
attributes which the directory administrator or his
organization cannot control (e.g. groups whose membership
is administered by another organization).
S6. Access SHOULD NOT be enabled on the basis 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.
S5, and S6 seem like policy recommendations rather than requirements
for the ACL system. S4 is written as a policy statement but has a
mechanism requirement behind it. I don't think policy recommendations
are appropriate for this document; it should focus on requirements for
the design of the ACL system. In the long term we will probably need a
separate document (Security Guidelines for LDAP Administrators?) that
would cover the policy recommendations.
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. Explicit denial SHOULD NOT be supported (i.e.
negative rights). If explicit denial is supported,
explicit "don't care" SHOULD also be supported to allow
administrators to independently state policies they are
competent to manage.
I do not agree with this. There are times when explicit denial can
be quite useful. Given that "override of subtree policy" is required (U7),
one of the most useful overrides is that X, who is given administration
rights at some high level of the tree does NOT have rights over some
independently administered subtree. This seems to need explicit denial
(or maybe we have different ideas of what explicit denial means). I think
we could use some examples here to help understand the issue.
Also, I'm not sure what "explicit don't care" means.
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 objects
(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.
This implies that ALL ACL entries are examined for each access, looking
for the most specific. It may lead to performance problems particularly
when coupled with U6, which seems to require inheritance of rights. I
like the concept, I'm just nervous about what it will mean to
implementations.
S13. Rights management MUST have no side effects.
I suspect this is here because someone sees a potential problem, but I
can't figure out what the potential problem is. I think this needs to
be clarified.
Stokes, Byrne, Blakley, Behera [Page 5]
Internet-Draft ACL Requirements 16 October 1997
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 the administrator, 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 NOT be required to know the
sensitivity of every attribute of every entry (dynamic
schema makes this impossible anyway).
I'm not sure what this means in practical terms. If the administrator does
not know, who does? I assume here that the administrator is the person
who controls the ACL of the object.
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.
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.
See comment on S1.
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
Stokes, Byrne, Blakley, Behera [Page 6]
Internet-Draft ACL Requirements 16 October 1997
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).
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.
MUST it also be possible to PROHIBIT this? Can the tree structure be
protected from view if that is desired by the administrator?
U15. It MUST be possible to create publicly-accessible
entries, which may be accessed 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.
3.4 Nested Groups
Nested Groups is an item that needs to be addressed in
this requirements document. To date, the authors have
not reached agreement on a requirements statement for
nested groups, so this section defines nested groups and
lists the advantages and disadvantages so it may be
debated by the working group. The goal is to reach
agreement on the requirement wording:
Stokes, Byrne, Blakley, Behera [Page 7]
Internet-Draft ACL Requirements 16 October 1997
Nested groups <MUST, MUST NOT, SHOULD, SHOULD NOT, MAY>
be supported.
My vote is MUST or at least SHOULD. Nested groups are a very useful
tool for administration.
3.4.1 Definition
Nested groups refer to the ability for an administrator
to place a group DN on the ACL where that group DN may
include other group DNs.
3.4.2 Advantages
The primary advantages are ease of administration and
ease of maintenance. Groups are a convenient way of
^
Nested
authorizing many people to that object.
And to assign people to groups by role rather than by name.
3.4.3 Disadvantages
The primary disadvantage is an administrator doesn't
necessarily know the consequences of his actions. For
example, if the administrator adds group A to the ACL and
group A includes group B, then from the administrator's
perspective group B is implicitly added and may give
access to a user (in group B) who should not have access.
Sorry, I'm not convinced. The person adding a group to an ACL does not
in general control membership in that group even if the group is not
nested, so it seems there is a problem here even for non-nested
groups. But U11 already requires groups (No, I am NOT suggesting we
eliminate groups!).
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 [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
Stokes, Byrne, Blakley, Behera [Page 8]
Internet-Draft ACL Requirements 16 October 1997
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.
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.
The definitions of Control Attributes and Privilege Attributes could
really use examples.
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.
Stokes, Byrne, Blakley, Behera [Page 9]
Internet-Draft ACL Requirements 16 October 1997
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.