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: Re: [xacml] Re: Combining algorithm combining orders


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



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