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

[Erik Rissanen <erik@axiomatics.com>]

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.

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
>