RE: [xacml] Re: Policy equivalence [was: The Indeterminate flavors question]

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Thursday, May 05, 2011 03:09
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Re: Policy equivalence [was: The Indeterminate
> flavors question]
> 
> Hi,
> 
> (Tried to post this earlier, but there was an outage in the OASIS
email
> servers it seems.)
> 
> Maybe, but it also goes against current concepts in XACML and is not
> that easy to define.
> 
> - It puts restrictions on combining algorithms. For instance the
> permit-unless-deny and deny-unless-permit algorithms would be
> disallowed.

I think it makes these algorithms behave consistently with their current
definition, which lead one to believe that they should never return
Indeterminate or NotApplicable from the *policy* or *policyset*.  As
Erik interprets these algorithms, they apply only to the contained rules
(or policies/policysets), and not to the entire Policy or PolicySet
element they are attached to (including any immediate Target).  This may
be a legitimate interpretation--it just isn't clear in the spec, and
makes these algorithms useless for implementing a rigid decision bias in
a policyset.

> 
> - I haven't thought it through properly, but I suspect that of the
four
> possible decisions, we can make only one decision "linear". So, if we
> for instance make Indeterminate linear, then NotApplicable cannot be
so
> because at any given level the conflict between a notapplicable and
> indeterminate has to be resolved. If there is a target T1 which causes
> Indeterminate and a target T2 which causes NotApplicable, depending on
> which one we push down in the equivalent policy, assuming we push down
> only one of them, we could get different results since given any
single
> definition of priority, only one of them can truly become linear. So
> linearity probably is not possible to achieve. (If I got this
right...)

This is a research opportunity, to see whether a well-defined
transformation of Targets to Conditions (see below) will actually cause
this sort of ambiguity in any type of policy.  And if there is such a
possibility, I would suspect that our definition of policy evaluation is
at fault, and should be revised to ensure consistency.

> 
> - The equivalency conditions are not that simple since the order of
> expressions in the equivalent policies matter, so we would need to be
> very careful about this. For instance, a condition with an AND
> expression short circuits, so we must take care to join the pushed
down
> conditional expressions properly in relation to everything else which
> exists or is pushed down. Can probably be done, but not very simple,
> which raises the following question:

Order of evaluation should be a processing convenience only, not a cause
of different results.  I believe the current policy evaluation
specification, with its implied order of evaluation, is somewhat
accidental and is not consistent with a purely logical evaluation of the
Boolean schema represented by a policy.

> 
> - What specifically is the proposal on the table and for what benefit?
> Is the proposal that we define some transformation in the spec? For
> what
> purpose? Is it that we require certain meta conditions on combining
> algorithms so some transformation supposedly holds? Which
> transformation
> is this and what are the conditions on the algorithms?

Using XACML 3.0 syntax and pseudo-xslt, here is the intended
transformation, which is irrespective of combining algorithms:

======== Policy equivalence algorithm =============
Target -> Apply[@FunctionId='and'].
AnyOf -> Apply[@FunctionId='or']
AllOf -> Apply[@FunctionId='and']
Match -> Apply[@FunctionId='any-of'], with children:
	Function[@FunctionId=current()/@MatchId]
	AttributeValue -> copy Match/AttributeValue
	AttributeDesignator -> copy Match/AttributeDesignator

Replace the existing Target element with an empty Target, then for each
descendent Rule element:

If there is a Condition element, then replace existing Condition/*
element with Apply[@FunctionId='and'] and use existing Condition/*
element as first child and the generated Apply element as 2nd child.

If no Condition, add a Condition element with the generated Apply
element as child.
======== End of Policy equivalence algorithm ========

I believe AttributeSelector could be handled in the same manner as
AttributeDesignator, but I don't have enough experience to say for sure.

My lemma is that all policies transformed in this way should evaluate to
the same decision as the original policy (given the same request
context).  And if not, there is a defect in the policy evaluation
specification.

Regards,
--Paul