[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft BTG Profile
Hi Martin
On 30/11/2010 15:38, Smith, Martin wrote:
> John/David, et. Al--
>
> And another thought . . .
>
> I had suggested: " 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 exactly what we do in our implementation. We use a standard
XACML stateless PDP that does not understand BTG, and wrap it with a
stateful BTG wrapper that holds this database of BTG state variables. We
then need a way of communicating with the PEP about BTG things
(responses, requests to set/unset state etc). This is why we have
introduced the topic to the XACML group for standardisation, so that all
BTG implementations can use a standard protocol for PEP-PDP
communications rather then re-inventing their own ways of communicating.
regards
David
>
> We might think of the BTG "state" datum as a service (vs. element in a
> database); and such a service might be provided by a real-world physical
> device (a glass-protected alarm in this case) attached to the cloud,
> which when activated would sound an audible alarm, of course, and also
> make available its state ("glassBroken") if queried from the cloud by a
> PDP. Thus the "attributes" requirement for someone to update BTG state
> would be exactly what it already is: physical access to the alarm and
> ability to break the glass. (Sorry--no access audit!)
>
> Makes for a nice economical unity between real-world environment and
> cyber-decision-making.
>
> 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: Davis, John M. [mailto:Mike.Davis@va.gov]
> Sent: Monday, November 29, 2010 1:42 PM
> To: Smith, Martin; David Chadwick; Rich.Levinson
> Cc: Ludwig Seitz; xacml
> Subject: RE: [xacml] Draft BTG Profile
>
> This suggestion is appealing. It is general enough to support a number
> of specific instances and policies without requiring a point solution
> for a specific problem. There are a number of similar variables,
> constraints and other attributes associated with access to an object
> "purpose of use", "location", "separation of duty", "normal working
> hours" already part of access control decisions. Environmental
> variable, are one of the classes of access control decision information
> found in ISO 10181-3 (environmental is one, others including target or
> access request ACI might also be appropriate).
>
> It might even be possible to logically extend "BTG=yes" as environmental
> variable model any ACI variable associated with a policy that includes a
> BTG attribute.
>
> Regards, Mike Davis, CISSP
> Department of Veterans Affairs
> Office of Health Information
> Security Architect
> 760-632-0294
>
>
> -----Original Message-----
> From: Smith, Martin [mailto:Martin.Smith@DHS.GOV]
> Sent: Monday, November 29, 2010 10:00 AM
> To: David Chadwick; Rich.Levinson
> Cc: Ludwig Seitz; xacml
> Subject: RE: [xacml] Draft BTG Profile
>
> 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 would toss the whole thing outside XACML, 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
*****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]