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" <>
To: 'Carlisle Adams' <>,"''" <>
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
