Re: [xacml] Obligations rear their ugly head.

[Bill Parducci <bill.parducci@overxeer.com>]

Polar Humenn wrote:

> "PEPs that conform with v2.0 of XACML are required to deny access unless
> they understand and can discharge all of the <Obligations> elements
> associated with the applicable policy."
> 
> With my dad in the operating room this weekend, I found myself stating to
> myself, "Gee I hope those IT people didn't install a XACML compliant PEP."
> 
> All I needed was to have a previous X-ray or Sonogram denied because
> somebody put an obligation, such as as in Example Rule 3 in the spec, "A
> physician may ...... provided an email is sent to the patient".
> 
> "Provided that"? What if the email system is down? Then the PEP cannot
> "discharge" that obligation, and therefore denies.

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.

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

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

> Furthermore, what are we writing requirements for a PEP anyway? 

why? deterministic *results* would be a good place to start.

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

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.

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

b