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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: Re: XACML TC Charter Revision - Strawman


> I don't think (a) is a practical possibility. It either requires the PEP to
> understand the policies that apply (which seems an undesirable lack of
> encapsulation) or for the PEP to provide all possible evidence with every
> request. I don't think this is feasible from a performance standpoint in a
> distributed environment. It also leads to behavior which is unacceptable
> from a user's point of view, for example, requiring unnecessary
> Authentication.

agreed.

> > (b) provide all information involved in the decision regardless of the
> > contents of the request

> Assuming (b) I would be interested in understanding your specific concerns.
> Certainly integrity and confidentiality of the assertion can be provided if
> required.
> 
> There is a principle in an Authentication situation to avoid giving away
> information that would assist an attacker. However, I am not aware of a
> similar concern in the context of Authorization. In fact, it is frequently a
> requirement to accompany a negative response with an indicatication of how a
> user might be allowed access, for example by reauthenticating with a
> "stronger" method.
> 
> In the case of a positive response, I see no issue with informing the PEP
> (or subsequently a court of law) what criteria were used.

maybe i am just being overly cautious., but my concern comes from the
detail of the response. since security is composed of authentication,
authorization and [encryption], i would prefer that failure of
authorization be limited to a predefined list of failure types to limit
the exposure of one security aspect from antother. 'free form' specifics
may allow an intruder to determine which 'product' is being used to
perform the authorization (kinda like how nmap generates os profiles
based up network responses), and therby be able to apply a known exploit
selectively. there can be 500 hundred responses if need be for all i
care just as long as they are predefined.


on the upside to this approach is that it would create the ability for
the requestor to automate actions based upon defined negative responses
(ala http response codes). but i digress...

b


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


Powered by eList eXpress LLC