Subject: Re: Comments on aci-model-04

From: [email-masked]
Date: Mon, 25 Oct 1999 16:13:04 -0500

David,

Here's a mapping I proposed in another note:

3) Mapping of LDAP rights to operations :

> 9) A major omission from the document is that nowhere could I find the
mapping
> from required rights to LDAP operations. This should be included for each
LDAP
> operation (even if in some cases it is simply that one right is needed
for a
> particular operation e.g. delete an entry). The complex one is obviously
the search
> operation. I suggest you need read rights for every attribute returned
and search
> rights for every attribute in the filter.

Here's my suggested mapping:

LDAP Op             Right Req.

Add entry           add ( on parent entry )
Delete entry             delete ( on entry )
Modify an attribute      write ( on attribute )
     - includes adding, deleting or replacing values.
Search ( ret. attributes only )    search on attribute
Search ( ret attr + values )  search and read on attribute
Compare             compare

The search ( as David mentions )  is complex. There needs to be multiple
levels of access control checks; on both the filter attributes and on the
returned attributes.  The filter check is crucial so that search operations
such as userpassword=secret do not return data where the person does not
have permission to know the value of userpassword.

I suggest a two pass access control check on the search. The first pass is
over the attributes listed in the search filter. The second pass is over
the attributes that are to be returned to the client.  Say objectA matches
the search criteria. In the first pass, if the user does not have both
read, and search on the attribute, the search can not return objectA's DN.
If the user has permission to the filter, then evaluate the second pass and
return the DN + whatever attributes are allowed based on whether the user
is asking for the attribute only, or the attribute and value. ( ReadDN is
in the next point )

4) ReadDN

> 10) A possible missing right is readDN for an entry. This cannot be fully
covered by
> read attribute rights, as the latter will only give rights to the RDN,
not the DN.

The algorithm in #3 could have another step where the model evaluates
whether the user has permission to know that the DN even exists. This would
be the 'ReadDn'  which David brought up. We could overload 'search' to
apply to both the object and the attribute. In the case of the object, it
would grant permission to read the DN.  In order to reduce confusion, I
think I would prefer a separate permission, even though our permission set
is becoming somewhat lengthy.

INet: [email-masked]
Lotus Notes : djbyrne@ibmus
Phone: (512)838-1930 ( T/L 678 )

"David Chadwick" <[email-masked]> on 10/25/99 07:32:57 AM

Please respond to [email-masked]

To:   "Jim Sermersheim" <[email-masked]>, Debora Byrne/Austin/IBM@IBMUS,
      "Bob Blakley" <[email-masked]>
cc:   [email-masked], [email-masked]
Subject:  Re: Comments on aci-model-04

>
> However semantically they may be different.  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:
>

Bob
This is another example of the lack of precise definition that worries
me. There is too much vagary (vagueness?) in the acl model as it
stands. I have already commented previously that nowhere is it
stated which permissions are needed (i.e. which grants are needed)
for which operations, in order for them to be successfully
performed. Now we also seem to have a variable ACDF in which
different implementations use the same ACI and derive different
results. So without a fixed and clearly defined ACDF, and fixed
permissions per operation, it seems pointless to talk about
precedences of various ACIs (which we have been doing) , since
by extension, each ACDF can determine its own precedence rules.

Comments?
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 [email-masked]
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

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

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 27 Oct 1999 22:32:16 +0100

> Add entry           add ( on parent entry )
OK
> Delete entry             delete ( on entry )
OK
>      - includes adding, deleting or replacing values.

I would prefer add on attribute to add an attribute and delete on 
attribute to delete an attribute. To replace you would need both 
permissions. There may be times when you are happy for someone 
to add information, but not remove it. Hence separate permissions 
for adding and removing.

> Search ( ret. attributes only )    search on attribute

I think this should be read on attribute in order to return it
and search on attribute in order to use it in a filter (presence in a 
filter without search permission will yield undefined)

> Search ( ret attr + values )  search and read on attribute

See above. We might also require read on the entry in order to 
return the entry. Without this the entry would be omitted from the 
Search results.

> Compare             compare

Compare on attributes. Attributes without this permission would  
return false.
David

> 
> The search ( as David mentions )  is complex. There needs to be
> multiple levels of access control checks; on both the filter
> attributes and on the returned attributes.  The filter check is
> crucial so that search operations such as userpassword=secret do not
> return data where the person does not have permission to know the
> value of userpassword.
> 
> I suggest a two pass access control check on the search. The first
> pass is over the attributes listed in the search filter. The second
> pass is over the attributes that are to be returned to the client. 
> Say objectA matches the search criteria. In the first pass, if the
> user does not have both read, and search on the attribute, the search
> can not return objectA's DN. If the user has permission to the filter,
> then evaluate the second pass and return the DN + whatever attributes
> are allowed based on whether the user is asking for the attribute
> only, or the attribute and value. ( ReadDN is in the next point )
> 
> 4) ReadDN
> 
> whether the user has permission to know that the DN even exists. This
> would be the 'ReadDn'  which David brought up. We could overload
> 'search' to apply to both the object and the attribute. In the case of
> the object, it would grant permission to read the DN.  In order to
> reduce confusion, I think I would prefer a separate permission, even
> though our permission set is becoming somewhat lengthy.
> 
> 
> INet: [email-masked]
> > 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:
> >
> 
> Bob
> stands. I have already commented previously that nowhere is it stated
> which permissions are needed (i.e. which grants are needed) for which
> operations, in order for them to be successfully performed. Now we
> also seem to have a variable ACDF in which different implementations
> use the same ACI and derive different results. So without a fixed and
> clearly defined ACDF, and fixed permissions per operation, it seems
> pointless to talk about precedences of various ACIs (which we have
> been doing) , since by extension, each ACDF can determine its own
> precedence rules.
> 
> Comments?
> David
> 

David Chadwick