Hi Erik,
Thanks for the detailed response. I think we are pretty much on the
same wavelength and it is just a matter of identifying the key details
and how to represent them in 2.0 and 3.0 (w no intent to change
anything in 2.0 except possibly combining algorithm details if they are
found to be inconsistent with what we perceive to be intended).
Responses inline: (Note: I am still not 100% sure of the logic I am
suggesting (i.e. I may be missing something), but am offering it as
analysis, which appears to me at least to yield a possible
simplification, which appears to remove the problem of Permits being
converted into Denys, plus fairly simply also removes the need for
separate rule and policy combining algorithms.)
Erik Rissanen wrote:
490886C9.6030003@axiomatics.com" type="cite">Rich,
All,
It's a very interesting discussion you have here with some good
thoughts, but there are some things that I don't agree with.
It's a long thread, so it's a bit hard to make responses, so I will
just write up my comments here, in the hope that everybody can figure
out what I mean. :-)
1. You say that we don't need all of the levels PolicySet, Policy and
Rule. I kind of agree. I have thought the same thing before. I don't
see the need to differentiate between PolicySet and Policy. A Rule on
the other hand is something entirely different, and should be distinct.
(When you say that a Rule and Policy need not be separated, you are at
the same time modifying the Policy to contain an Effect, essentially
making it what a Rule is today.)
Actually, all I am saying is that conceptually, based on the Effects of
the Rules that a Policy contains that a Policy may or may not have a
defined Effect. If all the Rules within a Policy are Deny, then the
Policy cannot possibly produce a Permit, and vice versa. I am also
saying that when the Policy processes the Rules it can keep track of
the Effects and determine if it effectively has a Permit or Deny or no
Effect. Then a PolicySet, with its policy combining algorithm can apply
the same type of logic: i.e. if a Policy evaluates to Indeterminate, it
can easily within the rule combining algorithm have retained the fact
whether all the rules had the same Effect or not, and, if so, which
value the Effect would have.
What happens with the current combining algorithms is that in the rule
combining deny overrides there is a built-in unbiased choice being made
which passes up ambiguity which results in the PolicySet that is
delivered this rule combining result is unable to determine whether or
not the Policy could have possibly returned a Deny or not.
That is an observation, not intended to say whether the algorithm is
right or wrong, just that it appears to be unnecessarily removing
information that might have been useful.
The other obvious choice is to return a Deny, which is what I
suggested, which is what I would call a "deny-biased deny overrides"
rule combining algorithm. i.e. it would return deny if it found a deny
could possibly be returned. This might be slightly less ambiguous than
unbiased version, but also has the disadvantage of introducing
ambiguity into whether the Deny was real or potential.
Actually, given the asserted objective of the algorithm, I think both
choices are bad and that a better choice is to calculate whether there
is a game changer in the Indeterminates. This way the rule combining
algorithm would return one of the following:
- Permit
- Deny
- Indeterminate + (calculatedEffect = Permit, Deny, or None)
- NotApplicable
where the "calculatedEffect" is just an indicator as to whether all the
applicable Rules were Permit or all Deny or a mix in which case the
Policy has no implicit Effect.
I believe this slight change would have two results:
- It would remove the distinction between rule combining and policy
combining because both types of algorithm would now process definitive
Deny's and Permits plus have a possible modifier indicating the
character of an Indeterminate result that might have been obtained.
- With that distinction removed, the PolicySet and Policy no longer
need to be distinct either.
I think the net effect would be that the Indeterminates could be cut
off at whatever level desired by simply inserting a "biased" combining
algorithm wherever it was deemed to be needed.You could put it in the
top level policy set and have a flag as to whether you had a biased PDP
or not, and if not, pass it on up and leave the choice to the PEPs.
But I think the net effect is that we could have a uniform structure of
PolicySets containing Rules and PolicySets, just like a file system has
directories that contains directories and files. Each PolicySet would
have a "combining algorithm", which could be either a biased or
un-biased flavor.
For 2.0 we simply could define rule combining algorithms that return a
calculatedEffect along with the result. For a biased algorithm, the
calculatedEffect would be irrelevant since it is already embodied in
the result, and for an unbiased algorithm it passes up the potentially
useful information that the Policy could have produced only one
possible Effect.
490886C9.6030003@axiomatics.com" type="cite">
However, I don't think this is important enough to motivate a change
which complicates compatibility between 2.0 and 3.0.
2. In your first email you suggest that the rule combining algorithm
should be changed (around the test for a "potential deny"). I don't
agree. It's the policy combining algorithm which is wrong, the rule
combining algorithm is right and by changing it you would introduce the
same kind of error in the rule combining algorithm as well.
I believe this was answered above - basically the point I was making
there was that by making the rule combining biased, that the policy
combining would no longer be in a position to turn Permits into Deny
because potential Denys would be pre-resolved and that if the policy
combining had the calculatedPolicyEffect then it would be able to make
its own decision in the unbiased case. Basically, at that point I was
concerned with the fact that information was being screened out of the
policy combining which caused it to be in the position you originally
characterized of one where it reversed a Permit rule into a Deny. As
indicated above, I think there are no "good" choices if you don't
return the calculatedEffect. Either choice removes information, causing
policy combining to be dealing with ambiguous results.
490886C9.6030003@axiomatics.com" type="cite">
3. You say that policies should be constrained by an Effect. I don't
agree with this. Policies/PolicySets are not the leaf nodes in the
policy tree, where the effect should be. Policy/PolicySet is for
combining results from lower levels. This is completely right.
I didn't say the policies "should be constrained by an Effect". I said
that policies could calculate an Effect, which policy combining could
use or not depending on the algorithm. Again the only "Effect" a Policy
would have is "Permit" if all the applicable Rules were Permits, i.e.
similar to a single Rule with Effect of Permit in a Policy should not
be able to produce a Deny, I think one can argue that a collection of
Rules, all whose Effects are Permit, should not be able to produce a
Deny either. That is the only meaning to this calculatedPolicyEffect
that I am considering.
490886C9.6030003@axiomatics.com" type="cite">
Instead, what you are kind of approaching here is something similar to
what Olav Bandmann did at SICS when we did some formal
analysis/modeling of XACML.
He suggested to me that the concept of Indeterminate could be extended
to include a set of "potential results". Currently an Inderminate means
"There was an error, and it could have been a Deny, Permit or NA".
Instead, we could extend Indeterminate so it also includes a more fine
grained set of potential results. For instance, if a rule with
Effect=Permit is evaluated to Indeterminate, we know that it could
never have been a Deny, so we could say that the result is Indet{P/NA},
meaning that "there was an error, and it could have been eitther a
Permit or a NA". There are two other possible versions of Indeterminate
in this model: Indet{D/NA} and Indet{P/D/NA}. Under the old rules,
every Indeterminate is equivalent to an Indet{P/D/NA}. (It's this model
Olav used to analyze the current algorithms, and that was when he found
the errors we are currently debating.)
I believe that the "calculatedEffect" I describe above serves this same
function. It is simply a byproduct of rule processing that can be
factored into policy combining algorithmically rather than defining
different classes of "Indeterminate".
490886C9.6030003@axiomatics.com" type="cite">
Now, if a deny overrides combining algorithm would have to combine a
Permit and a Indet{P/NA}, it could see that the indeterminate could
never be Deny, so it can safely return a Permit, despite the error.
I think Rich you were looking for something similar. But it's the
Indeterminate result which needs to be extended with the effect, not
the Policy.
Under this extended model, the extended set of the Indeterminate could
be something entirely internal to the PDP, just for the combining
algorithms to use, or it could also be exposed to the outside the
response.
Anyway, Olav made the suggestion a couple of years ago, but I never
posted it to the list since we both thought it would be too
controversial to be accepted by the TC.
It is interesting to note that the rule combining algorithms already
work like this. That's what the "potential-deny/permit" tests do in
effect. If this analysis would have been followed also on the policy
combining algorithms, they would not have been made the way they are
today.
I pretty much agree with all this. What I think happens with the
current structure is that by removing the notion of "Effect" at the
policy combining level, that we are introducing unnecessary complexity
conceptually which results in all kinds of strange behavior such as the
Permit becoming Deny that you originally described. By simply retaining
the "notion" of "Effect" we are able to have uniform logic in the
combining algorithms, which preserves information of a consistent
character that is currently being thrown away plus removes the need to
have distinct policy or rule combining algorithms.
490886C9.6030003@axiomatics.com" type="cite">
I guess that the reason the policy combining algorithms are wrong is
the use case you are talking about Rich: sometimes policy authors want
to specify in their policy that indeterminates should not be propagated
upwards. To handle this, the end result in the design became the
current algorithms. (I am just speculating here, I wasn't a member of
the TC back then, so I don't know.)
Sure, I agree that sometimes it is useful to not propagate errors, but
in many (most?) cases it is not. We need to separate these two use
cases into two different algorithms.
I agree. I think this is the notion of biased (consumes errors) vs
unbiased (propagates errors).
490886C9.6030003@axiomatics.com" type="cite">
So I propose that:
A. For 2.0 we change nothing. This is is too big to be errata.
I agree 2.0 should be left alone.
490886C9.6030003@axiomatics.com" type="cite">
B. For 3.0 we change the behavior of the currently defined
permit/deny-overrides algorithms so that they always propagate
Indeterminates upwards. (We do not change the identifiers.)
This I would consider the "unbiased" set of algorithms, which, if they
do not include a calculatedPolicyEffect, remove the fact of
potentialDeny or potentialPermit that might have been encountered.
490886C9.6030003@axiomatics.com" type="cite">
C. For 3.0 we introduce new combining algorithms
"permit-overrides-indeterminate" and "deny-overrides-indeterminate",
which never propagate an Indeterminate upwards, rather they will
default to Permit/Deny in case of an error.
This I would consider to be the "biased" set of algorithms, which,
regardless of whether they retain a calculatedPolicyEffect remove the
information as to whether the Deny or Permit being reported was
potential or real.
490886C9.6030003@axiomatics.com" type="cite">
(I think the concept of extended Indeterminate is a bit complex, and I
am not sure if it's really worth so much, so I do not propose that we
introduce it.)
I believe the "calculatedPolicyEffect" very cheaply produces the same
information as the "extended Indeterminate" and would remove the need
to have separate rule and policy combining algorithms which I believe
have the effect of removing information causing unnecessary ambiguity
at the policy combining level.
490886C9.6030003@axiomatics.com" type="cite">
Best regards,
Erik
Rich.Levinson wrote:
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
---------------------------------------------------------------------
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
|