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

[David Chadwick <d.w.chadwick@salford.ac.uk>]

Date forwarded: 	Wed, 15 Mar 2000 08:16:23 -0800 (PST)
Date sent:      	Wed, 15 Mar 2000 10:15:28 -0600
To:             	d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com
From:           	Ellen Stokes <stokes@austin.ibm.com>
Subject:        	Re: please publish (draft-ietf-ldapext-acl-model-05.txt)
Copies to:      	djbyrne@us.ibm.com, blakley@dascom.com
Forwarded by:   	ietf-ldapext@netscape.com

> Responses embedded below and prefaced by (EJS)
> Ellen
>
> >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.

Sorry, I dont buy this, since the application will have to know all the 
family OIDs if it is to be able to understand the meaning and content 
of the aci. There is thus no difference between having to know the 
OIDs of families or the OIDs of the attribute types. You have not 
saved anything by nesting families in a single attribute type (other 
than forcing them to all have the same syntax). Different code will be 
needed for each family OID, just as different code will be needed if 
it were different attribute types. Therefore I still believe the family 
OID is just extra clutter that actually buys you nothing.
  
> 
> 
> >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.  

I know that. What I was saying is that there is not a lesser 
permission than BrowseDN that only allows a read if you know the 
name beforehand. (Consider web access for example. There are 
many web pages that you can only access if you know the URL 
beforehand, but cannot browse to look for them)

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

Agreed, but you do not currently have a way of allowing someone to 
access something they know exists and not have access to 
something they dont know exists. This is what I am suggesting 
should be added.

> 
> 
> >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).

I follow this and agree with the example as far as it goes, but fail to 
see how the example supports the case for multiple role permissions 
to be intersection and not union, which appeared to be the rationale 
for the example, did it not? Also Bob has not said how role and 
group should combine together - would it be union or intersection? If 
it were union, then the precedence of group could be below role and 
his example would still work, would it not? Therefore can Bob explain 
why the example is arguing for group above role.


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

I can buy into this one as the highest precedence for the reason 
stated.

> 
> Hence, the precedence in this current draft (05), (highest to lowest):
> ipAddress access-id, kerberosID group role subtree
> 
> 
> 
> >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?

Ellen I think this is the best way forward, to see what people actually 
want. I was raising the topic for precisely that reason.

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

Again this seems to be the best way forward, lets get some opinions. 
I would argue for allowing multiple attribute types, rather than 
inventing a new collectionname that is only locally known and has to 
be broadcase to applications for them to understand it.

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

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