[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Groups - xacml-3.0-administration-v1.0-wd30-diff.doc uploaded
Hi Erik, On 31/10/2014 8:36 PM, Erik Rissanen wrote:
Hi, Regarding "discarded" or "NotApplicable", we discussed this in the past and we concluded that discarding is more correct since if the policy is not authorized, then it should be treated as if it did not exist.
Okay.
However, the usage of "discarded" by the draft needs cleaning up to accurately
express the intent.
In Section 1.2:
Reduction
the process by which the authority of a policy associated with an issuer is verified or discarded.
We're not discarding the authority of a policy. This should read something like
(also taking the opportunity to establish what "discarded" means):
Reduction
the process by which the authority of a policy associated with an issuer is verified. The value of an unauthorized policy is discarded before combination, i.e., an unauthorized policy is treated as if it did not exist in the policy set.
There's a number of places where the text talks about discarding policies
where it should talk about discarding the value of the policies.
In Section 3:
If the authority of the policy issuer can be traced back to the trusted policies, the policy is used by the PDP, otherwise it is discarded as an unauthorized policy.
The sentence should read:
If the authority of the policy issuer can be traced back to the trusted policies, the value of the policy is used by the PDP, otherwise the policy is unauthorized and its value is discarded before combination.
In Section 4.6:
The evaluation of a policy set is done as in [XACML], with the exception that the contained policies are possibly reduced and/or discarded, before combination, as defined by the following table.
This sentence should read:
The evaluation of a policy set is done as in [XACML], with the exception that the contained policies are possibly reduced and/or their values discarded, before combination, as defined by the following table.
In Sections 4.8 and 4.9:
If it was not possible to reach a trusted policy with either search, the policy P is discarded and not combined in the policy set.
In both cases, this sentence should read:
If it was not possible to reach a trusted policy with either search, the value of policy P is discarded and not combined in the policy set.
My revision to Section 10 should read:
A policy, P, that evaluated to “Indeterminate{DP}”, “Indeterminate{P}” or “Indeterminate{D}” in the policy set, MUST be reduced as follows in this section.
Form a reduction graph as described in section 4.7.
If and only if policy P evaluated to “Indeterminate{DP}”, perform two graph searches. For the first search, start from the node corresponding to policy P and follow only PP and PI edges. For the second search, start from the node corresponding to policy P and follow only DP and DI edges. If both searches reach a node that corresponds to a trusted policy (not necessarily the same node), then policy P is treated as “Indeterminate{DP}” in combination of the policy set; otherwise, if only the first search reaches a node that corresponds to a trusted policy, then policy P is treated as “Indeterminate{P}” in combination of the policy set; otherwise, if only the second search reaches a node that corresponds to a trusted policy, then policy P is treated as “Indeterminate{D}” in combination of the policy set; otherwise, the value of policy P is discarded.
If and only if policy P evaluated to “Indeterminate{P}”, start a graph search from the node corresponding to policy P following only PP and PI edges. If it is possible to reach a node that corresponds to a trusted policy, then policy P is treated as “Indeterminate{P}” in combination of the policy set; otherwise, the value of policy P is discarded.
If and only if policy P evaluated to “Indeterminate{D}”, start a graph search from the node corresponding to policy P following only DP and DI edges. If it is possible to reach a node that corresponds to a trusted policy, then policy P is treated as “Indeterminate{D}” in combination of the policy set; otherwise, the value of policy P is discarded.
The following paragraphs are still retained unchanged.
In all graph searches, the maximum delegation depth limit MUST be checked as described in section 4.11.
In all graph searches obligations must be collected as described in section 4.12.
Note (non-normative): This process is designed in this way because it is important to reduce “Indeterminate” results before combining them. An unauthorized “Indeterminate” can be used as an attack by forcing the PEP into error handling, and possibly denying or allowing access depending on the bias of the PEP. Intuitively we test if the policy would be authorized if it would have been “Permit” or “Deny”. If neither a “Permit” nor a “Deny” would have been authorized, the policy is not authorized, so the “Indeterminate” is discarded.
For the current combining algorithms there is no difference, but it is conceivable that there could be combining algorithms where an N/A may be significant. For instance, imagine a voting based combining algorithm which requires that at least X percent of the policies in the policy set agree. In that case, adding unauthorized N/As to the combining algorithm could change the end result, and would be a potential attack vector.
Just as an aside, such a combining algorithm would be a bad idea for a policy set to which delegates are allowed to add their own policies. An authorized delegate could bias the result by adding multiple copies of their policies. Regards, Steven
Best regards, Erik On 2014-10-30 07:23, Steven Legg wrote:Hi Erik & Hal, On 30/10/2014 12:59 AM, Erik Rissanen wrote:Hi Hal, Thanks. I understand the intent and it's correct as I can see. Section 4.10 could perhaps be formulated in a more clear manner by structuring it based on the three indeterminate cases:I agree, especially in regard to describing the extended indeterminate value for policy P, which the new draft doesn't do.Indet{DP}: first follow PP or PI edges. Then search again and follow DP or DI edges.If both searches are successful, then policy P is treated as "Indeterminate{DP}"; otherwise, if only the first search is successful, then policy P is treated as "Indeterminate{P}"; otherwise, if only the second search is successful, then policy P is treated as "Indeterminate{D}"; otherwise, policy P is treated as "NotApplicable". Note that the current text talks about discarding policy P when graph searches fail, but combining algorithm definitions have cases for policies that are "NotApplicable" rather than cases for policies that are discarded, so I think it is more appropriate in this profile to use 'treated as "NotApplicable"' instead of 'discarded'.Indet{P}: search once and follow PP or PI edgesAnd if the search is successful, then policy P is treated as "Indeterminate{P}"; otherwise, policy P is treated as "NotApplicable".Indet{D}: search once and follow DP or DI edges.And if the search is successful, then policy P is treated as "Indeterminate{D}"; otherwise, policy P is treated as "NotApplicable". In section 4.8, this statement: "If it possible to reach a trusted policy in this manner, the policy P is treated as “Indeterminate” in combination of the policy set." should read: "If it is possible to reach a trusted policy in this manner, the policy P is treated as “Indeterminate{P}” in combination of the policy set." Note also the missing "is". In section 4.9, this statement: "If it possible to reach a trusted policy in this manner, the policy P is treated as “Indeterminate” in combination of the policy set." should read: "If it is possible to reach a trusted policy in this manner, the policy P is treated as “Indeterminate{D}” in combination of the policy set." Regards, StevenBest regards, Erik On 2014-10-28 20:10, Hal Lockhart wrote:The new text is based on Steven’s comments from June 2011: https://lists.oasis-open.org/archives/xacml-comment/201106/msg00004.html See Issue 98 in the wiki. Please check to see if I got it right. Hal *From:*Erik Rissanen [mailto:erik@axiomatics.com] *Sent:* Tuesday, October 28, 2014 10:38 AM *To:* xacml@lists.oasis-open.org *Subject:* Re: [xacml] Groups - xacml-3.0-administration-v1.0-wd30-diff.doc uploaded Hi Hal, I did a quick review and most of the changes are fine I think. The one to be careful about I guess is the extended indeterminate in the reduction algorithm. Was there previous discussion about that on the list, which could be reviewed to understand the thinking behind the solution? Best regards, Erik On 2014-10-17 17:41, Hal Lockhart wrote: /Submitter's message/ Diff file -- Hal Lockhart *Document Name*: xacml-3.0-administration-v1.0-wd30-diff.doc <https://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=54337> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-----
*Description* Differences between WD 29 and WD 30 Download Latest Revision <https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/54337/latest/xacml-3.0-administration-v1.0-wd30-diff.doc> Public Download Link <https://www.oasis-open.org/committees/document.php?document_id=54337&wg_abbrev=xacml> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-----
*Submitter*: Hal Lockhart *Group*: OASIS eXtensible Access Control Markup Language (XACML) TC *Folder*: Specifications and Working Drafts *Date submitted*: 2014-10-17 08:41:02
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]