Re: [xacml-comment] Reduction Should Use Extended Indeterminate Values

[Steven Legg <steven.legg@enitiatives.com.au>]

Hi Erik,

On 30/08/2011 8:57 PM, Erik Rissanen wrote:
> Thanks Steven,
>
> What you say makes sense. But I would prefer to let the 3.0 profile stay now rather than changing it so
> late. We can improve it in another version in the future.
>
> The reduction of indeterminate was put there most importantly to protect against denial of service attacks
> by malicious policies. Basically we test whether the policy would be authorized for a Permit or Deny, to
> determine whether the Indeterminate should be considered. This protects against "completely unauthorized"
> DoS attacks.
>
> Correct me if I am mistaken, but for that purpose your proposed improvement does not make any difference
> since if a policy author has malicious intent, and some form of delegated authorization, he can always
> produce the "worst possible" flavor of Indeterminate just by changing the structure of his policy.

Correct. The improvement would halve the number of places in the reduction
graph where an attacker could make a PDP waste time on useless policies,
but that just means an attacker will concentrate on the half that are
still available.

Regards,
Steven

>
> Best regards,
> Erik
>
>
> On 2011-06-30 01:35, Steven Legg wrote:
>>
>> The reduction process specified in Committee Specification 1 of the XACML v3.0
>> Administration and Delegation Profile Version 1.0 could be improved by making
>> use of the extended indeterminate values. It does not currently do so.
>>
>> Suppose that in the evaluation of the administrative request A against P2 in
>> Section 4.7, the result is "Indeterminate{D}". Currently this means there is a
>> PI edge from P1 to P2 in the reduction graph, which may then contribute to an
>> overall indeterminate result for the policy set. However, if the circumstances
>> causing the indeterminate result for request A were to be corrected (for
>> example, by providing a missing attribute), the result would be "Deny" or
>> "NotApplicable" and there would be no PI edge from P1 to P2. The presence of a
>> PI edge in the case of "Indeterminate{D}" is not helpful. It only serves to
>> introduce an unnecessary indeterminate result.
>>
>> A better formulation of 1.c in Section 4.7 would be:
>>
>> If and only if the result is "Indeterminate{DP}" or "Indeterminate{P}",
>> there is a PI edge from P1 to P2.
>>
>> Similarly, there is a better formulation of 2.c:
>>
>> If and only if the result is "Indeterminate{DP}" or "Indeterminate{P}",
>> there is a DI edge from P1 to P2.
>>
>> The reduction of "Indeterminate" (Section 4.10) could also be improved by
>> taking extended indeterminate values into account.
>>
>> In section 4.10, suppose that policy P evaluates to "Indeterminate{D}".
>> Currently that result is combined into the result for the policy set if there
>> is a path of PP and PI edges to a trusted policy or a path of DP and DI edges
>> to a trusted policy. However, policy P could otherwise only evaluate to "Deny"
>> or "NotApplicable", and in neither of these cases would a path of PP and PI
>> edges be considered. Considering the PP and PI edges when P evaluates to
>> "Indeterminate{D}" does not appear to be either useful or appropriate. A
>> similar case applies with regard to the DP and DI edges when P evaluates to
>> "Indeterminate{P}".
>>
>> A better formulation of the reduction of "Indeterminate" would be to follow
>> the PP and PI edges if and only if policy P evaluated to "Indeterminate{DP}"
>> or "Indeterminate{P}", and to follow the DP and DI edges if and only if policy
>> P evaluated to "Indeterminate{DP}" or "Indeterminate{D}".
>>
>> Regards,
>> Steven
>>
>
>