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] Opened issue 32, Exception handling


Anne Anderson - Sun Microsystems wrote:
> Erik,
>
> Erik Rissanen wrote On 02/20/07 07:12,:
>> All,
>>
>> I have opened issue 32, which has been closed, waiting for the
>> delegation stuff to mature. I also added an problem to it which was
>> discovered by Olav here at SICS. For your convenience, the text here:
>>
>>
>>         32. Exception handling
>>
>> Section 7.15.3 in the XACML 2.0 specification contains definitions for
>> what diagnostic information the PDP shall return in certain cases
>> (missing attributes). We need to see whether the delegation
>> functionality affects any of this and how diagnostics of administrative
>> requests are to handled when returning to the PEP. Also, the extra
>> processing of delegation may introduce more diagnostic cases, for
>> instance failed reduction.
>>
>> There is also an issue with indeterminate results and delegation which
>> has been explored by Olav Bandmann at SICS. In XACML 2.0, if a policy
>> evaluates to indeterminate, in many cases the indeterminate result is
>> pushed up to the final result, indicating that something went wrong.
>> However, if a policy with an issuer evaluates to indeterminate, it is
>> discarded (in the current draft 15). This means information about this
>> failure is lost, and a valid result is returned, although there has been
>> an error. In certain circumstances an attacker could exploit this. If he
>> could for instance disturb attribute provisioning, he might be able to
>> effectively disable policies, without there being an error in the final
>> result.
>
> The implementation could report an error on the PDP side, so the
> failure information is not necessarily lost.
>
> Anne

Anne,

Unfortunately, it isn't that simple. The PEP has to either let the
access happen or stop it regardless of what happens on the PDP side.
This means that the PDP has to provide sufficient information to the PEP
so it can enforce something. In some cases the result from the PDP may
be an indeterminate, in which case the bias of the PEP will make the
decision.

The real issue here is whether an error from an untrusted policy is
allowed to influence the decision of the PDP. It isn't a simple problem,
but Olav has an idea for how to do it. I haven't had time to write up a
proper explanation of the issue yet though. I'll get back on it.

Regards,
Erik

>>
>> On the other hand, we don't want to combine an indeterminate from an
>> untrusted policy, since that would be an easy denial of service attack
>> by someone who is able to publish policies.
>>
>> One (the only?) way to handle this is to reduce indeterminate results.
>>
>>
>> Regards,
>> Erik
>>
>>
>




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