Re: [xacml] Obligations rear their ugly head.

[Polar Humenn <polar@syr.edu>]

On Tue, 6 Apr 2004, Bill Parducci wrote:

> what if the network is down? power is out?  there are many things that can lead
> to a PEP not being able to allow access that cannot be resolved.

And that is a policy of the PEP. Not a mandate from the definition of a
PDP.

> > First I have an issue with "provided that", of which I thought we agreed
> > that obligations were not supposed to mean.
>
> last i checked the intent was to mean that the PEP must understand and *be*
> *capable* *of* *fulfilling* the obligation in order to provide access. as to
> when this happens has remained intentionally undefined (to allow for 'deeply
> asynchronous' processes, or to a lesser extent possibly to handle situations as
> described above).

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.

Obligations are not Access Control items.

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.

which is what I thought we agreed on a long time ago, to avoid the
"provided that" syndrome.

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.


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

> > Furthermore, what are we writing requirements for a PEP anyway?
>
> why? deterministic *results* would be a good place to start.

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.

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.

> > XACML is
> > about calculating a decision. Granted that decision has semantics that
> > SHOULD be followed. However, it is up to the enforcement agent to
> > interpret the decision as it sees fit.
>
> i disagree. XACML is about being able to create policies that are
> interchangeable in a manner such that if applied, will yield predictable
> results. that is why the text in the spec was written to prevent precisely what
> you are suggesting; why spend so much time working toward deterministic results
> if those results are subject to 'interpretation'?

Since a PEP is not really defined in any real manner, it is not
inconceivable that a PEP may have to ask several PDPs. We've all stated
this case before. Some PDPs the PEP might trust more than others, one may
deny while the other permits. It is up to the interpretation of the PEP to
decide upon what basis it feels appropriate to its application.

I think it would be better to state the intentions of the workings. Words
like SHOULD and MAY are defined for that purpose.

> if you are opposed to obligations, the solution is not to implement a
> non-standard PEP, but to implement a PDP that does not support obligations (a
> completely standard implementation)
>
> > I don't think categorically denying things is the answer to ALL problems.
>
> true, which is why it hasn't been suggested here. the spec states that if you
> don't understand a decision you do not attempt to apply the decision. IF you are
> using a PDP that implements obligations, then you MUST deny if it provides you
> with a decision that you do not understand as a result of an obligation.
> supporting obligations in policies is *option*, ignoring them at enforcement is not.

I realize supporting obligations at the PDP is optional. However, it looks
like you MUST have a PEP that supports obligations. Why?

What I don't understand, is why do we have the "option" or the
"possibility" of getting an obligation that the PEP doesn't understand,
when the draft states that there is a "bi-lateral agreement" between the
PEP and the PDP. Why should we be saying anything at all about the
understandability of obligations at all?

> > If you're looking for a good use case, I just gave you a real one.
>
> here's another: there is a buffer overrun in the request parsing on the PDP and
> the result is unintelligible leading the PDP to issue and ERROR response.
>
> solution: do not categorically deny on ERROR?

You do not categorically deny or allow for that matter, because people
could die, planes could crash. It is a case that the PEP must decide
depending on what it is protecting. If a PEP for an Air traffic control
system gets an error from a PDP, it may elect to go to a back up, or do a
host of other things, like call Condi Rice, or something, not just
categorically deny.

-Polar

> b
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>