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: New combining algorithms profile and a potential issue in 3.0 core spec


All,

I have thought a bit more about the target issue I mentioned at the end, and actually, I don't think there is a problem.

Let me explain how I was thinking and how I (now) think I was mistaken.

The problem is that if a target is Indeterminate, then according to sections 7.12 through 7.14 in the spec, the children are evaluated. The purpose of this is to figure out what the policy would have evaluated to if the target would have matched, so we can figure out the flavor of the Indeterminate.

So, say that the target fails, but the content of the policy would have been Permit, then we know that the result of the policy as a whole would be Indeterminate{P}.

The problem is that it might not be safe the evaluate the policy contents if the target is not known to match since there may be assumptions which were made when authoring the policy contents. Those assumptions might be violated and the contents may malfunction.

However, I don't think that it's a problem.

Consider this:

Policy
  Target
  ... some rules ...

If the target becomes Indeterminate, then we know the result is Indeterminate, but we want to figure out the flavor of Indeterminate. So we could express it so that at this point we know that the result is Indeterminate{?}, where the question marks stands for that we don't know which flavor of Indeterminate we should use.

To figure that out, the spec says to evaluate the contents. Depending on the results, we will choose the flavor. For instance, if the contents said Permit, then the result is Indeterminate{P}.

What worried me is that because the target is not known to be a match, the contents of the policy might not work out as intended. So we can return the wrong flavor of Indeterminate.

However, I don't think that is a problem.

Say that if there would not have been an error in the target evaluation, then the target should have matched. In that case the contents are expected to work fine, and we don't have an issue to worry about. The right flavor will be used.

Instead, say that the target should not have matched. In that case the flavor of Indeterminate could be wrong, but it is still an Indeterminate, so anything using that Indeterminate further is going to consider that there is the possibility that the policy could have been N/A entirely. That would in fact be the right assumption in this case. Since that assumption is in play, and assuming that any combining algorithm using the result is correct, that possibility will be taken into account and there should not be any results which are inconsistent with the policy actually being N/A, which is correct.

What can happen though is that an Indeterminate is created where one is not needed.

Look at this case:

PolicySet [deny-overrides]
  Policy A -> Indeterminate{?}
  Policy B -> Permit

Say that Policy A has a target which is Indeterminate. The real situation is that this policy should not have matched and should be N/A. This means that the Indeterminate{?} could end up being the wrong flavor.

However, the worst that can happen here, because the combining algorithm of the policy set is correct, is that if an Indeterminate{D} is incorrectly returned from Policy A, which makes the PolicySet Indeterminate{DP}, although it actually could have safely said Permit. (Since the true value of Policy A should be N/A).

So, nothing to worry about then and no need for an errata. :-)

Best regards,
Erik


On 2013-06-19 10:14, Erik Rissanen wrote:
All,

I have uploaded a new working draft of the combining algorithms profile.

I have generalized the on-permit-apply-second algorithm so it can take
a third child which is applied in case the first child ("the condition")
returns N/A or Deny. This is the if-then-else feature which we discussed
earlier on the list.

I also made some other changes to the algorithm. It used to be "clever" in
case of different flavors of Indeterminate. But I realized that doing so
is dangerous and undesirable for this algorithm, so I simplified
the error handling. Let me explain why.

The purpose of this algorithm is to allow using conditions in policies.
For instance, someone could write a policy like this:

PolicySet Y [on-permit-apply-second]
  Policy A, Rule, Condition: the subject has an account in corporate LDAP
  PolicySet X
    ... policies which apply to these subjects ...

Now, when the PolicySet X is authored, it is likely to be done with the
assumption that the user has an ldap account, since this is what is
tested for in the condition. The author would assume that the policy set X
is not evaluated if the condition is false.

However, in WD 03 of the profile, if Policy A (with the condition) returns
an Indeterminate{P} or Indeterminate{DP}, the policy set X is evaluated
anyway to determine the flawor of Indeterminate which should be
returned as a whole for policy set Y.

But since the policy A was indeterminate, we don't really know whether
the condition is true or not, so we might in fact be in a situation
where we violate the assumptions which were made when X was authored. That is,
in this case, the user might not have an account in ldap.

That in turn means that policy set X may malfunction and behave incorrectly.
That could in WD 03 lead to an incorrect N/A or the wrong flavor of
Indeterminate from the on-permit-apply-second combining algorithm.

The potential generalization of the algorithm to three children would mean
that to discover the flavor of Indeterminate, one would evaluate both
children and then use a flavor depending on the result. Also, when the two children agree on the decision, then one could even make a defined decision
even if the first child (the condition) is Indeterminate. I made a table
which I have attached to the end of this email which lists all the cases.

However, if we consider that if it is not known whether the condition holds,
then we cannot really trust the result of either of the children, so
the values on the left in the table could be seen basically as random,
meaning that an algorithm which tries to be smart can potentially return
_any_ decision randomly.

Do note that already the WD 03 version of the algorithm is dangerous since the wrong flavor of Indeterminate could influence a nesting combining algorithm
to do the wrong thing.

So therefore I did not use smart Indeterminate handling in the combining
algorithm when I generalized and I have removed the smartness from
the case where there are only two children as well. This applies to the
case when the first child is Indeterminate{P} or Indeterminate{DP}.
The case of Indeterminate{D} should be safe since that implies that there
is no way the second child should be evaluated, regardless of the error. So
I kept that case as it was.

One more thing: when I thought about this algorithm, I realized that we have a similar issue with plain 3.0 targets. In sections 7.12 through 7.14 the spec
tells to evaluate the children and combine them in case the target is
Indeterminate. This is to determine the flavor of Indeterminate, but if
target is failing, we don't really know whether the children behave
as intended either.

I think we should do an errata on the core spec because of this and let the
Policy/PolicySet always be Indeterminate{DP} in case of a target which is
Indeterminate.

Best regards,
Erik

Here is the table for choosing a decision among two policies if
it is not known which of the two should be used:

Permit Permit -> Permit
Permit Deny -> Indeterminate{DP}
Permit Indeterminate{P} -> Indeterminate{P}
Permit Indeterminate{D} -> Indeterminate{DP}
Permit Indeterminate{DP} -> Indeterminate{DP}
Permit NotApplicable -> Indeterminate{P}
Deny Permit -> Indeterminate{DP}
Deny Deny -> Deny
Deny Indeterminate{P} -> Indeterminate{DP}
Deny Indeterminate{D} -> Indeterminate{D}
Deny Indeterminate{DP} -> Indeterminate{DP}
Deny NotApplicable -> Indeterminate{D}
Indeterminate{P} Permit -> Indeterminate{P}
Indeterminate{P} Deny -> Indeterminate{DP}
Indeterminate{P} Indeterminate{P} -> Indeterminate{P}
Indeterminate{P} Indeterminate{D} -> Indeterminate{DP}
Indeterminate{P} Indeterminate{DP} -> Indeterminate{DP}
Indeterminate{P} NotApplicable -> Indeterminate{P}
Indeterminate{D} Permit -> Indeterminate{DP}
Indeterminate{D} Deny -> Indeterminate{D}
Indeterminate{D} Indeterminate{P} -> Indeterminate{DP}
Indeterminate{D} Indeterminate{D} -> Indeterminate{D}
Indeterminate{D} Indeterminate{DP} -> Indeterminate{DP}
Indeterminate{D} NotApplicable -> Indeterminate{D}
Indeterminate{DP} Permit -> Indeterminate{DP}
Indeterminate{DP} Deny -> Indeterminate{DP}
Indeterminate{DP} Indeterminate{P} -> Indeterminate{DP}
Indeterminate{DP} Indeterminate{D} -> Indeterminate{DP}
Indeterminate{DP} Indeterminate{DP} -> Indeterminate{DP}
Indeterminate{DP} NotApplicable -> Indeterminate{DP}
NotApplicable Permit -> Indeterminate{P}
NotApplicable Deny -> Indeterminate{D}
NotApplicable Indeterminate{P} -> Indeterminate{P}
NotApplicable Indeterminate{D} -> Indeterminate{D}
NotApplicable Indeterminate{DP} -> Indeterminate{DP}
NotApplicable NotApplicable -> NotApplicable




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