[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Concrete Proposal of ConditionReference (#7)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]