atom feed30 messages in org.oasis-open.lists.xacmlRe: XACML TC Charter Revision - Strawman
FromSent OnAttachments
Damodaran, SureshJun 6, 2001 4:46 pm 
Hal LockhartJun 7, 2001 11:13 am 
Damodaran, SureshJun 7, 2001 12:20 pm 
Hal LockhartJun 7, 2001 2:36 pm 
Pilz, GilbertJun 7, 2001 2:44 pm 
bill parducciJun 7, 2001 2:54 pm 
Damodaran, SureshJun 7, 2001 4:34 pm 
Pilz, GilbertJun 7, 2001 6:25 pm 
Hal LockhartJun 8, 2001 7:12 am 
Hal LockhartJun 8, 2001 7:31 am 
bill parducciJun 8, 2001 9:20 am 
Hal LockhartJun 8, 2001 11:17 am 
bill parducciJun 8, 2001 11:33 am 
Hal LockhartJun 8, 2001 11:57 am 
bill parducciJun 8, 2001 1:22 pm 
Hal LockhartJun 8, 2001 2:08 pm 
bill parducciJun 8, 2001 2:31 pm 
Simon Y. BlackwellJun 8, 2001 8:18 pm 
Simon Y. BlackwellJun 8, 2001 8:49 pm 
Simon Y. BlackwellJun 8, 2001 9:04 pm 
Simon Y. BlackwellJun 8, 2001 9:19 pm 
Michiharu KudohJun 10, 2001 9:27 am 
Hal LockhartJun 11, 2001 9:44 am 
Ken YagenJun 11, 2001 11:36 am 
Hal LockhartJun 11, 2001 12:58 pm 
bill parducciJun 11, 2001 1:11 pm 
Simon Y. BlackwellJun 11, 2001 1:26 pm 
Carlisle AdamsJun 11, 2001 2:06 pm 
Simon Y. BlackwellJun 11, 2001 2:49 pm 
Carlisle AdamsJun 13, 2001 2:46 pm 
Subject:Re: XACML TC Charter Revision - Strawman
From:bill parducci (bi@parducci.net)
Date:Jun 8, 2001 9:20:46 am
List:org.oasis-open.lists.xacml

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