Re: [xacml] Combining algorithm combining orders

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Daniel,

I do not understand your objection. My suggestion removes nothing from the existing logic in terms distinguishing between effect and decision. In fact, it adds the ability to determine effect at the policy level as well, which the current algorithms do not include which results in the ambiguous and contrary results as described by Erik in his original email:
http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
where a Rule with Effect="Permit" results in a parent Policy with decision = "Deny".

If you follow the logic I described in detail, especially in the 3rd email (although it also exists in the first two as well):
http://lists.oasis-open.org/archives/xacml/200810/msg00044.html
I think you will find it to be the case that current effect logic is preserved, as well as all distinctions between errors and results.

The main point is to define what "Effect" really means, which is that the contained logic can produce one and only one of the decision types: i.e. either Permit or Deny, but not both (obviously not "both" at the same time, but "both" in the sense that until evaluation it is not determisitic which can be produced, which becomes the case when multiple Rules are present within a Policy that have different "Effects".). Once characterized in this manner, it is straight-forward to carry it up along with rest of the combining information.

    Thanks,
    Rich



Daniel Engovatov wrote:

I disagree with this assessment. I think it was important to separate the ability to explicitly handle errors from results. So effect and decision are distinct on purpose. 

What we really need is a normative and portable way to define and exchange combining policies. 

Daniel. 
-----Original Message-----
From: "Rich.Levinson" <rich.levinson@oracle.com>

Date: Sun, 26 Oct 2008 04:25:31 
To: Erik Rissanen<erik@axiomatics.com>
Cc: XACML TC<xacml@lists.oasis-open.org>
Subject: Re: [xacml] Combining algorithm combining orders


Hi All,

While there are probably some details in the previous email that need to 
be cleaned up, I think that it identifies a basic problem that needs to 
be addressed.

As indicated, Erik came up with a single rule policy where the rule had 
an effect of permit, and yet the policy that wrapped it effectively 
produced a deny at a higher level.

I believe the root cause of this problem is that the concept of 
"Effect", and its implementation in the current  XACML specs is 
fundamentally flawed and needs to be addressed.

Again, with Erik's use case, the flaw is obvious: a Rule with an Effect 
of Permit results in a Policy that causes a Deny. The flaw is that the 
concept of Effect is not handled properly. "Effect" effectively means 
that the block of logic contained within this element can ONLY produce 
either a Deny or a Permit, but not both. On the other hand, because a 
Policy does not have an Effect, it implicitly can produce either a Deny 
or a Permit. Therefore, to preserve the notion of "Effect", we have to 
include it also at the Policy level, with the following constraints: The 
Effect of a Policy must equal the "AND" of the Effects of all of its 
Rules. Therefore if a Policy has only Rules that are Permits, then the 
Effect of the Policy is Permit. If the Policy has Rules with both a 
Permit and Deny, then the Policy effectively has no "Effect" because the 
meaning of "Effect" is that only one type of decision is possible, and 
now the Policy can produce two types of decisions.

Therefore, I think my basic conclusions in prev email are correct about 
converging Policy and Rule into a single element - i.e. the only thing 
that distinguishes the Rule and single Rule Policy is the fact that the 
Rule has an Effect and the Policy doesn't, which has been shown above to 
be wrong and correctable by giving the Policy an Effect attribute, which 
effectively removes the distinction between Policy and Rule.

Comments and suggestions will be much appreciated.

    Thanks,
    Rich


Rich.Levinson wrote:
  

Hi Erik and TC,

As indicated at today's meeting, I have concerns about the proposed 
changes. I have read this email from Erik fairly carefully, as well as 
the first part of the cited reference:
http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
and I also started to follow the thread initiated by Daniel:
http://lists.oasis-open.org/archives/xacml/200810/msg00027.html

In the first cited reference, Erik states:
   "P1 has a singe rule with a Permit effect."
then goes on about how this Rule gets propagated up and effectively 
turns into a Deny under the deny-overrides algorithm.

I agree that this appears incorrect, and went to look for the source 
of that problem.What I found was that it appears this problem results 
from what appears to me to be an error in the deny-overrides *rule 
*combining algorithm, which has what I believe is an incorrect piece 
of logic on lines 5181-5184 of the XACML 2.0 core spec, p 133:

   5181     if (potentialDeny)
   5182     {
   5183         return Indeterminate;
   5184     }

It is my opinion the line 5183 should say "return Deny", because it is 
at this point that the "potentialDeny" condition that the algorithm 
goes to the trouble to find, now throws away, which ends up creating 
the situation where a rule with effect = Permit can produce a Deny at 
the policy combining level.

I also read Daniel's comment up to the point where he said:
   "Just throwing an exception all the way to the client is what we 
have tried to avoid.",
with which I agree. I expect that many policy administrators will want 
definitive results to come out of the PDP, and not any "Indeterminates".

So, my first suggestion would be to fix what I consider to be an error 
on line 5183 described above. The practical reason why I consider this 
an error is that if there is insufficient information to evaluate a 
rule that has an effect = Deny, then, I believe it is legitimate to 
define a rule combining algorithm that says that rule should return 
the effect = Deny so that one cannot remove input attributes in the 
hopes of reversing a decision. One could also define a companion 
combining algorithm the evaluated to Indeterminate in order to provide 
that option for those who want it. This way a policy administrator 
could choose on a case by case basis which behavior is preferable 
based on specific situations.

My second suggestion is more broad-based, and, in fact, I think we 
should consider for 3.0 if there is some agreement. I am not expecting 
what follows to be bought hook line and sinker at first glance, but I 
do think it is worth consideration, especially since we are already 
making a major paradigm shift with the category-based attributes that 
are defined in 3.0, that effectively adds a new "dimension" to the 
domain of attributes, which I believe is a desirable step forward from 
the Subject,Resource,Action,Environment-based attributes of 2.0, which 
based on previous discussions about the what appear to me as ambiguous 
and unnecessary semantic restrictions on the Action attribute 
"category". Personally, I would recommend in section B.6 of 3.0 that 
the action attributes be defined within a given "resource" category, 
as I believe that actions are attributes of resources and do not have 
any meaningful definition outside of a resource context. However, that 
is just a minor aspect of the overall suggestion I have related to the 
combining algorithms.

The main suggestion about combining-algorithms is that I believe, but 
have not definitively proven yet, that there is an unnecessary layer 
of combining with two types of rule and policy combining that exists 
in 2.0. One easy way to see that this might be true is to do the 
following thought experiment:

  1. Wrap every "Rule" within a Policy element, which effectively turns
     every policy into a single rule policy. However, if we do this,
     then we lose the "Effect" behavior of the Rule, therefore
  2. Move the Effect attribute up to the Policy level. Therefore, each
     single Rule Policy now also preserves the Effect.
  3. Clearly all multi-rule Policies must now become PolicySets, and
     the policy-combining algorithm must be replaced by the logic of
     the rule combining algorithm to take into account the Effect of
     the Policies.
  4. We are now left with a collection of single rule Policies (with an
     effect) and PolicySets that have no effect since it was factored
     out in step 3. This is where it gets "fuzzy", but I suspect that
     we might be able to show that we can still use the rule combining
     algorithms on a mix of entities some of which have an effect and
     some which don't. I suspect that for example on lines 5174-5177
     that we can just skip this block if the entity being tested is a
     PolicySet, and execute it if the entity is a Policy. If so, then I
     think we are done and have factored the distinction between
     rule-combining and policy-combining out of the structure.

If the above logic is correct, and we can reduce the structure to be 
simply Policies with an effect and PolicySets with no effect, and 
allow the combining algorithms to only use the "effect" segments on 
the objects that contain an effect, then I think we reduce the 
complexity of the syntax (either no longer have "Rule"s or no longer 
have "Policy"s) at the cost of only what appears to me to be a tiny 
increase in the complexity of the rule-combining syntax (which is to 
effectively allow for rules that have no effect and simply bypass the 
effect logic).

Bottom line is that I am offering this as a potential suggestion. 
Because the logic to analyze it is fairly complex, I allow for the 
fact that maybe I have missed something essential. However, since we 
are making some fairly broad changes in 3.0, I am offering this as a 
potential "simplification". At the very least, I am looking to find 
what I might be missing that would prevent this "simplification".

   Thanks,
   Rich







Erik Rissanen wrote:
    

All,

In my opinion the both the deny overrides and permit overrides policy 
combining algorithms are wrong. They treat errors in an incorrect and 
unsecure manner. The corresponding rule combining algorithms are 
correct, and the policy combining algorithms should work in a similar 
manner.

The Indeterminate result in XACML is used in those places where the 
result of some part of the policy cannot be determined because of 
some form of error. It is important that if such an indeterminate 
result affects the final decision of the PDP, that the indeterminate 
is returned to the PEP so that the PEP knows that there is an error. 
If so is not done, errors in policies might not be noticed or an 
attacker might be able to force the PEP into some bad action by 
causing errors in the PDP (for instance by interrupting attribute 
provisioning services).

If we want to determine whether an Indeterminate should affect a 
result, we can consider the indeterminate to be a result which 
potentially could be either Permit, Deny or NotApplicable and for 
each of them see what the overall result would be. If the overall 
result depends on which choice we make for the Indeterminate, then 
the Indeterminate should be propagated "further up" in the policy 
evaluation. (If you don't understand what I mean, just read on, I 
will provide examples.)

Currently the permit overrides policy combining algorithm works like 
this (using the updated textual description):

1.    If any policy evaluates to "Permit", the result is "Permit".
2.    Otherwise, if any policy evaluates to "Deny", the result is 
"Deny".
3.    Otherwise, if any policy evaluates to "Indeterminate", the 
result is "Indeterminate".
4.    Otherwise, the result is "NotApplicable".

Notice how a deny goes before indeterminate. That is a bad priority. 
Consider a policy set with two policies A and B. Assume that A is 
deny and B is indeterminate. Consider what the overall result could 
be if policy B would not have an error in it:

A: Deny
B: could be Deny
-> overall would be Deny

A: Deny
B: could be NotApplicable
-> overall would be Deny

A: Deny
B: could be Permit
-> overall would be Permit

Notice how the result depends on what the indeterminate could 
potentially be. However the current definition gives a definite Deny 
in all cases. This breaks the error propagation safety of the 
combining algorithm. In some applications availability could be 
critical, and a PEP might have a bias that indeterminate means that 
access is allowed. In such a case harm could be caused by this behavior.


Now consider the deny overrides instead. Currently the deny overrides 
policy combining algorithm works like this (using the updated textual 
description):

1.    If any policy evaluates to "Deny", the result is "Deny".
2.    Otherwise, if any policy evaluates to "Indeterminate", the 
result is "Deny".
3.    Otherwise, if any policy evaluates to "Permit", the result is 
"Permit".
4.    Otherwise, the result is "NotApplicable".

Note how an indeterminate is converted to a Deny. This gives the 
following behavior.

A: Permit
B: could be Deny
-> overall would be Deny

A: Permit
B: could be NotApplicable
-> overall would be Permit

A: Permit
B: could be Permit
-> overall would be Permit

Again, there is a definite result from the combining algorithm 
although the underlaying logic is ambiguous.

As I said we have discussed this previously. The threads are here:

http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
http://lists.oasis-open.org/archives/xacml/200702/msg00019.html

I propose that we define new identifiers for new combining algorithms 
for 3.0 which work like this:

Deny overrides:
1.    If any policy evaluates to "Deny", the result is "Deny".
2.    Otherwise, if any policy evaluates to "Indeterminate", the 
result is "Indeterminate".
3.    Otherwise, if any policy evaluates to "Permit", the result is 
"Permit".
4.    Otherwise, the result is "NotApplicable".

Permit overrides:
1.    If any policy evaluates to "Permit", the result is "Permit".
2.    Otherwise, if any policy evaluates to "Indeterminate", the 
result is "Indeterminate".
3.    Otherwise, if any policy evaluates to "Deny", the result is 
"Deny".
4.    Otherwise, the result is "NotApplicable".

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
      

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