OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] Making progress?

Hi Rich

I think some of the logic on deny overrides is flawed as described below.

Rich.Levinson wrote:
> Hi Erik,
> This proposal sounds good to me. Apologies for any ambiguity on my 
> preference for having the biased algorithms - it took a while for me to 
> realize that having "only" the unbiased algorithms made it impossible to 
> screen out Indeterminates and NotApplicables - I had thought cleverly 
> combining them could block things, but when I worked thru the details I 
> realized that was not possible. My sense is that for the most part 
> people will want to use unbiased, but that often there will be a need to 
> "cap off" the hierarchy w biased so that the PDP actually makes the 
> decision and doesn't leave it to the PEP. Not everyone will want to do 
> this, but I think we should make it available for those who do.
> Also, I am not a strong advocate of the other 2 algorithms (5 and 6), 
> however, I found it interesting "logically" to understand where they 
> fit, especially since it appears the policy-permit-overrides in C.3 was 
> intentionally the way it was to minimize the number of Indeterminates.
> It causes me to think a little more about what Indeterminate(D), (P), 
> (DP) really mean. These were defined in attachment to:
> http://lists.oasis-open.org/archives/xacml/200811/msg00028.html
> and from the perspective of the "-overrides" suffix, I think that having 
> these algorithms (5 and 6) undermines the meaning of "-overrides".
>     i.e. if we have a deny-overrides Policy and there are no denies, and
>     we are left with a permit and a potential deny (Indeterminate(D)),

In this case if the subject has the necessary attributes to fire a
permit rule, then returning permit is correct. If the subject does not
have sufficient attributes for any rules are no rules are fired, then
all you have are indeterminate(D)s, in which case you should either have
a combining policy such as Default Deny which always returns a Deny if
no rules are fired (in which case indeterminate is never returned), or
you return indeterminate and let the PEP decide.

>     then someone could theoretically discover that they were denied by
>     this policy, but that if they simply left out an attribute, then
>     that policy would evaluate to Indeterminate(D), which would be
>     overridden by a Permit.

Two points here. Firstly permit should not be returned in preference to
indeterminate unless your combining algorithm is called Default Permit
or similar. There is some fundamentally wrong logic in a combining
algorithm called deny overrides which actually has a permit overriding
indeterminate. Secondly, if the attribute that fires the deny is a
"negative" attribute such as a criminal record, then of course the
subject will never willingly provide this anyway, and there is no way
that a PEP or PDP can know the full set of attributes that any user has.
To solve the withholding of attributes by a subject is not a PDP issue.
Its a PIP issue if anything, so it out of scope of the current policy
discussion, since the PDP can never know the difference between someone
who genuinely does not have an attribute and someone who does have but
chooses not to reveal it. The PDP should treat both subjects identically.

  I know we discussed this before, but I think
>     it is worth recalling again, because it appears fundamentally
>     "wrong", at least in an algorithm named "deny-overrides".

I agree with that.

>     i.e. in prev email, I pointed out that the motivation appeared to be
>     to minimize Indeterminates, which, while it may sound like a
>     reasonable objective, the reality of it in a combining algorithm
>     really undermines the apparent intent of the algorithm.
>     i.e. deny-overrides is very weak if you can remove the impact of the
>     deny by simply submitting less information.

I agree.



> Therefore, I agree that the algorithms 5,6 should not be something that 
> we recommend in the spec. It they were to be intermingled with the first 
> 4 algorithms, they could create significant confusion. If someone really 
> wants them, they can always add in a custom algorithm, if their PDP 
> supports that.
> Bottom line: I think we are in agreement w the four combining algorithms.
>     Thanks,
>     Rich
> Erik Rissanen wrote:
>> Hi Rich and all,
>> I must have misunderstood you earlier. I thought you did not want the 
>> biased algorithms. But defining them is fine for me, as long we also 
>> have the unbiased ones. I think what Daniel suggests is not what most 
>> people would want to do, since I don't think most people want to hide 
>> errors from the PEP, but if someone would like to do that, then that's 
>> up to them to define in their policy, if they can choose between 
>> biased and unbiased algorithms.
>> The four first algorithms Rich proposes are good and will cover most 
>> use cases. The first two are for regular policy combining, number 
>> three and four are useful for defining bias in a policy.
>> The last two I think are dangerous and not useful. It's dangerous to 
>> combine permits and denys when there are indeterminates which could 
>> potentially be either permit or deny (which one is dangerous depends 
>> on the algorithm). For instance, if you use deny-permit-overrides and 
>> you have a Permit and Indet{D}, then the algorithm would return a 
>> Permit, although there could have been a deny somewhere else, but this 
>> was hidden by an error. I don't see any use case for this and it could 
>> be dangerous. On the other hand, if we "fix" this problem in the 
>> algorithm, the last two become the same as the first two.
>> So, I propose that we define the following algorithms. (I like these 
>> names slightly better than the ones Rich is using.)
>> All algorithms use extended indeterminate.
>> - urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides
>> This one is not biased. Basically the same thing as the 2.0 rule 
>> combining alg.
>> - 
>> urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-overrides
>> This one is not biased. Basically the same thing as the 2.0 rule 
>> combining alg.
>> - 
>> urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit 
>> - 
>> urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-unless-deny 
>> Best regards,
>> Erik
>> P.S. I don't think we can cover all possible combining algorithms in 
>> the standard. If we disregard order and number of policies, there are 
>> 16 possible inputs to a combining algorithm (the power set of the the 
>> set {P,D,I,NA}). For each input, the algorithm can return one out of 
>> four results. So there are a total of 4^16 different possible 
>> combining algorithms. That's about 4.3 billion variants. Correct me if 
>> I am mistaken. :-)
>> Rich.Levinson wrote:
>>> Hi Erik, and all,
>>> I have some concerns about the proposed resolution. In particular, 
>>> dis-allowing the biased algorithms (the existing XACML 2.0 
>>> policy-combining algorithm, deny-overrides, section C.1, is biased, 
>>> explicitly because of lines 5225-5228 (if Indeterminate return Deny)) 
>>> we are essentially changing what, according to Daniel, was planned 
>>> functionality:
>>> http://lists.oasis-open.org/archives/xacml/200810/msg00027.html
>>>     "The whole point of Indeterminate value is that it can be
>>>     explicitly handled by a combining algorithm, and error propagation
>>>     avoided whenever possible. Just throwing an exception all the way
>>>     to the client is what we have tried to avoid."
>>> In all the discussion that followed that, from my perspective, we 
>>> were trying to find a rationale for determining what the "correct" 
>>> set of combining algorithms should be. In the process, we uncovered 
>>> two fundamental characteristics of the existing algorithms:
>>>    1. There is an implicit "bias" property that was exhibited in
>>>       policy deny-overrides (C.1), that did not have a corresponding
>>>       representation policy permit-overrides (C.3). (and it also
>>>       appeared that C.3 had a mistake, because a Deny was given
>>>       precedence over Indeterminate in a permit-overrides algorithm,
>>>       which appeared to ignore the fact that the Indeterminate is a
>>>       potential-permit. Based on the text preceding the p-code, and
>>>       Daniel's comment above, this may also have been intended, with
>>>       the notion that any definitive decision is preferable to
>>>       Indeterminate, however it appears to be a 3rd variation to the
>>>       notion of "overrides".)
>>>    2. There is an implicit "extended" property (probably need a better
>>>       term) that was inherent in the rule-combining algorithms that
>>>       was screened out in the policy-combining algorithms. This
>>>       property reflects the "half-boolean" nature of a Rule, and also
>>>       possibly a collection of Rules, and also the logical property
>>>       propagates up to the Policy and PolicySet levels as well.
>>>       However, the property was only processed by rule-combining
>>>       algorithms, which accounts for the difference between the
>>>       rule-combining and policy-combining algorithms, which
>>>       effectively discards potentially useful information.
>>> The suggestion I made at the end of:
>>> http://lists.oasis-open.org/archives/xacml/200811/msg00037.html
>>> which was to have 2 biased and 2 un-biased extended algorithms 
>>> enables all of the functional issues above to be addressed, except 
>>> possibly the "3rd variation of overrides", which could possibly add 2 
>>> more (definitive-decision overrides) algorithms if that is a desired 
>>> option.
>>> The point is that the existing algorithms represent a particular 
>>> logical subset of the possible logical algorithms of the implicit 
>>> domains that represent a 3x2 matrix (3 override options: permit,deny 
>>> and definitive-decision, and 2 bias options: unbiased, biased).
>>> In addition, the existing algorithms, do not process all the 
>>> information (policy combining drops the extended Indeterminate 
>>> property).
>>> The following proposal is 6 algorithms that should cover all the 
>>> cases above, where these algorithms can be used at both the policy 
>>> and rule levels:
>>>     * extended deny-overrides (e.g. C.1 rule)
>>>     * extended permit-overrides (e.g. C.3 rule)
>>>     * extended biased deny-overrides (deny unless explicitly
>>>       permitted) (e.g. C.1 policy)
>>>     * extended biased permit-overrides (permit unless explicitly denied)
>>>     * extended deny-permit-overrides (indeterminate only if no deny or
>>>       permit)
>>>     * extended permit-deny-overrides (indeterminate only if no permit
>>>       or deny) (e.g C.3 policy)
>>> I think the above list at least makes explicit the logical options 
>>> that are implicitly contained in the existing algorithms. The fact 
>>> that they are all prefixed by "extended" means that the nature of 
>>> Indeterminates is logically preserved, although the 2 explicitly 
>>> "biased" algorithms remove this property by removing Indeterminates.
>>> With the above context in mind, my inclination is that the existing 
>>> algorithms are purposefully aimed at reducing the return of 
>>> Indeterminates, while at the same time attempting to preserve some 
>>> aspects of the half-boolean nature of an Indeterminate from a single 
>>> Rule and the potential half-boolean nature of a collection of Rules 
>>> within a Policy. (However, the existing algorithms do not take into 
>>> account the potential half-boolean nature of a Policy, PolicySet, or 
>>> collections of Policies and PolicySets.)
>>> Therefore, I am very reluctant to agree that we should only include 
>>> unbiased algorithms.
>>> One final point to the comment in Erik's email:
>>>     "Currently this means that policies have to be refactored so that
>>>     all such rules are isolated in their own policy since rules cannot
>>>     contain obligations directly. This is a bit of nuisance to do."
>>> I do not believe that with the existing algorithms that policies 
>>> "can" be refactored to allow the rules to appear in their own 
>>> policies, because the rules are subject to rule combining algorithms 
>>> which contain logic not available in the policy combining algorithms. 
>>> It is only by using the extended combining algorithms that this 
>>> refactoring is possible.
>>>     Thanks,
>>>     Rich
>>> Erik Rissanen wrote:
>>>> Hi Rich, and all,
>>>> It was noted during the discussion that it may be the case that one 
>>>> writes a number of rules with conditions, such that if those 
>>>> conditions trigger, there should be an obligation. Currently this 
>>>> means that policies have to be refactored so that all such rules are 
>>>> isolated in their own policy since rules cannot contain obligations 
>>>> directly. This is a bit of nuisance to do.
>>>> There was some discussion that there is really no fundamental reason 
>>>> to allow obligations at the rule level. I have thought the same 
>>>> thing previously, and I think it would be a good idea to allow 
>>>> obligations in rules as well. At first I was opposed to the change 
>>>> since we have a feature freeze and we should focus on closing issues 
>>>> rather than opening new ones. But I think this is a minor change 
>>>> which could be made.
>>>> TC: what is the general opinion on this? Should we change the schema 
>>>> so rules can contain obligations as well? It would be good if I 
>>>> could get a general indication of what we want to decide, and I 
>>>> could prepare a draft for review this week already, so we could 
>>>> close this issue on the next call already. Otherwise we will make 
>>>> the decision on the next call, and I edit the daft after that and 
>>>> the final closing of the issue is pushed past the holidays, delaying 
>>>> everything by a month or so.
>>>> Also, could I get some kind of indication on what we want to do 
>>>> regarding policy combination? After the discussions Rich and I have 
>>>> had, I propose the following, which I think Rich and I at least 
>>>> would agree on:
>>>> - The regular XACML combining algorithms will not be biased.
>>>> - We make use of the "extended indeterminate" to have better error 
>>>> handling capability at the policy combining level. This also makes 
>>>> the rule and policy combining algorithms symmetric.
>>>> - We do not specify biased variants of the combining algorithms?
>>>> TC: Could I get a rough indication on what people feel on this 
>>>> issue? If so I could finish a working draft this week which can be 
>>>> reviewed for CD status on the next meeting.
>>>> Best regards,
>>>> Erik
>>>> Rich.Levinson wrote:
>>>>> Hi Erik,
>>>>> Unfortunately I missed the meeting this morning, however, Hal 
>>>>> filled me in on some details. In particular, Hal mentioned that in 
>>>>> the Boeing presentation that there was indicated a requirement for 
>>>>> having Obligations available at the Rule level, while they are 
>>>>> currently available only at the Policy level. This was also 
>>>>> mentioned in today's minutes, but it is not clear from the minutes 
>>>>> or a quick read of the presentation referred to in the minutes what 
>>>>> the exact requirements are:
>>>>> http://lists.oasis-open.org/archives/xacml/200812/msg00008.html
>>>>> In any event, based on the partial information, I will take a stab 
>>>>> at a possible means to address this issue.
>>>>> One aspect of the discussion on issue 66 is that we agreed there is 
>>>>> essentially an "extra layer" in the PolicySet/Policy/Rule 
>>>>> hierarchy, which can effectively be removed using the uniform 
>>>>> extended combining algorithms we discussed in earlier emails:
>>>>> http://lists.oasis-open.org/archives/xacml/200811/msg00040.html
>>>>> As a result of this uniformity, there is no longer any compelling 
>>>>> reason to have more than one Rule in a Policy. i.e. if you have n 
>>>>> Rules in a Policy and decide you want "1-rule" Policies, then you 
>>>>> can simply change the parent Policy to a PolicySet and replace each 
>>>>> Rule with a Policy containing only that Rule. This will enable one 
>>>>> to effectively apply Obligations at the Rule level since all you 
>>>>> need to do is apply the Obligations to the Policy containing the 
>>>>> single Rule.
>>>>> I am not sure if that addresses the requirements as stated at 
>>>>> today's meeting, but would be interested to know if it does, or if 
>>>>> there are additional requirements that this would not cover.
>>>>>    Thanks,
>>>>>    Rich
>>>>> Erik Rissanen wrote:
>>>>>> All,
>>>>>> Could we get some more discussion on the open issues on the list 
>>>>>> so I could write up a tentative working draft in good time before 
>>>>>> the next meeting?
>>>>>> Having long technical discussions on the calls only is very 
>>>>>> inefficient. During the call today we spent 50 minutes discussing 
>>>>>> a single issue, and we had an almost as long discussion on the 
>>>>>> same issue last time. It would be much better if we could have 
>>>>>> more discussion on the list so we can make more decisions on the 
>>>>>> TC calls. Going like this means that we have many more months 
>>>>>> before we have a committee draft.
>>>>>> If I can get a rough direction on the following issues, I can edit 
>>>>>> the specs for review before the next meeting so we can hopefully 
>>>>>> approve them on the next call. Otherwise the whole thing is going 
>>>>>> to slip into the holidays and get delayed even more.
>>>>>> - Issue #66: policy combining. Should we fix the combining 
>>>>>> algorithm bias and should we extend the indeterminate?
>>>>>> - The small issues in the SAML profile. Can I get feedback on 
>>>>>> them? Hal has promised to fix the wording of the returned request 
>>>>>> in the SAML XACML Authz response.
>>>>>> - I also propose that we extend the schema so a Rule can contain 
>>>>>> obligations in the same way as Policies/PolicySets. This means 
>>>>>> that we avoid the need of rewriting rules into policies in some 
>>>>>> cases.
>>>>>> Best regards,
>>>>>> Erik
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]