Re: draft-ietf-ldapext-acl-model-01.txt

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

Erik,
My comments embeddd below with each point and prefaced by (EJS).
Ellen


At 03:53 PM 11/18/98 -0800, Erik Skovgaard wrote:
>Ellen,
>
>Interesting document.  I like some parts of it, but I have some comments,
>some on the pedantic side, some more fundamental:
>
>1. We should really use the term Access Control Information (ACI), not ACL,
>since the latter term implies a simple list of people that are granted
>access to something.  An ACI also contains what kind of access is provided.
> In other words, I see an ACL as part of the content of an ACI.
(EJS) OK.

>
>2. In some cases, you use the term ACL when you really mean just Access
>Control (e.g. the header on each page).
(EJS) Yep.

>
>3. A "discover" right should be added.  It is useful (for security
>purposes) to have the Directory deny that an entry even exists.
(EJS) I think the search right already covers this.  If I do not
have search right, then I cannot know that that entry exists.  But
if I have the read right, I can read that entry.

>
>4. The "Use" right (seems a little out of place.  What you are specifying
>could be an attribute of an application, but it does not really apply to
>the Directory itself.  I think we should keep the two type of use separated.
(EJS)  We see two kinds of access control information that is stored in
the directory:  that which controls access to the directory entry and that
which controls access to the object referenced by the directory entry.
The use/manage/get/set rights refer to the later.

>
>5. I have the same comment for the subjectDN on page 10.  You refer to the
>use of IP addresses.  Using the Directory ACIs may not be appropriate for a
>device, for instance.
(EJS) Here's we're trying to accomodate a wide variety of subjects that
directory servers may want to use for access control.  IP address is one such
subject.
>
>6. You talk about "grouping".  Do you mean sibling entries immediately
>below an entry?  If not, how do I know the members of a group?
(EJS) Groups are directory entries composed of a set of members (DNs).
The group can be read/queried to determine its members.  They are a 
convenience for defining access control when many defining the same access
control for many subjects to a given directory entry or set/subtree of
entries.

>
>7. It is not clear to me how you provide for Prescriptive ACIs?  It greatly
>reduces the administrative complexity when you can have one ACI for an
>entire subtree.  This also calls for the "self" category of access identity
>(as in "allow all owners of entries to read their own attributes") since it
>simplifies the ACI. 
(EJS) The SUBTREE parm can be used to provide mapping to Prescriptive ACIs.
And yes, we'll need to add 'self'.  We'll include some key examples in the
next 
revision to demonstate how to use this model with exiting access control
models.
   
>
>8. I have a more fundamental suggestion.  Why not simply make the ACIs
>operational attributes that "live" in directory entries?  Since we need a
>way of restricting access to the operational attributes, we could:
(EJS)  (This comment applies to remaining paragraphs of note.
I do understand your points, and that's exactly the direction we
took in the version 00 of the ldap access control model document.  However,
at the last IETF meeting (Aug), the general consensus was to define what
flows on the wire plus an indication in the directory of which access control
scheme was in effect in which part of the namespace.  The group did not want
data formats defined.  So what you now have is the set of operations specified
in the 01 version.  However, if your client knows that it's talking to a
server whose access control data formats it understands, the standard ldap
operations certainly can be used.

>
>	a. Mandate the default access to operational attributes (e.g. ACIs) be no
>read, no write and deny existence.  This means they would be invisible to
>regular users.
>	b. Add an operational attribute to the root DSE specifying who is allowed
>to read and write operational attributes (including ACIs).  Let's call this
>the Admin ACI (just to pisck something for now).
>	c. Since *someone* must be able to administer ACIs when the Directory is
>first set up, I suggest using a default DN of '....., cn=Administrator' in
>the root DSE Admin ACI.
>	d. The root DSE should also have a list of the AC Admin points in order to
>allow for distributed administration of AC.  This could be implemented as a
>multi-valued attribute which simply lists the DNs of subtree entry points -
>in other words, Access Control Administrative Points. Operational
>attributes at these points would contain the ACI for the operational
>attributes of the entries in the subtree below.  A subtree specification
>would be nice as well.
>
>Since the ACIs are now attributes (although with a special status), we do
>not need to make extended operations, nor do we need to add any controls.
>This would greatly simplify the implementation of Access Control and it
>would also make it trivial to specify ACIs in LDIF.  In fact, now that I
>think of it, clients do not need to me modified either (other than by
>adding to the recognized schema).
>
>How does a client (e.g. one used for administration) know that the server
>implements Access Controls?  Well, the proposed 'supportedACLMechanisms' in
>the root DSE would indicate the mechanism in place on that server, so that
>should do it.
>
>Cheers,                      ....Erik.
>
>---------------------------------------
>Erik Skovgaard
>GeoTrain Corp.
>Enterprise Directory Engineering
>http://www.geotrain.com
>+1 604 244-9131
>
>
>At 14:18 98/11/18 -0600, Ellen Stokes wrote:
>>Please publish (the draft is attached this time...)
>>Thanks.
>>Ellen
>>
>>Attachment Converted: "d:\program
>files\eudora\attach\draft-ietf-ldapext-acl-model-011.txt"
>>
>