[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: draft-ietf-ldapext-acl-model-01.txt
Ellen,
I have a few comments. See below.
At 05:05 98/12/09 -0600, Ellen Stokes wrote:
>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.
I still think that should be implemented as an attribute of an entry since
it would be application-dependent. We shopuld be very careful that we do
not confuse the administration of the Directory and its entries with the
administration of applications. Of course, the administration of
applications may ultimately take place by changing directory information,
but it may be performed by different administrators than the Directory
Security Administrator. In your proposal, the two roles would have to be
performed by the same person.
>
>>
>>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.
I have the same comment as above.
>>
>>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.
I think we are running into some confusion here. If we tie the Access
Control to the group entry (e.g. of Object Class groupOfNames), then the
Directory would have to know that an entry is referenced in a group before
it can determine the applicable ACI. For instance, if my entry (cn=Erik
Skovgaard, o=GeoTrain, c=ca) is a member of a group (cn=Directory Weenies,
o=GeoTrain, c=ca) and someone is looking up my entry, how will the
Directory know to check the group?
The group is an independent entry as far as the Directory is concerned - at
least until we have implemented "referential integrity".
Grouping in terms of sibling entries (i.e. immediately below a node) OTOH
makes sense since you'd typically design the DIT that way, anyway.
>
>>
>>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
I agree that it should be possible to determine the access control in
effect for any part of the DIT - if the administrator allows it. But it
can still be done in a simpler way.
I was not at the meeting, so I don't know what transpired, but I would
suggest reviewing that decision for three reasons:
1. The draft proposal is much more complex to implement in servers than
using simply ACIs.
2. The draft proposal would require changes to clients. If we do not
require extensions, clients need not change.
3. The proposed method is very different from X.500 and would make it hard
to implement LDAP servers as a front end to a full X.500 product.
As far as I can tell there has not been any discussion about this
fundamental issue on this list. It is possible that my mail service has
dropped mail, so I apologize if it was discussed.
>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.
Perhaps I missed something here. How so? If this is possible, why do we
need to extend the protocol?
>
>>
>> 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
>>+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"
>>>
>>
>
>
>
Cheers, ....Erik.
---------------------------------------
Erik Skovgaard
GeoTrain Corp.
LDAP & X.500 Training and Professional Services
http://www.geotrain.com/Pserve/psdirect.htm