Re: [xacml] Re: Combining algorithm combining orders

[Erik Rissanen <erik@axiomatics.com>]

It is not correct in my opinion in this case.

First, consider a case which I think is correct. If the permit overrides 
algorithm receives two inputs, a permit and an indeterminate, it will 
choose permit. This is correct since when the algorithm sees a permit, 
it knows that no matter what the policy would have been, the end result 
would have been permit. So it can discard the indeterminate and go with 
permit.

However, if the permit-overrides algorithm gets to choose between a deny 
and an indeterminate, it says deny, which is not correct. The purpose of 
the permit overrides algorithm is to give priority of permit over deny. 
In this case one of the policies could not be evaluated correctly. It 
could potentially have been a permit, in which case the algorithm should 
return permit. On the other hand if the second policy would have been 
something else, the algorithm should return deny. In this case the error 
has an impact on the end result, so the error should be propagated upwards.

Regards,
Erik


Daniel Engovatov wrote:
> I am not sure I am following your logic.    In this case a combining 
> algorithm does make a prescribed decision, and it is DENY, so clearly 
> it can be made.   It is not an arbitrary choice at all - it seems like 
> a very reasonable behavior for a whole lot of use cases.
>
> What we really need is a normative way to define interchangeable 
> combining algorithms - for example using some language, like XQuery.
>
> Daniel;
>
> On Oct 23, 2008, at 12:43 AM, Erik Rissanen wrote:
>
>> You are right, errors should not be propagated if it can be avoided, 
>> but we are discussing two particular cases where propagation of the 
>> error cannot (or should not) be avoided since a clear decision 
>> _cannot_ be made. Currently the combining algorithms make an 
>> arbitrary choice to deny access in case of an error, which is not 
>> correct if analyze how the error could affect the final outcome. 
>> There are other cases where the combining algorithms correctly 
>> discard errors since they can tell from the other policies that the 
>> error shouldn't affect the outcome.
>>
>> There is no issue with giving an attacker information, since we are 
>> propagating the error to the PEP, which controls the resource anyway.
>>
>> Regards,l
>> Erik
>>
>> Daniel Engovatov wrote:
>>>
>>> On Fri, 26 Sep 2008 , at 11:52 PM, Erik Rissanen wrote:
>>>
>>>> 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.
>>>
>>> Error propagation safety???    Error should not be propagated if 
>>> that can be avoided.   The whole point of Indeterminate value is 
>>> that it can be explicitly handled by a combining algorithm, and 
>>> error propagation avoided whenever possible.    Just throwing an 
>>> exception all the way to the client is what we have tried to avoid.
>>>
>>> In all the examples result would be Deny if no error had occurred.   
>>> There is no reason to propagate errors (and to give a would be 
>>> attacker any hints that some sort of disruption actually worked) 
>>> when there is a clear decision.    It is somewhat different on the 
>>> rule combining level, as it does not return the result to the PEP, 
>>> so it is ultimately handled on the policy combining level.
>>>
>>> I think we have designed it this way on purpose.   I do not think it 
>>> is a mistake.
>>>
>>> Daniel;
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>