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

[Erik Skovgaard <eskovgaard@geotrain.com>]

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.

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

3. A "discover" right should be added.  It is useful (for security
purposes) to have the Directory deny that an entry even exists.

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.

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.

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?

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.

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:

	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"
>