MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] Obligations rear their ugly head.
Polar Humenn wrote:
> And that is a policy of the PEP. Not a mandate from the definition of a
> PDP.
if you do not have consistency of enforcement than consistency of policy makes
little sense. since v1.0 of XACML an obligation has been an optional component
of a decision, NOT an optional component of decision *enforcement*.
> I agree with that approach. However, stating that a "PEP MUST Deny" when
> it encounters an obligation is doesn't "understand", leads to a "provided
> that" scenario, in the case of Permit. In Deny? well it doesn't mean much
> does it.
i think the real issue here is 'Deny' vs. 'DENY'. in reality what we have is an
ERROR condition on the PEP. what i believe the text of the specification intends
to say is 'access by subject to resource is not allowed because this is
considered an error condition' (aka 'deny'). the applied effect is the same but
i can see how there is concern that these 'shorthand' semantics are not clean.
again, let's step back and look at the larger picture: an enforcement device is
not allowed to take action without FULLY understanding its directives; 'non
action' is generally considered a DENY, but i personally have no problem taking
the extra step of having such a scenario more fully expanded so as to explicitly
call this an ERROR condition leaving the [obvious?] conclusion that this will
ultimately prevent the subject from access the resource.
on the other hand, what i don't think is acceptable is the use of SHOULD in the
specification since that has far reaching implications outside of the intended
message because it reduces the *application* of obligations to optional status
because, BY DEFINITION, obligations are a decision directive IF provided.
> Obligations are not Access Control items.
they are in XACML when issued as part of a decision.
> Obligations should be things that need to be carried out by the PEP or its
> delegates. The definition in my mind is more like:
>
> If the PEP allows access on a Permit with Obligation X then it SHOULD
> allow access and carry out Obligation X. If the PEP denies access on a
> Deny with Obligation X, then it SHOULD deny access and carry out
> Obligation X.
fine, but the portion that is missing is: 'however, the PEP MUST understand the
obligations as part of the consumption of the decision'.
> which is what I thought we agreed on a long time ago, to avoid the
> "provided that" syndrome.
my recollection of this is that the decision came down to the concept that the
PEP must have the intention of, and make every effort to, fulfill the obligation
as part of implementing the decision. however, in order to do so it MUST
understand what is being asked of it first.
for example, if the obligation is 'permit, encrypt:3DES' and the PEP doesn't
know what '3DES' is then, the PEP will deny access (in what is for all practical
terms an ERROR condition). note that the *decision* has NOT be changed to DENY,
rather the PEP has denied access based on it inability to understand the decision.
> Obligations should not embody the contra positive of the above statement
> which is "On a response of Permit with Obligation X, if the PEP can carry
> out Obligation X then PEP allows Access, otherwise deny.
fine. let's have the PEP throw ERROR then. syntactically more precise, but the
result is exactly the same for the subject in any sane system.
>>>Second of all, what if some IT administrator added a lower level XACML
>>>policy with that obligation without regard for all of the PEPs that might
>>>use that policy? And then the XACML v2.0 compliant PEP denies the request.
>>
>>what if the same administrator slapped on a combing algorithm on the sonogram
>>policy that was unsolvable in the affirmative?
>
>
> That is a different case. Aside from human error, this administrator
> should know the result of its policy, which is completely self contained.
> An obligation and "its understanding" is outside of that administrator's
> realm (upward). He doesn't know how high that obligation will get lifted
> and whether anybody above it understands it.
just because a PDP treats an obligation as an opaque entity doesn't mean that
the policy writer doesn't know what it means. at some point we must have a
modicum of faith that policy writers understand what it is they are doing. can
an obligation result in an unintended deny? sure, but the policy writer added it
there for a reason and that intent MUST be honored in a reliable system. the
alternative is that--using the example above--data goes out unencrypted without
the knowledge that such is occurring. the sword of 'unintended consequences'
cuts both ways.
> Deterministic results are stated by saying given a particular request and
> a particular policy you will always get an answer and it will be the same
> answer.
...unless the PEP discards a portion of the decision (obligation), in which case
the real world results will be in variance with the intention of the policy writer.
> Which helps a person implementing a PEP for a particular application lay
> trust down in the PDP that it does the right thing all the time. That is
> determinism.
if an enforcement point does not take into consideration ALL aspects of a
decision, what you have is an applied crap shoot. unless the specification is
changed to remove obligations as components of a decision (basically reduce them
to notations) determinism requires that the PEP be able to consume them.
if that is the position that you would like to follow then i think that we
should entertain the discussion of redefining/removing obligations altogether.
however, i do not think that it can be boiled to a simple modification of the
current wording (at least without a discussion on the ramifications of such
beforehand).
b
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]