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] Re: [EXTERNAL] [xacml] Default behavior for unrecognized resource attributes?


Hal, all--

Agree with your point that standards are missing as to how "access-relevant" resource metadata can be identified as such, located and retrieved. (That's why I was asking about "common practices" in this area a while back.) 

I'd be interested in a bit more on how a DDOS attack might be enabled . . .

It may be possible to get the result I'm looking for by pre-query-time processing in the PAP.  Not sure how that would work or if there is some NP-type problem that might arise. (In fact, I have a vague recollection that the NIST "Next Gen" work we discussed last call was originally focused on methods for exhaustive testing of digital-policy consistency. If so, they apparently wandered off that problem. <g>)

Thanks for the feedback,

Martin






On Thu, Jan 7, 2016 at 11:58 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

I am just catching up with this thread.

 

I think there are at least two separable issues which have become a bit entangled.

 

1. what is needed and how best to accomplish it.

 

2. whether it is a reasonable requirement, or alternatively how common is this environment.

 

In the earlier discussion, I largely ignored #2. The idea of a Profile is that it is a set of functionality which is seen as useful by all or some members. It is optional for anyone to support a Profile even if they support the core. Before a Profile (or any spec) becomes an OASIS Standard, we need 3 Statements of Use, which is intended to demonstrate there is at least some level of interest in actually using it.

 

IMO, one can object to a Profile that forces mandatory behavior which is seen as harmful or interferes with other mechanisms you depend on. Or you can object on technical grounds that the proposed scheme will not function as described. Alternatively, you can object because you want to use the Profile, but the proposal does not contain features you need. However, it is rarely necessary to object on the grounds that nobody needs it.

 

Therefore I will focus on #1.

 

Let’s start with the basics. In XACML Attributes are all we know about anything. Everything that a policy can use as data is an Attribute of something. XACML merely assumes that the Attributes we need are somehow available in the environment. In practice they usually come from existing, non-xacml sources, which make them available by preexisting means which we have no way to influence. For example, a file as a resource would have a name, modification data, size, owner among other data. The means of obtaining attributes of all kinds for a given sort of Resource (or Subject) will probably be the same.

 

My conclusion from this is that to do what Martin wants, whether at policy deployment time or at decision time will require some kind declarative mechanisms that says “these are the attributes/values” which are critical to access control and the others are not. I see no way for the PDP or context handler or PAP to make this distinction, nor any way to insure that only one or the other type is present when attribute values are obtained from their sources.

 

XACML attributes can be single valued or multi-value. The way information is encoded in attributes is not specified by xacml for the simple reason that they usually exist in advance of their use in policies and typically it is not possible to change their structure. For example, suppose there are properties Red, Green, Blue associated with resources. This could be represented in at least 3 ways: 1) Single value enumerated attribute called color can contain  Red, Green or Blue, 2) Three different attributes called Red, Green & Blue each of which may be present or absent, and 3) a multi-value attribute which may contain the values Red, Green & Blue zero, one or more than one time each.

 

So for starters the question is whether to cover all of these cases or just some and what specifically should the rules be for each supported case. In particular is it sufficient to perform some test on an attribute or do we have to check for all the legal values or just check at least one.

 

Now consider the xacml policy evaluation process. A policy package contains a bunch of policies the PDP trusts, but just by looking at them it is not possible to determine which ones will be used for a particular decision or even if they will ever be used. Only when a request is processed then if the tests in the Target and Condition are true, the policy will be deemed applicable. Then the applicable policies’ Effect will be combined to produce a decision. At that point , that is in the context of a particular request) we have three types of policies: 1) Inapplicable, 2) Applicable with same Effect as the decision and 3) Applicable, but with a different Effect as the decision.

 

So here we need to decide do the checks of critical attributes in policy need to occur in Set 2 or both Set 2 and Set 3?

 

I believe answering these questions will clarified the desired functionality.

 

Turning to implementation, I agree it is very desirable to do this analysis at policy testing/deployment time not at decision time if at all possible. It seems a bad practice to halt all access to a resource because we discovered a policy bug at decision time. This could conceivably create a DoS attack in some environments. Further many environments have latency requirements for policy decisions.

 

The approach I mentioned last year was to perform semantic analysis on the policies and determine if certain information was checked under specified conditions. I believe it would also be possible to assert conditions that you believe will always true about your policies. This would be more general that Martins cases, but would also make it possible to detect policy errors.

 

At one point Axiomatics was offering a semantic analysis tool, developed by another company, to analyze policies. I don’t see it mentioned on their web site now, so perhaps that approach has been abandoned. Can Erik or David or anybody from Axiomatics comment on the experiences with this?

 

 

Hal

 

 

From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Thursday, January 07, 2016 3:54 AM
To: Martin Smith
Cc: XACML TC
Subject: Re: [xacml] Re: [EXTERNAL] [xacml] Default behavior for unrecognized resource attributes?

 

Martin,

Ok, then I have misunderstood you a bit. I thought that you meant that an attribute was referenced at runtime evaluation, not just that the policies reference it somewhere. I don't think that changes the discussion much though. The same kind of arguments can be made that an attribute might be irrelevant and legitimately ignored by the policies as a whole because the attribute is relevant only in some other context.

As for you looking for "any mechanism, performed by the PDP or elsewhere, that will assure that all resource attributes are referenced by some rule in the set of policies applied to a decision", then that is something which is not present in the XACML standard.

Best regards,
Erik

On 2016-01-05 20:19, Martin Smith wrote:

Eric--

 

Let's drill down on what is meant by "used."  Let's say that a regulation says that if ANY of three conditions (rules A, B or C) is met, then the resource may be accessed.  Let's say that rule B is not met and (by itself) would result in a DENY, but rule A is met and thus the overall outcome is PERMIT.  Is rule B "not used"?  

 

I tried to avoid this ambiguity by proposing that the set of rules collected to process a request must contain at least one rule that refers to each of the access-related attributes associated with the protected resource. Just because the set of "active" rules includes one or more rules that do not affect the decision regarding the current request by the current user in the current environment. doesn't mean those rules are irrelevant. At query time, relevancy is determined by the resource attributes; which resource attributes are required to be associated with which resources is determined at "design time", when the policies are developed by governance authorities.

 

Regarding "what the PDP does not know": an interesting viewpoint. My understanding is that what the PDP knows is (a) a set of policies loaded from the PAP; (b) the Request Context provided by the Context Handler; and (c) additional subject, resource or environmental attributes the PDP may request via the Context Handler. 

 

My initial thought as to how the PDP might implement the goal of accounting for all resource attributes was for it to request "All" resource attributes. (This is not supported in the current spec as I read it.) My understanding (but I certainly could be wrong) is that the PDP will identify all Policies with a Rule that references any attribute of the requested resource. In addition, my thought would be that the PDP should check that all the resource's attributes are referenced by some rule to be applied to the current request, and if not, then issue a Deny decision, perhaps with explanation. I do not think this checking function can be performed by anything is the current spec. Both the gathering of all resource attributes and the checking and Deny decision would be a selectable option by the implementing organization. 

 

All this said, I repeat that what I'm looking for is any mechanism, performed by the PDP or elsewhere, that will assure that all resource attributes are referenced by some rule in the set of policies applied to a decision. 

 

I agree with your statement (as slightly amended): "The current XACML spec simply assumes that you are operating with the correct policies. What you are looking for is some extra information to detect some cases where a mistake has been made in the deployment and the policies [or the applied resource attributes] are not correct." 

 

Regards,

 

Martin

 




--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile


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