Re: [xacml] Groups - xacml-3.0-combalgs-v1.0-wd02.doc uploaded

[Steven Legg <steven.legg@viewds.com>]

Hi Erik,

On 23/08/2012 7:02 PM, Erik Rissanen wrote:
> Hi Steven,
>
> I made it as restrictive as possible intentionally. I targeted only the refactoring of the policy condition.
> So that is why I restricted the use of Deny.

Letting a Deny from the first policy translate into NotApplicable for
the on-permit-apply-second combining rule doesn't hurt your original
use case, so I don't see the point in intentionally making the rule
unusable for other use cases that you haven't thought of yet. I've
toyed with the idea of an Unpermit effect; something to override a
Permit effect without necessarily inducing a Deny result. The
on-permit-apply-second combining rule could do that if a Deny from
the first policy translates into NotApplicable. If can see a use for
that in allowing Deny rules to be introduced into Permission Policy
Sets for Hierarchical RBAC. If the PPS is wrapped in a policy set
with the on-permit-apply-second combining rule, then the PPS can still
be considered to describe only positive entitlements that are added,
as expected by the NIST RBAC specification. The effect of a Deny rule
in a PPS could never leak out to mess with other positive entitlements
from other PPSs or non-RBAC policy sets.

Translating Deny into NotApplicable is also consistent with other cases
in XACML of recursive policy evaluation in order to obtain a boolean
result. A Deny during reduction doesn't cause an Indeterminate result;
it means that an untrusted policy isn't authorized. A Deny result from
evaluating the access-permitted function doesn't cause an Indeterminate
result; it means that access isn't permitted. The RBAC profile doesn't
say, but I presume a Deny result for a Role Enablement request doesn't
cause an Indeterminate result; it means the role is not enabled.

> Regarding the indeterminate result from the first policy, I split it up like that to change the status code.
> I don't remember right now why I did that. I think it was because I wanted to be strict about the first
> policy doing only Permit or N/A.
>
> But, yes, it might make sense to keep the original status code, since if one thinks about refactoring the
> policy condition, then if one would have had the condition actually in a policy, then it would have passed
> up an indeterminate with that original status code.

That's how I was looking at it.

Also note that the core specification doesn't have anything to say about
how Indeterminate status codes should be combined, thus leaving it as
implementation-defined. The on-permit-apply-second doesn't need to be
prescriptive on this either. It can be left to the discretion of the
implementor as with the other combining rules.

However, there is one exceptional case with the on-permit-apply-second
combining rule. If the first policy evaluates to Deny, then an
Indeterminate status code has to be associated with decision0 for the
cases where decision0 has to be combined (in the implementation-defined
manner) with an Indeterminate decision1. Of course, if Deny translates
into NotApplicable, then this situation doesn't arise.

> Regarding the two forms, since conditions are not allowed directly in policies, there is no defined
> requirement in which order the target vs the condition should be evaluated.

But there is a precedent from rules. If conditions really were being added
to policies and policy sets it would most likely follow that precedent.
Your ideal policy is suggestive of following that precedent in that you
have put the Target before the Condition. It looks like the ideal policy
and the actual policy set are using different orderings.

> Which one is more efficient
> would depend on the implementation or the particulars of the specific policy. So it's pretty much an
> arbitrary choice which one to do.

Except if Policy Set X is inside a policy set using the only-one-applicable
combining rule.

On efficiency, I was thinking more in terms of whether the PDP has to look
at the policies at all. The separation of targets and conditions is supposed
to facilitate indexing. Policy A could be simply indexed on its Target.
Effective indexing of Policy Set X needs something more sophisticated since
it has an empty Target. Of course, mileage will vary between implementations.

Regards,
Steven

> And the only impact it has is whether both the target and the condition
> would be indeterminate, then the order would determine which status code to use.
>
> Best regards,
> Erik
>
>
> On 2012-08-23 06:48, Steven Legg wrote:
> > Hi Erik,
> >
> > I have some comments on the Additional Combining Algorithms draft.
> >
> > In the pseudo-code in section 2.1, the last four "if" statements, i.e.:
> >
> >   if (decision1 == Indeterminate{P}) {
> >     // Use status code urn:oasis:names:tc:xacml:1.0:status:processing-error
> >     return Indeterminate{P};
> >   }
> >   if (decision1 == Indeterminate{D}) {
> >     // Use status code urn:oasis:names:tc:xacml:1.0:status:processing-error
> >     return Indeterminate{D};
> >   }
> >   if (decision1 == Indeterminate{DP}) {
> >     // Use status code urn:oasis:names:tc:xacml:1.0:status:processing-error
> >     return Indeterminate{DP};
> >   }
> >   if (decision1 == NotApplicable) {
> >     return NotApplicable;
> >   }
> >
> > can be simplified to this:
> >
> >   if (decision1 == NotApplicable) {
> >     return NotApplicable;
> >   }
> >   // Use status code urn:oasis:names:tc:xacml:1.0:status:processing-error
> >   return decision1;
> >
> > I'm not so sure the pseudo-code should be specifying the status code to return.
> > If the first policy evaluates to indeterminate because of a missing attribute,
> > then it would be very useful for that to carry through rather than being
> > overturned by this combining rule.
> >
> > As currently specified, the on-permit-apply-second combining rule is treating
> > a Deny decision from the first policy as equivalent to Indeterminate. Policy
> > writers would have more flexibility in how they structure the first policy if
> > Deny (and Indeterminate{D}) were treated the same as NotApplicable, i.e., that
> > the "condition" is not satisfied. For example, the first policy could contain
> > a Deny rule with a positive target instead of an equivalent "not" expression
> > in a condition in a Permit rule.
> >
> > Section 2.2 describes this refactored policy:
> >
> >     PolicySet X [on-permit-apply-second]
> >       Policy Y
> >         Rule Z [Permit]
> >           Condition A
> >       Policy A:
> >         Target A
> >         Rules of A...
> >
> > which is not equivalent to the ideal policy because it puts the condition
> > evaluation before the target evaluation. It should be this:
> >
> >     PolicySet X [on-permit-apply-second]
> >       Target A
> >       Policy Y
> >         Rule Z [Permit]
> >           Condition A
> >       Policy A:
> >         Rules of A...
> >
> > This arrangement is more faithful to the ideal, as well as being more efficient,
> > and more appropriate if, for example, PolicySet X were contained in a policy set
> > using the only-one-applicable combining rule.
> >
> > By the way, I won't be on the conference call to discuss this because it starts
> > at 3:00 AM my time.
> >
> > Regards,
> > Steven