Re: Comments on draft-stokes-ldapext-acl-reqts-00.txt

[Ellen Stokes <stokes@austin.ibm.com>]

Responses embedded below and prefaced by (EJS).
Ellen

At 01:02 PM 11/3/97 -0800, Chris Weider wrote:
>Comments on 'Access Control Requirements for LDAP'
>
>
>G3: Text-> ACL administration SHOULD be part of the LDAP protocol
>Comment: What does this mean? ACL administration is already a part of the
>LDAP protocol if ACLs are implemented as specific attributes in each
>entry.... that makes them readable and writeable through LDAP. Did you mean
>something more?
(EJS)  Nope...
>
>G4: Text: Object reuse protection SHOULD be provided and MUST NOT inhibit
>implementation or object reuse.
>Comment: This comes to the first of my major sticking points. Our LDAP
>implementation allows DN reuse because all access control is based on UIDs
>(GUIDs, in our case). I think that the current overloading of DNs as: 1)
>navigational information 2) location information and 3) identity information
>has caused us too many problems. If primary entry identification and
>security can be done on UIDs, that solves the rename and reuse problems.
>This also solves some of the problems listed later in the document. 
>
>Also, enforcing no name reuse also causes scaling problems. Are you supposed
>to put timestamps in DNs to ensure uniqueness? Are you supposed to store all
>the old DNs around? For how long? Years? Decades? Millenia?
>
>The statement on space freeing is an implementation detail and is outside
>the scope of the LDAP protocol. If implementors choose not to zero their
>storage, there's nothing we can do about it.. the market will decide that
>their implementation can't be trusted.
(EJS)  These were meant be just examples (as stated in the text.  Certainly
there are others ways of doing DN reuse, etc.  If people have problem with
the examples here, I'll just remove the examples and leave in just the
first sentence which is the requirement.

>
>S2: Text-> More specific policies must override less specific ones...
>Comment-> We don't have any metrics for security principal specificity. I'm
>not sure we can create a partial ordering that will satisfy everyone, and in
>any case, administering it will be a nightmare. I think we need to rethink
>this. Note that this comment also applies to S3.
>Also, one of MS's basic tenets has been that groups are first order security
>principals. I think this is the correct approach.
(EJS)  This talks about containment and therefore you don't need metrics or
partial ordering. IBM, too, believes that groups are first order security
principals.  On specificity, an ACL for the user is more specific than an
ACL for a group.  That doesn't make groups second class citizens (I can
certainly have just group ACLS on the object).

>
>S5: Text-> 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).
>
>Comment: We're working in a distributed system. Part of the beauty of that
>is that it should allow you to base access on groups from other
>organizations.  Delegation implies trust. If you don't trust a given
>organization, don't include security principals from it. But don't lock it
>the possibility of doing it.
(EJS)  If you read the definition of SHOULD NOT, it doesn't lock out the
possibility of doing it.  The specification can allow it and the access
policy implemented and disallow it.

>
>S7: Text-> Humans SHOULD NOT be required to manage access policy on the
>basis of attributes which are not "human-readable".
>Comment: What does this mean? Isn't this a usability requirement? And
>wouldn't the UI be responsible for most of this? And I could argue that DNs
>are not particularly human readable, either....
(EJS)  It means exactly what's stated.  This is also a usability statement
and usability is a security issue (see statements in first paragraph of 
section 3).

>
>S8: Text-> Explicit denial SHOULD NOT be supported.
>Comment: Explicit denial allows for much easier administration. But what
>does 'don't care' mean?
(EJS)  from previous mail:
What is meant by explicit denial here is the support of a "rights bit" whose
interpretation is "deny operation x" as opposed to "grant operation x".

So for example, the UNIX file system allows only "grant" rights; they are
"r", "w", and "x".  It also supports a "don't care" flag, which is "-".

So a UNIX file system ACL (well, mode bit vector to be precise) of the form

rwxr-x---

Means that the owner are granted rights to read, write, or execute the file
by this entry; 
Members of the owning group are granted rights to read or execute the file
by this entry;
Others are granted no rights by this entry.

In this syntax, there's no way to say "Joe *CAN'T* read the file".  The way
Joe is 
excluded from reading the file is by not putting him in any group which is
explicitly
granted "r", and relying on the default-deny semantics of the ACL
resolution algorithm
to lock him out.

There are many ways to implement semantics of the sort "The public can read
all
attributes EXCEPT payrollCode" without implementing explicit denial.  
One way is to group attributes and give each attribute group a separate ACL.

So, for example, you might define two attribute groups for a particular
directory
object:

normal-attributes INCLUDES ALL EXCEPT payrollCode
private-attributes INCLUDES payrollCode

Then you could have an ACL on the object which looks like this (assuming
that the
rights language contains the same set of "grant" rights as the UNIX file
system --
this of course isn't appropriate for directories but makes it easy to talk
about
the example):

ACL for "object1":

	normal-attributes:  PUBLIC "r--"
	private-attributes: PUBLIC "---" 


>
>S10: Text-> The system MUST be able to support either union semantics or
>intersection semantics for aggregate objects.
>Comment: What is an aggregate object? It seems to me that you're implying
>here that access control is set at the 'object class' level rather than the
>entry level. That seems counter-intuitive.  Since most access control is set
>at the entry level (or at the parent level....) this would mean that we
>would need another set of specificity metrics to determine whether the
>'object class' ACL overrides the 'parent' ACL. I think we have a confusion
>of models here.
(EJS)  Oops, error in the reqt statement - it should say 'aggregate subjects',
not 'aggregate objects'.  (and aggregate subjects are groups).

>S12: Text-> ACL policy resolution MUST NOT depend on the order of entries in
>the ACL
>Comment: Why? The only way to get around this is to have the partial
>ordering of ACLs that I've been saying is a bad idea. We may have to specify
>an order-dependent wire encoding format for ACLs, but I don't think that's a
>problem.
(EJS)  Why?  Big usability problem.  The administrator needs to know that an
ACL always evaluates the same - otherwise is an undesired side effect.  If the
adminsitrator can't easily administer the directory, then he'll be unable to
set up a secure policy and manage it.

>
>S13: Text-> Rights management MUST have no side effects
>Comment: What is rights management? What is a side effect?
>(EJS) From previous mail:
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":

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.

  
>
>U2: Text-> Subjects MUST be drawn from the "natural" LDAP namespace; they
>should be DNs.
>Comment: Why? You're attempting to mandate implementation. It's cleaner and
>more flexible to state that whenever subjects are transmitted between
>machines, they must be transmitted in DN format (i.e. the wire
>representation is a DN. 
(EJS)  To go back to your statement, 'We are specifiying foramts and 
protocols.'  Here we're talking about format; DNs already flow on the
protocol.  

>
>U3: Text-> Is SHOULD NOT be possible via ACL administration to lock all
>users, including the administrator, out of the directory
>Comment: This assumes a single-administrator model that doesn't accord with
>customer's needs from the directory. Also, 'super-user' privileges like this
>can be very dangerous.
(EJS)  How about modifying text to '...including all administrators...' for
clarity?  And we're not implying super-user privileges.

>U6: Text-> Management of access to resources in an entire subtree SHOULD
>require only one ACL.
>Comment: What about junction points in the subtree? Am I supposed to be able
>to propagate ACLs across subordinate references? And should they also flow
>across aliases?
(EJS)  This is a good set of questions.  I'll expand on is in separate note.
I'll also take note that David Chadwick offered a proposal in this area.

>
>U10: Text-> Control of access on a per-user granularity MUST be supported
>Comment: What does this mean? That users should be security principals?
(EJS) User MSUT, groups/roles SHOULD