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

[seth proctor <Seth.Proctor@Sun.COM>]

Polar Humenn wrote:
>>Let's be clear here. Implementations that allow referenced values to
>>change over the course of an evaluation are _not_ in violation of the
>>1.0 or 1.1 specification.
> 
> That is EXTREMELY unfortunate, and any product that does that I wouldn't
> put any faith in, let alone buy. This is why standards must adhere to
> formalizisms that guarrantee the integrity of the products that are
> deployed. I am sorry you feel the way you do.

I'm not expressing a feeling here. I'm repeating what the XACML standard 
says. When the decision was made that attributes can come from locations 
other than the decision request, it was implicitly decided that the same 
decision request can return different results because values are being 
filled in outside of the Request.

>>It is perfectly legal, and indeed expected, that the same Request may
>>yield different Responses.
> 
> Who "expects" it? That's where you an I differ. Just because there is a
> problem with the specification where it said "PDP" instead of
> "RequestHandler", I WOULD NOT expect that behavior out of a quality
> implemenation. Maybe bill gates does, but I do not. Sorry.

The language about PDP versus Requst Handler is a separate issue 
surrounding current date/time values, and as I have stated I believe 
this has already been resolved.

As to who expects the environment providing attribute data to change, I 
do. As does Daniel based on his last email. As do countless dozens of 
people with whom I've spoken over the last year, and thousands of people 
who design infrastructures. Policies change. Attributes change. If a PEP 
provides, in a decision request, all the values used in an evaluation 
then yes, the result will always be the same. But as soon as even one 
value is being pulled from outside the decision request, you can no 
longer assume this. As Daniel said, it hurts your system overall to try 
and enforce this.

And another thing: if you ever equate me to Bill Gates again, I'm 
personally coming to Syracuse to beat some sense into you :)

>>There is nothing in the specification that says otherwise. I have
>>re-read the specification several times in the last week, and I cannot
>>find any language that says otherwise (other than the explicit statement
>>about functions, which I mentioned in my earlier mail). Therefore,
>>clarifications for the new def/ref mechanism are very useful.
>
> We should definately recitify this problem. And it is a problem.
> I am sure it was a mandate when we started that given the same request
> context, the PDP MUST return the same answer, (with exception of error
> cases). That is to say, if the PDP returns Permit for a particular
> request, it will always return Permit for that exact request, or quite
> possibly return Indeterminate, but never Deny. And the same argument
> follows for Deny.

I do not believe that there is a problem that needs to be rectified. I 
do believe that providing some options to make evaluation constant are 
useful. Moreover, I challenge you to find a way to build a system that 
makes these guarentees without breaking the overall security of the 
system. Would you cache all retrieved attribute values? Would you ignore 
when they change? Very dangerous...


seth