RE: XACML TC Charter Revision - Strawman

["Simon Y. Blackwell" <sblackwell@psoom.com>]

Title: 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 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. Although, I can also envision situations in which "Inform subject" could be risky if the access control mechanism is being used to provide apparently random access to subjects where we don't even want them knowing how to duplicate their successful access in the future.

 

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.

 

Simon

 

 

-----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.