Subject: Re: grant / deny precedence indraft-ietf-ldapext-acl-model-04.txt

From: "Bob Blakley" <[email-masked]>
Date: Fri, 22 Oct 1999 14:36:57 -0500

Brian Jarvis writes:

>In general, I agree.  But I think the more specific the ACI, the more
precedence it should have.

This is the standard security convention, and I agree

>Example #1:
>BJarvis is a member of Group1
>aci: 1.2.3.4#subtree#deny;r,w;[all];#group#cn=Group1
>aci: 1.2.3.4#subtree#grant;r,2;[all];#access-id#cn=BJarvis
>
>I maintain that access-id is more specific than group and thus in example #1,
grant has precedence over deny.

Again, this is the standard security convention, and I agree.

>This implies that we need to define a precedence order for dn-types.

Yes.

>I would propose (lowest--least specific) group, role, ip-address?, access-id
(highest--most specific).

For reasons explained in my earlier note, I consider group to be more specific
than role.  So my partial order goes:

    (lowest--least specific) role, group, access-id (highest--most specific).

My personal feeling is that ip-address is completely useless as a subject
field and shouldn't be allowed as
a privilege attribute at all.  However if we have to have it, we ought to
consider how it will be used.  Normally
the requirements I see 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.

If this is the right requirement, then I'd claim that the precedence order
which satisfies this requirement is:

    (lowest--least specific) role, group, access-id, ip-address (highest--most
specific).

>Example #2:
>aci: 1.2.3.4#subtree#deny;r;w;[all];#group#cn=Group1
>aci: 1.2.3.4#entry#grant;r;w;[all];#group#cn=Group1
>
I> maintain that entry is more specific than subtree and thus is in example
#2, grant has precedence over deny.

I agree and think that the current text in the spec suggests (if it doesn't
actually mandate) that
entries with an "entry" ACL override "subtree" policies for subtrees
containing the entry.

>This implies that we need to define a precedence order for scopes.

Right.

>I would propose (lowest--least specific) subtree, <level>, entry
(highest--most specific).

Yeah, but get rid of <level> (as I think we've already agreed here)

>When ACIs are of equal precedence, I think deny should override grant as a
safety issue.

I agree.  Again this is standard practice.

>When they are not of equal precedence, I maintain that the precedence order
should
>determine ACI overrides rather than grant/deny.

I agree again, and again this is the standard security convention.

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

---

From: [email-masked] (Prasanta Behera)
Date: Fri, 22 Oct 1999 13:10:10 -0700

Bob Blakley wrote:

> a privilege attribute at all

Can time based ( like timeofday and dayofWeek)
or authentication strength  can be considered as privilege attributes.
I think it should be.

It will be very hard to get a exact precedence rule once we throw in
new privilege attributes. Should we think of  "precedence category".

Thanks
/prasanta