Re: [xacml] Draft BTG Profile

[David Chadwick <d.w.chadwick@kent.ac.uk>]

Hi Ludwig

The model you have appears to be that each user must BTG himself, and 
then he is given the BTG attribute after agreeing to this. But this is 
not the model we have, and it is not the model of BTG in general (e.g. a 
fire door in a hotel).

Our model is state based, ie. there is a BTG state that is initially 
false (corresponding to unbroken glass) and can be set to true 
(corresponding to broken glass) by a defined class of user in the policy.

Another class of user (typically a manager) can reset the state to false 
(ie repair the glass).

this model is much more general and flexible since it can be applied to 
individuals (as in your case) or to roles (e.g. doctors) or to any 
combination of attribute holding subjects. Furthermore the glass state 
can be applied to a single resource or a group of resources. To a single 
action or a group of actions. You can find details in last years ACSAC 
conference


http://www.acsac.org/2009/openconf/modules/request.php?module=oc_proceedings&action=summary.php&a=Accept&id=135

regards

david


On 25/11/2010 15:05, Ludwig Seitz wrote:
> On Thu, 2010-11-25 at 14:36 +0000, David Chadwick wrote:
>> Hi Ludwig
>>
>> answers below
> ...
>>>
>>> Hi David,
>>>
>>> I have some questions related to the proposed approach:
>>>
>>> 1.) You propose to introduce a new status code. Why not simply use
>>> Advice instead? It seems a bit superfluous to add new elements to the
>>> standard when there are suitable elements in the standard already.
>>
>> the whole purpose of standardising the status code is so that different
>> implementations can interwork without having to find out what the status
>> code or Advice element is that is being set by a particular PDP.
>>
>
> Yes but you can achieve the same effect by just standardizing Advice-ids
> in a profile, without adding new elements to the XACML-schema and
> without requiring new behavior.
>
>>> 2.) You propose to introduce a new element called<Consequences>. Why
>>> not use either Advice or Obligation with AttributeAssignments instead?
>>
>> We have used the syntax of Obligations, because this is what they are.
>> But with one difference. They are future obligations that will come into
>> effect if some future event happens. We did not want to call them
>> obligations, since the semantic of these is quote "An operation
>> specified in a policy or policy set that should be performed by the PEP
>> in conjunction with the enforcement of an authorization decision"
>
> Ok I guess then your approach with the "future obligations" is the one I
> don't see as necessary.
>
> Why not use this procedure:
>
> 1. Return an Advice "user can BTG" with the Deny decision
> 2. Offer the user to perform the BTG action. If the user chooses to do
> so, a new attribute for that user is created.
> 3. Resubmit the original request with the new attribute
> 4. Other policies matching the BTG attribute now permit access (possibly
> with Obligations requiring special auditing).
>
>>> General question:
>>>   From the document you provided I cannot see the necessity for
>>> introducing new elements into the standard. Could you try to explain
>>> which functionality are you want to achieve that cannot be realized with
>>> the existing features of the standard?
>>
>> 1. A standard way of specifying this response type. By its very nature
>> it needs to be in the standard.
>>
>> 2. A standard way of indicating future obligations.
>
> I still don't see the necessity for changing the standard to implement
> this use-case. In fact Swedish healthcare implements BTG policies using
> XACML and the approach sketched above. So I'll try to clarify my
> question:
>
> Given the fact that standardizing BTG in a profile is useful, why can it
> not be done without introducing new elements/functionality/behavior in
> the standard?
>
>
> /Ludwig
>

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************