Re: [Re: [xacml] obligations & error conditions] - PROPOSAL

[Polar Humenn <polar@syr.edu>]

On Wed, 14 Apr 2004, Bill Parducci wrote:

> > First of all, obligations are NOT constraints of the decision!
>
> if you don't understand or cannot discharge an obligation presented in a
> decision you CANNOT permit access regardless of the decision rendered. that
> isn't a constraint?

Not in a formal sense. It is an error condition which may be dealt with
per installation policy, as it sees fit. If that means deny, so be it.
However, it could equality mean permit.  As in forgoing the call to the
security desk to Permit Mary's access to open the freezer door. So, she
doesn't die.

> > And why isn't "Deny" means deny access *only* if you fully understand the
> > ....."
>  >
>  > Why are they different?
>
> because the TC has determined the XACML standard explicitly state that unless
> the PEP is presented with a "Permit" that it *fully* understands the PEP CANNOT
> ALLOW ACCESS. period. you can propose to fundamentally change the specification
> if you wish, but this is what the spec has said for quite some time now.

And, I'm trying to clear something that has been messed up for some time
now.

> > The paragraph stated the PEP interpret the decision from the PDP in a
> > different way. It says nothing about what the PDP thinks the PEP will
> > understand.
>
> again, if the PDP presents a Permit or Deny with an obligation and the PEP
> treats the answer as Indeterminate or NotApplicable the PEP just made and access
> control DECISION.

Now, you are getting it. The PEP is free to make that access control
decision.

> > It was there mainly to convey the information that if the PEP didn't
> > understand an obligation, it can consider the result an "error" (which is
> > not defined), so I used Indeterminate, which is defined. And since
> > Indeterminate may have reasons associated with it, the PEP can consider
> > the reasons for the indeterminate result the problem it has with the
> > offending obligations.  That way, it may be able to do something about it,
> > like ask somebody what the damn obligation means.
>
> hey, if you are going to *change* the decision why not pick Permit? i am not
> saying that the PDP must now return a decision of "Error", i am saying that the
> PEP must treat it as if there was an ERROR condition. if your PEP wants to bark
> at the moon when there are errors in the decision request process that is fine,
> it just cannot *change* the decision because it doesn't like the answer
> (Permit/Deny w/obligation --> Indeterminate); that is most precise description
> of a standards violation i can think of.

I said that I am fine with that interpretation, if it needs to be there.
The PEP can consider it an Error, (Indeterminate), and take steps to
either make an outright decision (of Permit or Deny), or take alternative
action.

However, the text stated that it had to be Deny, periord. (2nd sentence).
Also, it had that obligations worked differently with a Deny decision
than they did with a Permit. Permit caused the obligations cause and Error
if they were not understandable or dischargable. Deny didn't care much. It
would still be a deny, instead of an error.  It's that slanted diacotomy I
am objecting to.

> > This paragraph is explicit. Doesn't the PDP return one of four values.
> > Permit, Deny, NotApplicable, and Indeterminate? I thought it did. There
> > should be interpretations for each result.
>
> no one said that the PDP didn't return one of those answers. the point that we
> are discussing is what happens if there is an obligation with [Permit, Deny] and
> the PEP doesn't know what to do with it. in that case, i have suggested that the
> PEP treat the decision as if the result were incomprehensible (in my world that
> is typically known as an Error).

That is fine, if Permit and Deny are treated equally with respect to the
offending obligations.

> >>if the PEP makes that DECISION then you have just broken the separation
> >>of concerns model that XACML is based upon pretty seriously in my mind.
> >>can it try other PDPs? yes. can it rephrase the question? yes. can it
> >>decide that NA/I answers will grant access?  NO. and NO.
> >
> > Why not?
>
> forgetting for a second that the spec has always specifically stated that this
> is not allowable, assigning [undefined=]unpredictable actions to discrete
> decisions removes any value from the definition of such decisions.
>
> > You say, you grant access *only* if there is a Permit.
> > That assumes you only write policies that grant access.
> >
> > What if I want to only write policies that Deny Access.
> > I don't see a difference of one over the other.
>
> then it only takes ONE 'access' policy to allow you to do that to your heart's
> content:
>
> 1. let everyone in
> 2. don't let bill in
> 3. don't let fred in
> (deny-overrides)
>
> PEP: can polar get in?
> PDP: Permit
>
> PEP: can bill get in:
> PDP: Deny

Fine. I have no problem with writing XACML policy to mean something
determinate.

Okay, now I get one of your little ERRORs from the PDP. What do I do?
Permit or Deny?

> one little policy and we can all work together. contrast this to having a PEP
> that decides (*without* *an* *expressible* *standard* by which to communicate
> that decision) to allow everything unless expressly forbidden to do so. this is
> NOT telling anyone how to run their business. this is a practical constraint
> that allows for interoperability.

But we are not talking about one little policy. We are talking about the
interface between a PEP and some number, assuming 1, PDPs. The spec tells
me what policy is that I must adhere to.

What you keep wanting to do is place a be-all-end-all policy on the
interface.

> why? (beat you to it :o) because not having such a constraint removes the basis
> by which there would be any hopes of compatibility amongst compliant systems
> (which is why the spec specifically forbids it). is this mind control? no. the
> policies simply need to be written such that the desired actions are permitted
> and the undesirable actions are not *regardless* of the compliant PEP that
> enforces them. no one is trying to tell you 'how to run your business', but we
> are telling you how to write your policies so as to allow for such interoperability.

I agree. And that's all in the spec. How to create an XMLized version of
an Accss Control Policy <Policy> or <PolicySet> to do what I need do. I
have no problem with that.

But you bring up Errors in the interface, (which is not defined), and mabe
no Error, per say, but such that a decision may have non-understandable or
non-executable components in the result. Then, you try to force my hand at
some policy you think is acceptable for me, which may indeed be no way
near what I need or want, because you have no authorative information
about my organization or even the policies I put in the PDP.

> > And I then I say you've overstepped your bounds about telling me how to
> > run my organization, and I can tell you that you don't have enough
> > information about how I run my organization, or even what my policies are,
> > and I can tell you to go take a hike. What are you going to do, sue me?
> > [...]
> > John Ashcroft
>  > [...]
> > Patriot Act
>  > [...]
> > duck hunting trip
>  > [...]
> > sales records
>  > [...]
> > These words and pseudo requirements are meaningless, much less out of
> > scope of what the standard can enforce.
> >
> > Again. You don't have enough information on those systems. You're
> > guessing. I don't like your guesses.
>
> sorry, but i am not following the hysteria here. what i can tell you is that if
> you bring your PEP to an interop where it is presented with an obligation that
> it doesn't know what to do with and then proceeds to *change* the decision to
> 'Indeterminate', or decides to allow unless presented with a Deny, that it will
> not interoperate and will not be deemed compliant. no guesses there.

First of all there is no interface defined for a PEP (sic) PDP
relationship. You'd have to give me a lot more to go on.

Secondly, there would be many more requirements based on the application
context. One of them would very well could be, if you get an error from
the PDP, you shall Deny Access. Fine. If that is a requirement for that
particular PEP at the interop, so be it I can configure it to meet those
policy requirements for that particular application context.

I run an interop demo at the next HIMMS conference that is running a
critical operating room. The application context, the requirement is that
the PEP should be configured such that if you get an error from the PDP
your PEP shall permit access to information and log it.

Your PEP, I assume without the ability to vear from that part of the
XACML, would FAIL the demo.

No big deal. No hosiptal would buy it. There might be a few lawyers
chasing around, though, that might be interested in your company's
E&O insurance policy.

> > For the purpose of transportability of policies and understanding amongst
> > writers, the words "Deny" is meant to mean deny access and "Permit" is
> > meant to grant access, NotApplicable means that the policy does not apply,
> > and Indeterminate means that a decision could not be determined for
> > various reasons. Period.
>
> ...and you just got done telling me that if your PEP gets a Permit with an
> obligation it does not understand that the *PEP* will CONVERT it to an
> Indeterminate. it is not possible to be any more broken than that.

I would rather say nothing about the operation of the PEP, period, becuase
I consider it out of scope of what the spec has knowlege of, and can
enforce.

But in realization I will probably loose that battle, I'd rather have it
say something that doesn't try force my hand at a particular policy, which
I would have to ignore.

If you interpret this condition as ERROR (what ever that is) as if it were
an Indeterminate, then it is local policy to decide what to do with it.
(Like Permit and log it).

> > Most of that text keeps stating *the* PDP, and *the* PEP. Not multiples.
>
> because the spec condenses down to *one* PEP talking to *one* PDP, we are not
> discussing polysynchronous communication models here. this does not mean a PEP
> cannot ask 500 PDPs for an answer, but for the purposes of how the decision is
> rendered the only way we can define the outcome is on a per decision basis.

And that's probably why we should NOT say anything about it at all. We
don't have enough information.

> >>heck, why stop there? why should XACML say you should Permit on Permit or Deny
> >>on Deny?
> >
> > It should. That's because one of the chief tenets of the standard is
> > transportability of access control policy.
>
> precisely. you are dictating how a PEP should behave in the light of these
> decisions. for the sake of transportability, what you must also do is dictate
> what a PEP does if it is presented with an incomprehensible decision.

No I don't. I'm not transporting my PEP or the thing that interprets my
policy (PDP?) or my application which ties it together.

I'm transporting the policy, i.e. <Policy>, <PolicySet>.

>  by definition the PEP is presented with a decision of Permit or Deny if
> given an obligation. this unequivocally precludes the PEP 'behaving as
> if it were given an Indeterminate'.

That is fine, if you say, the PEP understands the obligation. If it
doesn't, then it says it is an Error in the case when the decision is a
Permit, which of course, means you should Deny. And in the case when the
decision is a Deny, then you say, well, you gave it your "best-effort",
and of course, you should Deny. That is a slant toward Deny.

> the only mechanism that i can think of that doesn't break the spirit of the
> specification is for the PEP to handle such a situation as an Error. this
> maintains the integrity of the decision and [on most systems] creates a context
> for notification that something is amiss. at that point, the PEP can do whatever
> it is that it thinks is reasonable other than grant access (unless presented
> with a decision that explicitly states that it may do so via a Permit).

if you stopped right after "whatever it is that it thinks is reasonable",
I would have been fine with that. But then when you continued with "other
than grant access" you lost me, yet again.

> > I may have a PEP that asks 27 PDPs, and figures out an comfortable
> > majority. It's my policy. I'll do what I need to for my application.
>
> 'figures out an comfortable majority'? hmmm... interesting. policy combination
> algorithms on the *PEP*.

It's my PEP. Look, my whole access control system may not consist of the
ONE and the ONLY, ubiguitious, be-all-end-all XACML single policy engine
solves all access control problems for ever and ever solution!

I may have many layers from configuration files, proprietary access
languages, XACML policy engines, Ponder policy engines, to old RACF
systems. I've got to combine them somehow. And you may see that as a
policy combining algorithm at the PEP. What's wrong with that? Nothing.

> > Look, if you build a PEP that behaves the way you say. Denies unless there
> > is unequivocal Permit that's fully understood. It takes an XACML PDP on
> > one end, and allows an application on the other. That's fine.
> >
> > Now, if I'm a buyer of software products. I see that your PEP denies on
> > anything, but a Permit.  Okay, that may be well and good for 85% of all
> > customers.
>
> can you give me an example of the 15%? if you want to have a PEP *behave* as if
> it allows everyone in unless specifically told not to you can do this easily
> with the current spec (the example above does just that).

I keep going on and on about the life criticial situations such
as surgical operating rooms, triage units, etc. These systems must be fail
safe, and fail safe in such a way that people do not die if something goes
wrong.

> if you find none of this persuasive then i suggest that you submit a proposal to
> the TC to change the specification in a manner that is consistent with your views.

okay.

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