Re: Examples (differing privileges, DNs) for aci-model-04

[Bob Blakley <blakley@dascom.com>]

David Chadwick wrote:

>Brian
>Here are my preferred options (which I believe are also compatible
>with the X.500 ACDF)

I want to observe before starting into the details that we were trying to
AVOID
constraining the policy semantics of back-end implementations in the draft
because several LDAP implementors had made incompatible choices, and
specifying semantics at this level might require them to change established
implementation behaviors.  However, if the group feels strongly that it's
appropriate
to do this, I'm happy to see it happen ("the more standard, the better"), and
my preferences are enumerated below.

>>
>> Example #1
>> dn: o=XYZ, c=US
>> aci#1.1: 1.2.3.4#subtree#grant;r;attribute1;#access-id#cn=bjarvis
>> aci#1.2: 1.2.3.4#subtree#grant;w;attribute1;#group#cn=G1wBJarvis
>>
>> What rights does cn=bjarvis have to attribute1 of o=XYZ, c=US?
>> Two reasonable answers:
>> A1.1: r    (aci#1.1 overrides aci#1.2 because access-id is higher
>> precedence than group)
>> A1.2: r,w    (rights are ORed between aci#1.1
>> and aci#1.2) I can see how some might prefer A1.1, but I strongly
>> prefer A1.2. I submit that "because access-id is higher precedence
>> than group" does not apply because both ACIs are grants.
>
>A1.2 would be my choice.

My choice is A 1.1, for two reasons:

(1) This choice is the one implemented by UNIX, NT, DCE, and a host of other
access control systems.  The practical import of this is that security
administrators
are accustomed to the strict precedence model, and if you give them something
different they'll be confused based on their experience of many other systems.

(2) Implementing A 1.2 is substantially more complicated than implementing A
1.1.
With a strict-precedence model (A 1.1), the implementation can check for which
entries
are eligible to participate in the decision using the precedence rules, then
execute a very simple combination algorithm (e.g. AND, OR, or either of these
with a slight modification to implement the precedence of deny vs. grant).
With the hybrid model proposed in A 1.2, you have to consider ALL entries in
every access decision, and examine every entry to see whether the particular
operations requested are granted or denied.  You also have to worry about
whether
entries which don't mention the requested operation should be treated as
"default grant" or "default deny", and you have to run a hierarchical decision
algorithm over all entries if you encounter any entry which has either an
explicit
or an implicit deny for any one of the requested operations.  The code is much
more complicated, and because in the normal case (i.e. granted access) it must
look at the permissions for all entries in the ACL, it is also slower.

I feel very strongly about this one.

>>
>> Example #2
>> dn: o=XYZ, c=US
>> aci#2.1: 1.2.3.4#subtree#grant;r;attribute2;#group#cn=G1wBJarvis
>> aci#2.2: 1.2.3.4#subtree#grant;w;attribute2;#group#cn=G2wBJarvis
>>
>> What rights does cn=bjarvis have to attribute2 of o=XYZ, c=US?
>> One reasonable answer:
>> A2.1: r    (rights are aci#2.1 "OR" aci#2.2)
>> I strongly prefer A2.1.
>>
>
>I would strongly prefer r and w which is not in your list (although I
>suspect there is an error in your email, since you only gave one
>option)

Like David, I strongly suspect that Brian's A2.1 is supposed to be
"rw", not "r", and this is the option I prefer.  But I feel compelled to
observe that there is another reasonable answer:

A2.2: no access (rights are aci#2.1 "AND" aci#2.2)

>> Example #3
>> dn: o=XYZ, c=US
>> aci#3.1: 1.2.3.4#subtree#grant;r,w;attribute3;#group#cn=G1wBJarvis
>> aci#3.2: 1.2.3.4#subtree#deny;w;attribute3;#group#cn=G2wBJarvis
>>
>> What rights does cn=bjarvis have to attribute3 of o=XYZ, c=US?
>> Two reasonable answers:
>> A3.1: r    (rights are aci#3.1 "minus" aci#3.2)
>> A3.2:none    (aci#3.1 overrides aci#3.2 because deny is higher
>> precedence than grant) I strongly prefer A3.1.
>>
>
>Agreed.

I agree also, but you have to consider another case also -- what happens if
the
order of aci#3.1 and aci#3.2 are reversed?  Is evaluation of these policies
order-sensitive?  If so, then evaluating the two commands in reverse order
results in "rw".  If we don't support order-sensitivity, then there's no way
(administratively)
to reverse the effect of a "deny" operation without actually deleting the ACL
entry
and creating another entry with the same DN (which seems clumsy).

>A grant should not override a grant.

But I don't understand what's meant by this statement.

>> Example #4
>> dn: o=XYZ, c=US
>> aci#4.1: 1.2.3.4#subtree#grant;w;attribute4;#access-id#cn=bjarvis
>> aci#4.2: 1.2.3.4#subtree#;r;attribute4;#access-id#cn=ABC
>>
>> What rights does cn=bjarvis have to attribute4 of o=XYZ, c=US?
>> Two reasonable answers:
>> A4.1: w    (aci#24.2 has no bearing--no "identity equivalence")
>> A4.2: r,w    (rights are aci#1.1 "OR" aci#1.2 because of "identity
>> equivalence") I can see how some might prefer A4.1, but I strongly
>> prefer A4.2.
>
>I dont follow where your identity equivalence came from. Sorry.
>Was ABC meant to be an alias of bjarvis?

I'm with David here.  "Huh??"

--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:19991022T204433Z
END:VCARD