OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Combining algorithm combining orders


All,

In my opinion the both the deny overrides and permit overrides policy 
combining algorithms are wrong. They treat errors in an incorrect and 
unsecure manner. The corresponding rule combining algorithms are 
correct, and the policy combining algorithms should work in a similar 
manner.

The Indeterminate result in XACML is used in those places where the 
result of some part of the policy cannot be determined because of some 
form of error. It is important that if such an indeterminate result 
affects the final decision of the PDP, that the indeterminate is 
returned to the PEP so that the PEP knows that there is an error. If so 
is not done, errors in policies might not be noticed or an attacker 
might be able to force the PEP into some bad action by causing errors in 
the PDP (for instance by interrupting attribute provisioning services).

If we want to determine whether an Indeterminate should affect a result, 
we can consider the indeterminate to be a result which potentially could 
be either Permit, Deny or NotApplicable and for each of them see what 
the overall result would be. If the overall result depends on which 
choice we make for the Indeterminate, then the Indeterminate should be 
propagated "further up" in the policy evaluation. (If you don't 
understand what I mean, just read on, I will provide examples.)

Currently the permit overrides policy combining algorithm works like 
this (using the updated textual description):

1.    If any policy evaluates to "Permit", the result is "Permit".
2.    Otherwise, if any policy evaluates to "Deny", the result is "Deny".
3.    Otherwise, if any policy evaluates to "Indeterminate", the result 
is "Indeterminate".
4.    Otherwise, the result is "NotApplicable".

Notice how a deny goes before indeterminate. That is a bad priority. 
Consider a policy set with two policies A and B. Assume that A is deny 
and B is indeterminate. Consider what the overall result could be if 
policy B would not have an error in it:

A: Deny
B: could be Deny
-> overall would be Deny

A: Deny
B: could be NotApplicable
-> overall would be Deny

A: Deny
B: could be Permit
-> overall would be Permit

Notice how the result depends on what the indeterminate could 
potentially be. However the current definition gives a definite Deny in 
all cases. This breaks the error propagation safety of the combining 
algorithm. In some applications availability could be critical, and a 
PEP might have a bias that indeterminate means that access is allowed. 
In such a case harm could be caused by this behavior.


Now consider the deny overrides instead. Currently the deny overrides 
policy combining algorithm works like this (using the updated textual 
description):

1.    If any policy evaluates to "Deny", the result is "Deny".
2.    Otherwise, if any policy evaluates to "Indeterminate", the result 
is "Deny".
3.    Otherwise, if any policy evaluates to "Permit", the result is 
"Permit".
4.    Otherwise, the result is "NotApplicable".

Note how an indeterminate is converted to a Deny. This gives the 
following behavior.

A: Permit
B: could be Deny
-> overall would be Deny

A: Permit
B: could be NotApplicable
-> overall would be Permit

A: Permit
B: could be Permit
-> overall would be Permit

Again, there is a definite result from the combining algorithm although 
the underlaying logic is ambiguous.

As I said we have discussed this previously. The threads are here:

http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
http://lists.oasis-open.org/archives/xacml/200702/msg00019.html

I propose that we define new identifiers for new combining algorithms 
for 3.0 which work like this:

Deny overrides:
1.    If any policy evaluates to "Deny", the result is "Deny".
2.    Otherwise, if any policy evaluates to "Indeterminate", the result 
is "Indeterminate".
3.    Otherwise, if any policy evaluates to "Permit", the result is 
"Permit".
4.    Otherwise, the result is "NotApplicable".

Permit overrides:
1.    If any policy evaluates to "Permit", the result is "Permit".
2.    Otherwise, if any policy evaluates to "Indeterminate", the result 
is "Indeterminate".
3.    Otherwise, if any policy evaluates to "Deny", the result is "Deny".
4.    Otherwise, the result is "NotApplicable".

Best regards,
Erik



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]