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

[Bob Blakley <blakley@dascom.com>]

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 (blakley@dascom.com)
Chief Scientist, Dascom

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:+1 (512) 458-4037 x 5012
TEL;WORK;FAX:+1 (512) 458-2377
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;Plaza Balcones=0D=0A5515 Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Plaza Balcones=0D=0A5515 Balcones Drive=0D=0AAustin, TX 78731=0D=0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:blakley@dascom.com
REV:19991022T193657Z
END:VCARD