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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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


Subject: Public Comment


Comment from: rgrzywinski@yahoo.com

I have clarified a number of ambiguous points in the initial document that I sent based on Anne's comments.  I doubt that my clarifications will change any resulting responses but I felt that they were necessary.

Initial note:  

-  I know that XACML is not a protocol specification.  The reasons for this note will be evident as you read on.
-  Rhere are three kinds of assumptions:
   -  [Rob]:  assumptions made by me and can be refuted but are necessary for understanding of the associated questions / concerns
   -  [Use]:  assumptions that are necessary for a particular use case.
   -  [Spec]:  assumptions defined by the specification.  If the are untrue, please let me know, but use them as assumptions for the associated questions / concerns.
-  The use cases provided are used to either backup a point that I am making or to add an additional "thought point" that may not have been considered previously.
-  "IFF" is used to mean "if and only if"
-  I have added a "*" to denote new / changed sections that from the initial post.  This is not to say that you shouldn't re-read the entire document, but to facilitate finding deltas, I added the marker.


-------------------------------------------------------------

o  Attributes 

   *Assumptions [Use]:  the PEP is separate (linked via network) from the PDP (and potentially any context handler)

   *Background:  It is -implied- throughout the specification that the attributes that comprise the set of all attributes that are required from the PEP from the PDP (-not- including those from other sources) required for a decision request are passed from the PEP to the PDP in the <Request>.  

   Question:    Since it is not possible for the PEP to know a priori what attributes are required, nor is it feasible to include every possible attribute, (as some may be expensive to compute or too large to send) what is the current thinking for the retrieval of these attributes?  

   Possible solution 1:  Figure 1 shows an attribute query from the context handler to the PIP.  It is possible for a PIP to exist on the same machine as the PEP and an out-of-band query is perfomed from the context handler to retrieve any required attributes.  This would imply that the communication is outside of the realm of the XACML spec.  
   
   *Follow up:  The addition of a statement (perhaps in one of the examples) indicating that it may be necessary to retrieve other attributes from the PEP that are not present in the <Request>, may resolve this issue.  This additional statement appears to be in scope given sections 2.5 and 2.7.
      This proposed statement would serve only to ensure that the generality that you are trying to achieve with respect to attributes is assured in this case.  In other words, I have obviously interpreted the specification's intent incorrectly in this case.  If I've done it, then it's likely that others will do also.  Extending line 580, for example, to include the possibility of the PIP retrieving additional resources from the PEP would go a long way to rectify this.  
      The spec clearly explains that there may be attributes that are not present in the <Request> that are needed by the PDP (I only mention this for clarity).

   Possible solution 2:  A second request / response is added to the existing communication that would query for the required attributes.  This is an in-band solution and would increase the scope of the current specification which is likely not desired.

   Use case:  Policy associated with a decision request includes a QoS component from the PEP (such as the load average of the machine on which the PEP resides).  The QoS attribues are too expensive to compute (and whose computation may actually affect the QoS) and send with each <Request>.

   Use case:  A PEP is located within an MTA (mail transport agent).  Some policy decisions are made on Bayesian filter results of the email message.  These results are too expensive to compute for each email and the email contents are too large to send with each decision request.  These attributes should be requested from the PEP IFF a condition requires them.

o  Obligation scope

   Part 1:

     Background:  The specification states that obligations will be carried out on the PEP and that if "the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource" (section 6.10).

     *Assumption:  
           [Use] The PDP logs all authorization decisions for auditing.
           [Use] QoS policy decisions are made based on -actual- results of authorization decisions.

     Question:  How does the PEP inform the PDP of the -actual- decision?

     Possible solution 1:  An out-of-band response is sent from the PEP to the PDP.  This would imply that the communication is outside of the realm of the XACML spec.  This approach reduces the affinity of the actual decision from the initial decision request causing potential auditing problems as a second communication channel needs to be authenticated and maintained.
 
     Possible solution 2:  A follow-up response is made from the PEP to the PDP.  This is an in-band solution and would increase the scope of the current specification.  Addressing this issue in the specification as a "protocol issue" may clear up any ambiguities.

     *Follow up:  Here's the problem that I keep having to fight with:  
        The motivation states (section 2.0):  "there is a pressing need for a common language for expressing security policy".  This is one concept.  That same paragraph of 2.0 goes on to state "a common policy language allows the enterprise to manage the enforcement" and it outlines the scope of what it is to "manage" the policy.  Nothing is said to imply that XACML will make the foray into the "manage" part.
        Section 2.1 expands the scope including the notion of request / response and decision (implying evaluation)  (i.e. communication, evaluation, and enforcement, none of which is part of management).  This is another concept.  
        So which is XACML?  A "language for -expressing- security policy" or a language for -communicating- security policy.  Or both?
        Short aside:  when I first found XACML I thought "Great!  The PCIM generalized and put into XML.  This is perfect for my needs."  Then I find tags such as "<Request>" and "<Response>" and I began to get quite confused -- a confusion that still continues today.
        The reason that I have digressed so far is to outline my current state of confusion on points such as the question presented in this part.  If XACML -is- a communication language then the question is in scope.  If XACML is not, then "<Request>", "<Response>", etc need to be reconsidered.

   Part 2:

     *Assumption:
         [Spec] Lines:  1768 - 1770, 2731 - 2733, 2756 - 2757, 2859 - 2862
         "It MAY include a set of obligations that MUST be fulfilled by the PEP.  If the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource."
         [Spec] Line: 591 (non-normative)
         "The PEP fulfills the obligations."
         [Spec] The attribute name "FulfillOn"

     Question:  Has there been consideration to change the language from "does not understand" to "does not understand or cannot fulfill"?  If not, what is the recommended action for an obligation that is understood yet is unable to be fulfilled.

     Possible Solution:  Expand the definition of "understood" to include compliance meaning that an obligation is "understood" IFF it can be interpreted and has all necessary attributes (the traditional meaning of "understood") -and- fulfilled.

     Follow up 1:  lines 3060 - 3062 use the "fulfill" terminology.

     Follow up 2:  the mixing of the terms "understood" and "fulfill" in multiple contexts leads to much ambiguity.

   Part 3:

     *Assumption: 
         [Spec] Obligations are fulfilled on the PEP.  
         [Rob]  I should point out that the specification does not say that the obligations -cannot- be carried out elsewhere, but I will assume that obligations are only fulfilled on the PEP.
         [Rob]  It is implied that the obligation is fulfilled at the time of the response in order for the PEP to potentially deny authorization.  In other words, to be able to associate meaning with the statement "If the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource" then there must be a clearly defined and consistent cause and effect in order to be deterministic.  (This all pertains to question 2 below.)

     Question 1:  Can components, other than the PEP, fulfill obligations?  And if not, has any consideration been given to extending obligations to other components?

     Use case:  The PEP for a web service is located on a web server.  An obligation requires that a record from a data store (which is located on a separate machine) is deleted.  The PDP dispatches the obligations to a central "obligation service" which then dispatches the obligation to the data store.

     *Follow up 1:  The use case outlined above is technologically -possible- given figure 1 of the specification.  The concern is that it is not -feasible- for one primary reason:  a PEP, located in a DMZ, cannot be trusted to initiate such requests back out of the DMZ.  The PDP would be a better choice.

     *Follow up 2:  Anne has stated "XACML does not specify or constrain such an implementation" and my point here is that it does.  By -only- allowing the PEP to understand and fulfill obligations you are severely limiting the usefulness and application of XACML.
        I should point out again that herein lies much of my confusion surrounding the XACML specification.  If XACML is only defining a language for -expressing- policy then the specification should not make assertions as to where obligations are to be understood or fulfilled. 
        If the committee does not feel that XACML should dictate where and when obligations should be enforced, then please make this clear in the spec as it is currently leaning away from this.

     Question 2:  Has there been any consideration to delayed obligations and their effect on the ability for a PEP to deny an access based on their result?

     Use case:  The obligation is to delete a record after a period of 30 days.  (This was derived from the P3P specification.)

     *Follow up:  I understand that -expressing- the use case in XACML is possible and I understand that it is an implementation detail to have an obligation service fulfill the obligation.  My assertion is that the statement "if the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource" limits the PEP to understanding (and fulfilling) obligations that do not have a delayed component to them.  One can imagine a case where a delayed obligation is not -understood- until the time at which is it applied.

   Part 4:

     Lines:  2076 - 2077 compared with 1768 (for example)
     "The <Obligations> element SHALL contain a set of obligations that MUST be fulfilled by the PDP in conjunction with the authorization decision."

     Question:  This appears to be in conflict with the other normative sections of the specification.  There are no other references to the PDP fulfilling the obligations and appears to be in conflict with 5.35.  Is this a typo?  It is possible that I'm overreading this but the phrase "by the PDP" appears to be in reference to "MUST be fulfilled".

---

* The following items have been added after receiving Anne's comments and attempting to clarify myself to ensure that my intent has been voiced clearly.

 o  General specifications comments

   -  In order to preserve continuity between 2.1 and 2.2 - 2.12, it may be better to change 2.2 to 2.1.1. 2.3 to 2.1.2, etc..  If this is undesired then perhaps adding the section numbers in the bulleted list in 2.1 would be in order.

   -  For individuals not familiar with obligations, the over-use of the term "action" in 2.12 is very confusing.  I understand that by "action" not being in a different type-face that it is not the defined meaning, but perhaps emphasis of this fact with an explicit statement would be in order.  This would enforce it is not an oversight.  A better solution would be to not use the word "action" but a suitable alternative would have to be chosen carefully.

   -  There is much allusion to the contract between the policy writer, the PAP, the PDP and the PEP.  Anne's comments have added to this.  I feel that a more formal definition of this contract needs to be made.  I do not imply that XACML would specify the language of the contract but I do think that the specification needs to outline the scope of the contract.  For example, EPAL defines the notion of "vocabulary".  By simply defining the fact that a "vocabulary" is needed sheds much light on this contract.

   -  My vast confusion with respect to the scope of XACML was defined in the follow up of part 1 of "Obligation Scope".  I feel that others have the same confusion and this can be seen in EPAL's use of only a potion of XACML.  (Of course this is only my interpretation.)

 o  LDAP

   -  Is there any reason that the LDAP profile does not use, extend or mention the PCIM (or PCIMe)?  If there is more than a one sentence reason, then I'm not curious enough.  :) 
   
 o  Final thoughts:  Products up to this point (this is an overgeneralization but I'm trying to make a point) has been concerned with the "effects" (used as defined in the spec) of policy.  Products today are just beginning to introduce the notion of "actions" (used as defined in the spec) and 2004 - 2005 will be their time.  "Obligations" (as per spec) and "purpose" (as per the EPAL spec) are tomorrow's concepts and will be where all of the focus is placed.  By introducing them into the spec you have added the snowflake that causes the avalanche but I feel that they are the weakest (most confusing, ill-defined, contradictory, etc) part of the specification.  I guess that all I'm trying to say is:  be careful and be diligent because the work that you do today is going to define the next major change to the way that industry handles policy.


Thank you for your time and thank you for all of the hard work that has been put into XACML.



--
Rob Grzywinski



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