[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on Access Control Requirements draft
Ellen Stokes wrote:
> My responses embedded below and prefaced by (EJS).
> Ellen
>
> At 02:39 AM 12/12/97 -0500, Richard V Huber wrote:
> >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
> >
> >--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
> >
> > 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.
>
The storage of ACL information in a standard fashion within the LDAP tree is vital
to the survival of the protocol.The result of not including this feature will be
the evolution of deliberately incompatible standards by software vendors.
The method of ACL storage should be flexible to accommodate evolving Role based
access methods in addition to
traditional Access Groups
> (EJS) I'll add requirement to say that access control information is
> an LDAP attribute.
>
> >
> > 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?
> (EJS) IETF does not generally standardize tools. What I suggest is that
> as part of the LDAP server deployment working group that a set of deployment
> guidelines or tools be identified.
>
> >
> > 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?
> (EJS) Yep, you found a conflict. I'll modify S1 to state "...per-object
> or finer granularity."
>
> >
> > 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.
> >(EJS) Yep. I'll reword S5 and S6 to read "Access policy SHOULD NOT be
> expressed in terms of...".
> And yes, in the long term, I see the LDAP server deployment working group
> adding a document governing security guidelines (once we get access control,
> replication, etc into the LDAP).
>
Perhaps if we could create an access attribute that, when set, would affillate an
LDAP object with one or more otherobjects permitting the creation of object
grouping within the directory and thereby concentrating the access attributes
to a manageable set of key objects.
This group affiliation would be an alternative to individual assignment, which
would be available as needed.
This would foster the establishment of security policies within the directory
which would be easily managed by
granting security admin.'s permission to selected key LDAP objects which serve as
keystones while screening
the individual object data from delegated admin.'s who have no need to use the
objects themselves
I understand this challenges the "rights management side effects" indirectly by
creating relationships between objects.
But I challenge this group to anticipate the inclusion of Agents as directory
objects. (a change which would create
directory entries which would have side-effects)
This change would satisfy the Explicit denial argument which follows and permit
permission structures to form, while
preventing vendor lock-in (vendor specific solutions for this, in the form of
third party products will be forthcoming should this group fail to anticipate
dependant and related object permissions)
> > 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.
> (EJS) Here's more information on explicit denial (it was posted previously
> in response to an earlier set of comments):
>
> Explicit denial example
> -----------------------
>
> Suppose the rights for an object are defined as r, w, and x, and the
> defined groups are
> printer_users, printer_admins, printer_operators, dept57, and dept58 with
> the following
> association ('grant' grants access, 'deny' denies access, and '-' is "don't
> care"):
>
> r w x
> Printer_users - grant deny
> Printer_admins grant grant grant
> Printer_operators grant grant grant
> Dept57 grant deny deny
> Dept58 deny grant deny
>
> Case: If a user in is both the printer_users and dept57 groups, then r is
> granted, w is
> denied, and x is denied.
> Case: If r/w/x are all don't care, then there is a default permit or deny
> policy that
> resolves this.
> Case: If r/w/x is grants & don't cares, then resolution is grant.
>
> >
> > 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.
> (EJS) Here's the proposed exapnsion (a response to a previous set of
> comments):
> Sorry; this text wasn't explicit enough. Here's a more explicit version; this
> defines what is meant by "rights management MUST have no side effects":
>
There are times when relationships are beneficial, when properly regulated
> Granting a subject a right to an object MUST NOT implicitly grant any other
> subject the
> same right to that object.
>
> Granting a subject one right to an object MUST NOT implicity 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.
>
> >
> > 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.
> (EJS) It falls first to the developer of the schema to decide on the
> sensitivity since he udnerstand best the attribute/data and not the
> administrator.
> The administrator should pick up his knowledge from the developer of that
> schema.
>
> >
> > 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?
> (EJS) Yep, I'll add/refine requirement.
>
> >
> >
> > 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.
> >
> > 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.
> (EJS) Will do... An access control list or list of rights or time of
> day range are examples of control attributes. Group/role membership
> is example of privilege attributes.