Re: [xacml] Concrete Proposal of ConditionReference (#7)

[Polar Humenn <polar@syr.edu>]

Seth,

Please see comments in line.

On Thu, 5 Feb 2004, Seth Proctor wrote:

>
> Polar Humenn wrote:
> > Oh, it has, maybe before your time. We've always held XACML to be a
> > "declarative" language. And the given the same policy, and the same input,
> > in all cases all PDPs should return the same value.
>
> This is nice in theory, but it's certinaly not accurate in reality. Why?
> Because you rarely have the "same" input. Consider:
>
>    <Request>
>      <Subject/>
>      <Resource>
>        <Attribute DataType="...:string" AttributeId="foo">
>          <AttributeValue>bar</AttributeValue>
>        </Attribute>
>      </Resource>
>      <Action/>
>      <Environment/>
>    </Request>
>
>    <Policy ...>
>      ...
>      <Rule RuleId="rule" Effect="Permit">
>        <Condition FunctionId="...time-less-than">
>          <Apply FunctionId="...time-one-and-only">
>            <EnvironmentAttributeDesignator DataType="...time"
>                AttributeId="...current-time"/>
>          </Apply>
>          <AttributeValue DataType="...time">17:00:00</AttributeValue>
>        </Condition>
>      </Rule>
>    </Policy>
>
> It is obviously true that the same Request run over the same policy will
> return different Results at different points. Because the RequestContext
> is "notional" and because you can always write custom, non-deterministic
> functions, you cannot make any guarentees about the restuls.

This "current-time" attribute name is still burning us. The RequestContext
is "notional", but the information in it is not. All information must be
there. The Request must contain the "current-time" attribute (if used).

The PDP has no concept of "current" time. I've said this time and time
again. :)

You must supply the current-time in the RequestContext.  It is valid to
ask if Alice has access to a resource at any time, whether or not that
time is said to be "current" in reality.

A PDP that supplies a value for the current time attribute is not correct.
It is the XACML Request Handler that will supply that attribute.
Therefore, in your scenario, your two requests would actually be
different.

> >>If I have a designator that references something that changes over the
> >>course of the evaluation, I now have to keep its value constant? What
> >>about if I cache a policy over many evaluations? Hrm.
> >
> > The value must remain constant for the entire evaluation. This requirement
> > is enforced implicitly. You apply a policy evaluation (and sub-policy
> > evaluations) to the same RequestContext.
>
> There is no such requirement in XACML. The RequestContext is amorphous,
> and therefore gives you no guarentees about anything remaining constant.

If there isn't, it should be. I don't have the spec in front of me, but I
believe we mandated that a long time ago. At least I know I did.

> Even if it was the same, what stops me from writing a custom function
> that uses random numbers to produce random results? Nothing. Either way,
> you cannot make these guarentees about a PDP's results.

Nothing stops you. However, then by writing that function, you are
invalidly extending XACML. I believe there is a point in the spec that
states that extension functions that are provided the same inputs shall
provide the same results for those inputs. (That doesn't give license to a
zero-ary function to produce random results).

> > If what you say were really the case, we couldn't hope for
> > interoperability or consistent evaluation even by the time Jenna Bush is
> > ordained president of the united states.
>
> Comments about Jenna aside (though that could be entertaining too <g>) I
> disagree. Interoperability isn't a problem, since the form of the policy
> remains the same across PDPs. Consistent evaluation is based on the
> whole of the "context handler" which is a non-static entity.

Interoperability is not a problem, because we PUNTED on it. The fact that
I lost the fight to have at least one "access-subject"  subject with one
specific named attribute, one Resource with a specific named attribute,
and one "action-id" Action attribute, gives credence to the fact that
policies will not have a guarantee of being "interoperable" (i.e. portable
accross PDP Request Handler/PDP implemenations).

I've been through this situation before in the days of CORBA 1.0, where
nobody could conceive that you might deploy a distributed CORBA
application on different vendor's products simulaneously.

> > As a policy writer, you must have the assurance that your values will not
> > change at some arbitrary point in the evaluation. We enforce that by
> > saying XACML is a declarative language.
>
> Again, I disagree. As a policy writer I need no such guarentees. All I
> need to know is that I can access a particular value. In fact, I may
> choose to implement access to a particular attribute such that each
> access changes the value. I'm not making this up. I've done this. (for a
> fun exercise, think about qbits)

Surely, you can even implement a function called "plus" that takes two
arguments 4 + 5 and returns a random result.

> Now, I can understand the value in saying that for a given evaluation,
> all values will remain fixed. I can also understand the value of
> introducing a language feature that makes this contract explicit. I
> might be supportive of something like this. I do not think, however,
> that this is defined in any clear way in the current specification. I
> also don't think that it should be slipped in with a feature that is
> supposed to be providing some simple syntactic sugar. If we're changing
> the semantics of the language then fine, but let's be clear about it.

Paragraph 2 of A.14.14 Extension Functions and Primitive Types says:

"In order to preserve some integrity to the XACML evaluation strategy, the
result of all function applications SHALL depend only on the values of its
arguments.  Global and hidden parameters SHALL NOT affect the evaluation
of an expression.  Functions SHALL NOT have side effects, as evaluation
order cannot be guaranteed in a standard way."

> Note that a while back I suggested a change for 1.1 that required the
> current date, time, and dateTime to remain fixed for a given evaluation,
> since they're values that the PDP is required to supply and therefore
> they are special cases. I receieved a fair amount of opposition to this,
> suggesting that others also think that values and evaluation results are
> non-static for a given input.

Time information is like any other information in the request. There is no
notion of values changing throughout the coarse of an evaluation.
Implemenations that do so, may play that card in some hopes for
efficiency, as Daniel may have taken advantage of. However, those that do,
and do so in a way that yields different results for the same request are
in violation. Any "clarifications" to that effect of specific attributes
are redundant, and could lead to implications that for all other
attributes it is not the case unless specified.


> Thoughts?

You got mine. :)

Cheers,
-Polar

>
> seth
>