[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]