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] Optimizing <Target> evaluation


This issue was deferred to the next call, so I am bumping up this 
message so it's not forgotten.

I would also like to explain more carefully why it is more consistent to 
give priority of a non-matching target section before an indeterminate 
in the target evaluation.

An Indeterminate result is used when the value of an evaluation cannot 
be determined. Consider the following example:

  <AnyOf> ... this evaluated to "Match" ... </AnyOf>
  <AnyOf> ... there is an error retrieving an attribute here -> 
Indeterminate ... </AnyOf>

In this case we don't know the value of the second <AnyOf>. If we would 
have been able to resolve the attribute, the value could be either Match 
or NoMatch. If we consider these two possibilities for the whole target, 
we see that in the first case the whole target is a Match and in the 
other case it's a NoMatch. This means that because of the error in the 
section of the target, the value of the whole target is uncertain, and 
we should therefore treat that whole target as Indeterminate as well.

Now, consider the following case:

  <AnyOf> ... this evaluated to "NoMatch" ... </AnyOf>
  <AnyOf> ... there is an error retrieving an attribute here -> 
Indeterminate ... </AnyOf>

Again, the section which failed could be either NoMatch or Match if it 
would have been non-failing. But in this case the value of the whole 
target would be NoMatch in either case, so it would be safe to return a 
NoMatch for the whole target. However, currently the specification says 
that the whole target should be Indeterminate. This is not consistent 
with the meaning of Indeterminate as "the value of the policy is 
uncertain". And it is also suboptimal from a performance point of view.


BTW, it was by reasoning like this Olav Bandman at SICS discovered 
similar inconsistencies in some of the combining algorithms, and he was 
able to "exploit" them to make the PDP go from Permit to Deny, or vice 
versa, by imagining that an attacker could force a failure in attribute 
resolution. We discussed this some time ago, but there was some 
resistance to fix this. I still think it would be better to update the 
combining algorithms in 3.0 and "deprecate" the old versions. I can 
imagine there are similar performance issues in the combining algorithms 
as well, but I haven't looked into it yet.

Erik Rissanen wrote:
> All,
> I have been considering how to optimize evaluation of the <Target>, 
> and I think the standard could be improved for 3.0.
> There are several levels in the target, and their behaviour has been 
> inherited from the 2.0 specification. The levels of combining results 
> in the target matching are <Target>, <AnyOf> and <AllOf>. The issue I 
> am considering is the priority of an Indeterminate result in the 
> combination at these levels.
> At the <Target> level if at least one of the children is 
> Indeterminate, then the whole target is Indeterminate, regardless of 
> the other values.
> At the <AnyOf> level if at least one of the children matches, then the 
> whole <AnyOf> is a match, regardless there are any Indeterminate 
> values in the other children.
> At the <AllOf> level if at least one of the children is "false", then 
> the whole <AllOf> is a no match, regardless there are any 
> Indeterminate values in the other children.
> At first, one can note that the treatment of Indeterminate is somewhat 
> inconsistent. At the <Target> level Indeterminate has priority, while 
> at the other levels it does not.
> I would think that it makes more sense that Indeterminate does not 
> have priority since if we know that a section of the target does not 
> match, then we know for sure that the policy does not apply, so it 
> would be safe to ignore the indeterminate from the other parts of the 
> target. Conversely, if all parts of the target match, except that 
> there is also an indeterminate, then it makes sense that the 
> indeterminiate result is propagated upwards since we cannot know 
> whether the policy applies or not.
> There is also a performance optimization argument in favour of 
> changing the <Target> behaviour. The current behaviour means that if 
> the PDP finds a section in the target which does not match, it still 
> has to evaluate the remaining sections to determine that there is no 
> Indeterminate result. In most cases we would expect that 
> Indeterminates are less common than non-matching targets, so we can 
> expect better performance if the PDP would give priority to a 
> non-matching target.
> I propose therefore that to improve consistency and performance, we 
> change the <Target> matching specification in 3.0 so that a 
> non-matching child in a <Target> has priority over an Indeterminate 
> child.
> Best regards,
> Erik
> ---------------------------------------------------------------------
> 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]