Next in thread →
Next in month →
RE: [xacml] Combining algorithm combining orders
All
I
agree that 2.0 should be left alone. Think that anything u do in 2.0 will also
need to be corrected at the ITU.
cheers
From: Rich.Levinson
[mailto:]
Sent: Thursday, October 30, 2008
12:46 AM
To: Erik Rissanen
Cc: xacml
Subject: Re:
[xacml] Combining algorithm combining orders
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:
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.
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.
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.
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".
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.
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).
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.
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.
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.
(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.
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" <>
Date: Sun, 26 Oct 2008 04:25:31 To: Erik Rissanen<>
Cc:
XACML TC<>
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
Next in thread →
Next in month →