Re: [xacml] Draft BTG Profile

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

Hi Martin

On 29/11/2010 18:00, Smith, Martin wrote:
> David, all--
>
> Why not model "BTG=yes" as an environmental variable, which is
> maintained as a resource (i.e., database) with appropriate access
> control (like "anyone in the hospital" or "a designated fire marshall or
> alternate") on updating it?

this is what we already do.

>
> This would toss the whole thing outside XACML,

exactly. This is where we are today. As my earlier post stated we would 
like to standardise this in order to provide portability and ease of 
implementation for applications.

regards

David


  and make it just one of a
> very large set of specific scenarios in which the PDP has to query an
> external (environmental) state (like "currentThreatLevel") maintained
> somewhere "in the cloud."
>
> Martin
>
>
> Martin F. Smith
> Director, National Security Systems
> US Department of Homeland Security
> NAC 19-204-47
> (202) 447-3743 desk
> (202) 441-9731 mobile
> (800) 417-6930 page
>
> -----Original Message-----
> From: xacml-return-2280-martin.smith=dhs.gov@lists.oasis-open.org
> [mailto:xacml-return-2280-martin.smith=dhs.gov@lists.oasis-open.org] On
> Behalf Of David Chadwick
> Sent: Monday, November 29, 2010 7:21 AM
> To: Rich.Levinson
> Cc: Ludwig Seitz; xacml
> Subject: Re: [xacml] Draft BTG Profile
>
> Hi Rich
>
> On 28/11/2010 20:41, Rich.Levinson wrote:
>> Hi David and Ludwig, et al,
>>
>> I have been following this discussion and it seems to simply revolve
> around
>> Policy definitions that Deny access under a given set of conditions,
>
> and state information. It is important to bear in mind which element is
> updating the BTG state (or attribute).
>
> If the PDP understands that BTG is a special attribute (or state
> variable) then it can act in a special way when it is mentioned.
>
> If the PDP does not understand BTG then no changes are needed to the
> XACML specification (scenario iii) below).
>
> There are 3 scenarios, namely
>
> 1) PDP understands BTG and keeps the BTG state
> ii) PDP understands BTG but does not keep the state
> iii) PDP does not understand BTG
>
> I believe that your description below is addressing scenario ii) only
> (correct me if I am wrong)
>
>    but
>> will
>> Permit access if there is that given set of conditions PLUS there is a
> BTG
>> indicator that can be checked and if its value is
> "glass-has-been-broken"
>> (BTG = true), then access is permitted:
>>
>>      * (given-conditions = true) AND (BTG = false) then Deny
>>            o + send back BTG as reason for Deny, and indicating
>>              obligations PEP has to tell user reason for denial and
>>              options user has to get access
>
> Rather I would say that these obligations are future obligations that
> the PEP must enforce if the user decides to BTG. If the user does not
> BTG, then no obligation enforcement is necessary. But if the user does
> BTG, then the state has to be changed by the PEP, and it is the changing
>
> of the state that requires these obligations to be enforced. If they
> cannot be enforced the state should not be changed. E.g. If the
> obligation says to log this and email the manager, and the PEP is not
> able to do this, then the glass should not be broken, since no-one can
> be informed about it and the user will not have any explaining to do
> later. (Note that in our design we have the concept of Fallback
> obligations which are to be performed if the primary obligations cannot
> be, in order to try to address this issue, but this is a second level
> issue to the current problem.)
>
>>      * (given-conditions = true) AND (BTG = true ) then Permit
>>            o + send back BTG indicating obligations PEP must enforce
>>              when in BTG = true state
>
> This is a very interesting take on the scenario. What you are suggesting
>
> here is that the BTG obligations should only be enforced when the user
> actually exits the hotel through the firedoor. What I am suggesting
> above is that the obligations are enforced when the user breaks the
> glass, regardless of whether he decides to subsequently exit the hotel
> or not. This is an interesting conceptual point that should be discussed
>
> further, because clearly it effects which obligations should be enforced
>
> when. It also effects how many times the obligations are enforced. In
> your scenario they are enforced for everyone who subsequently leaves the
>
> hotel by the firedoor, in my scenario they are only enforced on the
> person who breaks the glass. This again is an interesting conceptual
> point. If I exit a hotel via an open fire door, should I have to explain
>
> this later to someone. If I view a patient record, which is for say a
> VIP and someone has previously broken the glass for me, should I have to
>
> explain this later. If I break the glass on a VIP record but I do not
> actually view the record, should I have to explain this later to
> someone?
>
>
>>
>> I agree it wouild be useful to have a profile describing how to
> implement
>> this using standard XACML PolicySets, which, it seems to me can be
>> done in some fairly straight-forward manners using designated URIs for
>> AttributeIds and ObligationIds, the semantics of which can be
> implemented
>> by the PIPs and PEPs.
>>
>>      For example, if there is a special AttributeId = "...btg", and a
> trusted
>>      Issuer of this attribute, then the Policy can look for it within
> the
>>      context
>>      of the request.
>>      Similarly, a Deny response could use a profile-specific
> status-code or
>>      just some designated ObligationId to indicate there are
>>      AttributeAssignments
>>      with AttributeId URIs indicating what the PEP is supposed to do.
>>
>> Bottom line is I would want to understand what cannot be done w XACML
>> 2.0 with
>> a guiding profile using Attributes and Obligations, before defining
>> alternate means, which
>> might eventually prove to have needlessly added complexity to the
> specs.
>>
>> Currently, the XACML 2.0 spec indicates that a PEP should only make
>> specific decisions
>> if it understands any Obligations that are returned with the decision,
>> so it seems to me that
>> a trusted Attribute with the BTG state plus a set of appropriate
>> Obligations should be
>> sufficient for this use case.
>
> You are most probably correct. The reason I proposed Consequences in our
>
> draft instead of Obligations, was that they were future obligations on a
>
> subsequent action rather than the current one, whereas with your model
> above there is no need for future actions since you perform the
> obligations each time the user accesses the resource and not when the
> user breaks the glass.
>
> regards
>
> david
>
>
>>
>>       Thanks,
>>       Rich
>>
>>
>> David Chadwick wrote:
>>> Hi Ludwig
>>>
>>> On 26/11/2010 08:32, Ludwig Seitz wrote:
>>>> On Thu, 2010-11-25 at 17:05 +0000, David Chadwick wrote:
>>>>> 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).
>>>>
>>>> You claim your model represents the model of BTG in general. Can you
>>>> support these claims?
>>>
>>> Yes in so far as it has been implemented and we have not yet come
>>> across any BTG requirement that it cannot satisfy. So in that respect
>>> it is as general as the HL7 model (which is not a universal standard
>>> either)
>>>
>>>
>>>>
>>>> In a previous mail Mike Davis seems to suggest your model is
> different
>>>> from HL7's requirements, and currently the requirements from HL7 are
> as
>>>> close as it gets for "a model of BTG in general".
>>>>
>>>>> 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).
>>>>
>>>> I see no difference between a BTG state and a BTG attribute. Could
> you
>>>> please explain where you see a difference?
>>>
>>> Clearly none if the attribute holds the state!
>>> But in your attribute model you did not say how the attribute value
>>> was set to different values. This was added in our model.
>>>
>>>
>>>>
>>>>> 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
>>>>>
>>>>
>>>> I'm all in favor of a flexible BTG model, but from what you present
> here
>>>> I fail to see how that cannot be done within the current XACML (v3)
> core
>>>> standard.
>>>
>>> This is not the issue. The issue is, can we have a standard defined
>>> way of doing it. You suggest using Advice to signal BTG, so I say we
>>> should have a profile to standardise the contents of the BTG Advice.
>>> But I also request a standard way of doing it in XACMLv2 as well, and
>>> Advice cannot do that.
>>>
>>>
>>>> There is absolutely no requirement for a BTG attribute to be
> associated
>>>> with a specific subject or resource. What this comes down to, is a
>>>> question of attribute management, and that's outside the scope of
> XACML.
>>>
>>> Actually it is in a twilight world, since you have PIPs which manage
>>> attributes, but you dont describe how they work. So you sort of
>>> acknowledge that attribute management is needed, but then dont say
> how
>>> to do it. What we are wanting to do, is for a specific type of access
>>> control - BTG - is allow the XACML infrastructure (context handler,
>>> PIPs, obligation service etc) to manage the BTG attribute/state so
>>> that applications dont need to. But in order to do this we need to
>>> standardise more of the protocol between the PEP and the XACML
>>> infrastructure so that BTG can be handled by the infrastructure,
>>> thereby reducing the load on applications.
>>>
>>>> (note that I think BTG profile should nevertheless give
> recommendations
>>>> about how to do that).
>>>>
>>>
>>> which is what we tried to do in a general way in the draft profile.
>>>
>>>
>>>> My point remains: You seem to derive the necessity to make changes
> to
>>>> the core standard from your BTG model. I am not convinced they are
>>>> necessary to realize your BTG model.
>>>
>>> Clearly no changes are needed to XACML if you dump all the work on
> the
>>> PEP and the application. This is the status quo today. What we would
>>> like to achieve is that the application independent code can take
> some
>>> of the burden off the PEP. This is the motivation for the profile.
>>>
>>>>
>>>> There is a more important problem though: Before coming up with
>>>> solutions for BTG, we need a good definition of what the
> requirements
>>>> for BTG really are. Right now we are starting with a solution and
> are
>>>> trying to make the requirements fit, and that seems like a bad
> approach
>>>> to me.
>>>
>>> If you care to read our ACSAC paper you will find a set of
> requirement
>>> there which were derived from the hospital. So we started with a set
>>> of requirements and derived an application independent way of
>>> satisfying them.
>>>
>>> regards
>>>
>>> David
>>>
>>>>
>>>> /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

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