[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: please publish (draft-ietf-ldapext-acl-model-05.txt)

Responses embedded below and prefaced by (EJS)
Ellen

At 12:35 AM 3/14/00 +0000, David Chadwick wrote: 
Ellen
Please find attached my comments on model-05
David
***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

Comments on ACL model 05

i) I think it is extra clutter to have familyOID as the first component of the
ldapACI attribute type, and does not buy us anything. If you want to define
another set of permissions, then simply give them a new attribute type (e.g.
ldapACIv2) which is itself an OID. It serves no good purpose to have one OID
for the ldapACI attribute then another OID for the family. You might as well
have just one OID that means precisely one set of permissions and access
control information.

(EJS) We could do as you suggest, but I'd rather not. I believe that it is better
to have a single attribute known for ldap access control rather than proliferate
more attributes for this purpose and let the family OID control the remaining
information. This provides an application with one way of accessing access
control information, although it may still have to parse out the information.
If we start propagating different attributes for ldap access control, then it is
difficult, if not impossible, for the application to know which ldap access control
attribute it needs to invoke.


ii) I made a comment on 04 about ReadDN that I don't believe has been
addressed yet. There is a difference between letting someone have access to an
entry they know exists, and ones they don't know exist. I.e. there is a
difference in permissions needed for the base object of a Search and the entries
beneath the base object (the latter is a greater permission than the former). At
the moment BrowseDN gives the latter permission, but there is not the lesser
permission of accessing an entry whose name you already know. This would
call for a ReadDN permission I believe. Comments please on this. 

(EJS) BrowseDN is ReadDN.  BrowseDN allows that DN in a search.  This allows
someone access to only information that he has been authorized for.  A person
may know that an entry exists, but just because he does have that knowledge
does not mean he can access it.  Likewise, if a person doesn't know an entry
exists doesn't mean that he should be able to discover it.


iii) Precedence of privilege dnTypes. I would argue that role comes higher than
group as it is more specific. By this I mean that group membership is usually
conferred on more people than are roles (and as you said in October, roles can
be regarded as groups with permissions). I would expect my role of abc
administrator to have more weight than simply a member of the IETF LDAP
group.

The following is a cut and paste from Bob Blakley's reasoning in his prior email
on the precedence stated in this current draft.

The underlying implementation of the access decision function (which looks
at ACL entries and compares them against the subject's credentials to render
a yes/no decision about a particular access request) may treat "group" entries
differently from "role" entries. For example, it might implement "union semantics"
for groups but "intersection semantics" for roles. Thus if an ACL contained 4 entries:

group1: grant (read, search)
group2: grant (update)
role1: grant (read, search)
role2: grant (update)

A subject belonging to group1 and group2 would be granted access (because
union semantics grants access if any group grants access), but a subject
belonging to role1 and role2 would be denied access (because intersection
semantics grants access only if all roles grant access).

This ability to distinguish groups and roles semantically is important. It
permits security administrators to have two different subject collection
constructs with different granularities and different dynamism.  Roles
(not role attributes -- actual roles) are typically defined at a fairly high
organizational level and changed infrequently. The authorizations granted
to role attributes mirror the organizational responsibilities associated with
the roles.

However in modern organizations roles don't describe the "entire job" of an
individual -- the VP of marketing may be assigned (for a short time) to a task
force evaluating the technical competitiveness of a product. To participate in
this activity, she may need access to engineering data to which her job role
(or roles) as marketing VP don't entitle her. The CFO and the East Region
Helpdesk Director may also be on the taskforce, and may need access to
the same data. To grant the desired access to all three of these individuals,
it would be possible to individually authorize them to the data -- but this would
be bad for several reasons. The first is scale -- for three people this would
be feasible, but for 30 it would be unpleasant, and for 3000 it would be impractical
(especially in organizations which run lots of task forces or have lots of matrix
management). The second is that if you simply put individual entries on the
ACL, you might forget who the individuals are and why they're on the ACL.
In this case you'd very likely forget to take them off the ACL when the task
force ended, thus creating a need-to-know violation.

On the other hand, defining a new "role" for the task force is bad also: task
force membership isn't really a role; it's really an assignment. Adding lots
of roles to the role namespace pollutes the policy environment and makes
it very difficult for the enterprise policy administrators, whose job is defining
work roles and their proper authorizations, to do their work.

What's really called for is defining a "group" -- an ad-hoc collection of users
who can be authorized to the specific set of resources for the duration of the
project as an *exception* to the role-based policy. The group should be given
an evocative name (like the name of the project) and should be authorized to
the resource. When the project ends, the group can be deleted, and its entries
can be removed from the associated resource ACLs.

As this example suggests, in order to support using groups as exceptions to
roles, group attributes and role attributes need to have different precedence.
As the example also suggests, I think groups should have *higher* precedence
than roles, since roles are essentially a coarse-grained, static, subject
collection, and groups are a fine-grained, dynamic subject collection.

Note that many existing security models, including ISO, ECMA-138, CORBA,
and others include both groups and roles (and type-distinguish the two).

For ipAddress, we ought to consider how it will be used. Normally the
requirements are for restricting access to a resource so that either (1) it can
be accessed ONLY from a particular workstation or group of workstations,
or (2) it can NEVER be accessed from a particular workstation or group of
workstations.

Hence, the precedence in this current draft (05), (highest to lowest):
ipAddress
access-id, kerberosID
group
role
subtree

Comments?


iv) On the same vein, can you explain why IP address should be higher than
access-id, when the former can be used by multiple people, the latter by only
one. It is the issue of specificity again. The more specific a dnType the higher
its precedence should be. 

(EJS) See response to iii) above.


v) In my comments to version 4, I mentioned that delete permission for attribute
values could be needed, as with Modify Entry you both add values and delete
values and replace values (I took your write values permission to mean add).
With separate permissions you can allow some people to add, some to delete,
and some to do both. You said you would look into it, but I don't remember
your reply to this. I would suggest changing "write" to "add", and adding
"delete".

(EJS) The write (w) permission is for the ldap_modify operation where that
single operation allows add, delete, and replace. We can certainly change
this so that write permission is broken into two permissions (add and delete)
where replace requires both add and delete. Proposed permissions for
this change are 'w' for write/add and 'o' for write/delete (obliterate) where write/replace
operation requires both w and o to be set. The question in doing this is do
people/applications really make this fine of a distinction in write permissions, for
example where someone may write/add but not write/delete (and vice-versa)?
Comments? What's the consensus here?


vi) Why can an acl entry only confer multiple rights on a single attribute name. I
would have expected <attr> to allow multiple attribute names within it.
(Version 4 allowed this.) Your later example shows the ldapACI being
repeated in order to give SysAdmins access to attr2 and attr3. Why was the
restriction introduced? 

(EJS)  Several people complained that the syntax was too complicated and
hence the restriction.  We can certainly remove the restriction so attribute:
can have one or more attributes.  So you can then specify a grouping of
attributes by collection: <collectionname> or by attribute: <attr>*.
Comments?  What's the consensus here?


vii) Section 9 introductory paragraph talks about manipulating access rights and
getting and setting them. But as I read it, the section only provides a
mechanism to read them, not to update, set or manipulate them. Can you alter
the wording please.

(EJS) You are correct. I will alter the wording to reflect read, not write (oversight
on my part).