xacml — archive

[System <sblackwell@psoom.com>]

 MHonArc v2.5.2 -->
















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: RE: XACML TC Charter Revision - Strawman




From: "Simon Y. Blackwell" <sblackwell@psoom.com>
To: 'Carlisle Adams' <carlisle.adams@entrust.com>,"'xacml@lists.oasis-open.org'" <xacml@lists.oasis-open.org>
Date: Mon, 11 Jun 2001 14:51:57 -0700






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