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

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

>>line 3130:
>>A PEP SHALL allow access to the resource only if a valid XACML response
>>of "Permit" is returned by the PDP.  The PEP SHALL deny access to the
>>resource in all other cases.  An XACML response of "Permit" SHALL be
>>considered valid only if the PEP understands and can and will discharge
>>all of the obligations contained in the response.  An XACML response of
>>"Deny" may also be accompanied by obligations.  In this case, if the PEP
>>understands the and can discharge the obligations it MUST deny access and
>>make best efforts to discharge the obligations; otherwise the PEP MUST
>>treat the decision by the PDP as an ERROR.
> 
> This still doesn't address my concerns. In the Permit case you seem to be
> issuing a SHALL requirement on discharging obligations, while in the Deny
> case, you are issuing a SHOULD (best-efforts).

we can say that it SHALL discharge the obligations, but the reality is that even 
if the obligations cannot be discharged the effect is deny because the PEP has 
to *do* *something* (doing nothing is doing something for access control). there 
is no such thing as 'sorta allow' or 'sorta deny' that i am aware of, so is the 
alternative, 'if the PEP is presented with a Deny + Obligations and it doesn't 
understand the obligations it should...' allow access? spin a big wheel?

> I don't agree.

i can see that ;o)

> The second sentence also says that the PEP SHALL deny access "in all other
> cases".  The paragraphs might as well just end after that sentence.
> 
> That single sentence alone says, if you don't get a Permit, then Deny.

...except that the rest of the paragraph attempts to explain what a "Permit" & 
"Deny" are (they have obligations vs. NA/I which do not) and what the 
ramifications of this difference entails (which seems to be the very basis of 
this thread)

> which leaves absolutely no room for dealing with this "error" thingy
> (which is not defined), or even NotApplicable.
> 
> Why cannot this paragraph simply state the requirements are for
> interpretation of the most simple model, which governs the common
> understanding that you write XACML policies, such that "Deny" means do not
> grant access, and "Permit" means grant access.

because it is important that "Permit" and "Deny" are fully expounded upon to 
alleviate 'interpretation' of what they may mean. "'Permit' means grant access 
*only* if you fully understand the constraints of the decision".

> A PEP that relies on a decision from a single PDP, and it receives a
> decision of Permit from that PDP, this PEP SHALL allow access. If this PEP
> receives a decision of Deny from that PDP, this PEP SHALL deny access.
> Either decision may carry with it obligations. It is this PEP's
> responsibility to discarge those obligations. Should this PEP not
> understand or cannot discharge any of the obligations, this PEP shall act
> as if the PDP returned a decision of Indeterminate with reasons concerning
> the understandablility or discharging the offending obligations.

just curious as to how you consider the decision "Indeterminate"? the PDP made a 
decision and that decision was clearly stated. how does the PDP know that the 
PEP cannot understand the Obligations when the answer it gives is "Permit" or 
"Deny"? furthermore, if the PDP doesn't know that the PEP cannot understand its 
decisions how is it expected to provided 'reasons concerning the 
understandability'? as far as the PDP is concerned everything is OK.

> If this PEP receives a response of Indeterminate or NotApplicable its
> action is out-of-scope as further action MAY be taken by the PEP depending
> on its configuration and capabilities. Further action MAY include, but is
> not limited to, denying access outright, looking up values for misssing
> attributes and resubmitting the access control request, looking up
> incomprehensible obligations, or requesting of an alternate PDP.

again, how does the *PDP* know this is "Indeterminate"? 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.

>>line 3478:
>>A PEP that receives a valid XACML response of "Permit" with obligations
>>SHALL be responsible for discharging all of those obligations.  A PEP
>>that receives an XACML response of "Deny" with obligations SHALL be
>>responsible for discharging all of the obligations that it understands
>>and is capable of discharging. If the PEP cannot understand the
>>obligations provided by the PDP it must treat the decision by the PDP as
>>an ERROR.
> 
> 
> Again, this is skewed toward Deny.

no it isn't. the *decision* is absolutely neutral. what is 'skewed' is the 
implementation constraints and that is necessary to make sure that when two PEPs 
are given the same decision they behave the same way (given teh same level of 
understanding). again, one of the PEPs may go looking elsewhere for information 
but until it finds a PDP that tells it to do something different (in a manner 
that it can understand) it MUST physically deny access.

> A default policy is the configuration issue for the particular application
> that deploys it.

that is true to a point. if you have a system that: ignores obligations, permits 
on "Indeterminate", or permits on "Not Applicable" you have a system that is NOT 
conforming. period.

> You can tell me how I SHOULD use your product, but You are NOT going to
> tell me how to run my organization!

then write policies that don't break your systems. this has nothing to do with 
business processes. quite the opposite, what is being said here is that we want 
to make sure that if a policy says to do something under certain circumstances 
(with qualifications if desired) that it will actually be done the same way 
using two or more systems that implement the same specification (with the same 
capabilities).

> I don't agree. Again you are writing requirements on points you have no
> knowlege about and you cannot control. You're guessing, and for lack of
> information, you may be making the wrong decision.  Like our current
> President.

i am not guessing about anything. i am trying to prevent some anarchist PEP 
developer from creating a system that will ignore the reasons the underlying 
principles of the standard because he doesn't want to be 'mind controlled by the 
man' :o)

> Deny is meant to be deny access
> Permit is mean to be grant access.
...so long as you fully understand what Permit means

and

Indeterminate means deny access lacking another other decision to the contrary

and

NotApplicable means deny access lacking another other decision to the contrary

that is EXACTLY what the spec has said since day one. i have looked through the 
spec and cannot find anything that prevents the PEP from taking other decision 
prospecting actions. what i do see is the spec saying that you cannot allow 
access unless told to do so. i personally cannot think of any other way to 
explain how to succinctly act upon the decisions presented.

> and further, this is only in the case where you have a signular PEP-PDP
> relationship!

no. it is the case regardless where the PEP looks for decisions or how it 
requalifies the question.

> It may be your Policy at your organization to categorically deny when you
> get anything other than a Permit.  I respect that. It's your organization,
> and it's your configuration.
> 
> But don't tell me that's how I should act.

heck, why stop there? why should XACML say you should Permit on Permit or Deny 
on Deny? why not have the PEP just kind of cruise around until it gets an answer 
that it is emotionally comfortable with?  that way it is ok for an 
'organization' to allow access upon Deny and we can all stop being so darn 
judgmental! :oP

> If I want to deploy a XACML eating breathing PDP in my organization, the
> spec tells me how to write polciies for it, such that Deny means Deny, and
> Permit means Permit. And that's only so we have some common standard
> expectation if I gave the job to write policies to somebody else.

NO. who needs an international standard for that? you can pick any vendor in 
oasis that provides the desired service and just hand the next policy writer the 
operation manual. the goal of the XACML standard (unless i have been wasting 3 
years of my life ;o) is to create an environment where more than one entity may 
be able to exchange policy information in such a manner such that the *applied* 
affects are equivalent even when interchanging components.

> If my PEP chooses to have 27 PDPs how are you going to tell me to run
> that?

see above.

<thwap> <thwap> <thwap> uh-oh, the black helicopters are here for my meeting 
with my co-conspirators. gotta run...

b