RE: XACML TC Charter Revision - Strawman

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: RE: XACML TC Charter Revision - Strawman

Hi Simon,

----------
From:   Simon Y. Blackwell[SMTP:sblackwell@psoom.com]
Sent:   Monday, June 11, 2001 5:51 PM
To:     'Carlisle Adams'; 'xacml@lists.oasis-open.org'
Subject:        RE: XACML TC Charter Revision - Strawman

Carlisle,
 
Your comment "see little value (and potential harm) is sharing this information with the rest of the world" is exactly the issue we at Psoom are trying to get around. Agreed, the sharing of the denial information should be within some type of trusted environment. However, this is not to say that the subject who is being denied access is not the one to be trusted. We have several high value situations in which we need to expose to the subject the reason for denial. For the most part these situations can be reduced to things of the form "If you don't tell me that I need a $5,000 balance to access your services, how do I know what to do to comply?".  Access policy is not strictly a matter of security in the traditional sense of the word. Once again, we should leave the decision whether or not to expose policy to the expression of the policy itself. This could perhaps be done at some global level for a PDP, or perhaps it could be done at the specific policy level, e.g. deny access unless balance is above $5,000, and OK to inform of this condition.

 
I agree with your overall direction here, though perhaps not with the precise wording.  Specifically, "...we should leave the decision whether or not to expose policy to the expression of the policy itself".  This decision is really a kind of meta-policy, separate from the expression of the policy regarding this resource/action/etc..  One policy (X) says "deny unless balance is > $5,000."; a different policy (Y) says "you can show policy X to the requester under these circumstances...".  The PDP processes X in order to come to a decision.  Once the decision is made, it may then process Y in order to determine how much information to send along with the decision in the response.  Y doesn't have anything to do with the first task and X doesn't have anything to do with the second task; they are entirely independent in that respect.

I do agree with the changes of risk if one changes "Inform subject" to "Inform everyone else". However, I do not agree that "Inform everyone else" can be used as a second line substitute for "Inform subject". Perhaps a third line is needed. 

 
I don't know how it is possible to distinguish between "Inform subject" and "Inform everyone else" unless the information is encrypted (only) for the subject.  Given the common view of the architecture (i.e., PDPs talk to PEPs, and PEPs talk to subjects), it seems unreasonable to expect that PDPs will have (or be able to acquire) keys for all potential subjects so that information can be encrypted for these subjects.  This seems beyond the anticipated functionality of a PDP.  Therefore, I don't see a third row for "Inform everyone else"; I think this is identical to the second line.

Additionally, although I am not a security expert, it seems to me that exposing the reasons for allowing access to a subject may result in ongoing or faster compromise for some types of brute force attacks that involve multiple varying attack parameters. And, once again, I think the exposure decision should ultimately be up to the policy controllers, not those of us specifying the language for expressing the policy or even the protocols for access them.

 
As I mentioned above, I agree that this is not the job of those specifying the policy language.  (Whether XACML defines a way of expressing just X above, or both X and Y, is perhaps a decision this group should make.)  I also agree that it's not the job of those specifying the protocols, except to the extent that the protocols designed must have placeholders to carry this information (if it is to be conveyed in some environment).

Carlisle.

 

-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: Monday, June 11, 2001 2:05 PM
To: 'Hal Lockhart'
Cc: 'xacml@lists.oasis-open.org'
Subject: RE: XACML TC Charter Revision - Strawman





Hi Hal,

        ----------
From:   Hal Lockhart[SMTP:hal.lockhart@entegrity.com]
Sent:   Monday, June 11, 2001 4:02 PM
To:     'Simon Y. Blackwell'; 'xacml@lists.oasis-open.org'
Subject:        RE: XACML TC Charter Revision - Strawman

        In summary here are the four cells as I see them:

                                Allowed                                Denied
----------------------------------------------------------------------------
----------
                 |                         |
Inform PEP       |   SAML Requirement      |     Useful if condition can be
changed
                 |                         |
----------------------------------------------------------------------------
----------
                 |                         |
Inform Subject   |      Harmless           |             Possibly Risky
                 |                         |
----------------------------------------------------------------------------
-----------




Good summary.  I have a couple of comments.

Firstly, I don't know if the top left quadrant is actually a SAML requirement.  Certainly, there is interest in being able to send the justification for an "allowed" decision (along with the actual decision), but I don't recall this actually being mandated (especially since it has been agreed that very, very simple PEPs must be supported).  In any case, I certainly agree that it might be useful to allow the PDP to send the justification for both allowed and denied to the PEP.  So, I'd change the first cell to "May be useful for auditing purposes" and leave the second cell as-is (or perhaps add "May be useful for auditing purposes" to what you have).

The bottom row, however, should perhaps not be labeled "Inform Subject", but rather "Inform everyone else" (since I doubt that people are thinking of encrypting this policy information for the subject, for example).  Once we think of it as "Inform everyone else", then I think that both cells should be labeled "Possibly Risky".  Exposing the reasoning behind the PDP decision (whether the decision is "allowed" or "denied") gives information to a third party as to what they can try themselves in order to get an "allowed" decision.

In short, there may be value in sharing this information (confidentially) with a PEP, but I see little value (and potential harm) is sharing this information with the rest of the world.  An SSL-protected session between the PDP and the PEP might seem like a reasonable solution, but this leaves the information exposed at the PEP site once it exits the SSL pipe (similar to SSL-protected credit card numbers today).  Therefore, the proper solution may be to encrypt the information for the PEP within the SAML response message or decision assertion.

Carlisle.