[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**

*From*:**Erik Rissanen <erik@axiomatics.com>***To*: "xacml@lists.oasis-open.org" <xacml@lists.oasis-open.org>*Date*: Thu, 20 Jun 2013 13:37:49 +0200

All,

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

However, I don't think that it's a problem. Consider this: Policy Target ... some rules ...

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

Look at this case: PolicySet [deny-overrides] Policy A -> Indeterminate{?} Policy B -> Permit

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" incase 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 istested for in the condition. The author would assume that the policyset Xis not evaluated if the condition is false.However, in WD 03 of the profile, if Policy A (with the condition)returnsan 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 situationwhere 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 behaveincorrectly.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 wouldmeanthat to discover the flavor of Indeterminate, one would evaluate bothchildren and then use a flavor depending on the result. Also, when thetwochildren agree on the decision, then one could even make a defineddecisioneven 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 conditionholds,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 dangeroussincethe wrong flavor of Indeterminate could influence a nesting combiningalgorithmto 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 thereis no way the second child should be evaluated, regardless of theerror. SoI kept that case as it was.One more thing: when I thought about this algorithm, I realized thatwe havea similar issue with plain 3.0 targets. In sections 7.12 through 7.14the spectells 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 andlet thePolicy/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

**References**:**New combining algorithms profile and a potential issue in 3.0 core spec***From:*Erik Rissanen <erik@axiomatics.com>

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