[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] BTG comment
Hi Paul, I am not sure I understand the objections you are raising. I have put comments inline below, trying to respond to the points you have made. As I have indicated in prev emails, I believe the proposal is using standard mechanisms and not introducing any "state" to the PDP, other than the implicit state of the request context which already exists, nor is it doing anything significantly different from techniques we have already used in the RSA 2008 Interop, where we had policies for emergency conditions based on an emergency-override attribute that a subject could obtain thru some external mechanism from a trusted authority that could then be submitted with the request. If you are interested the details of that Interop are in the XACML Repository: http://www.oasis-open.org/committees/document.php?document_id=28030&wg_abbrev=xacml (In the doc description of the zip file at the above URL, it is item #2 that contains the specification with details of requests and responses and policies in section 2.2.4 that describes the "Emergency Access Use Case".) Thanks, Rich Tyson, Paul H wrote: 3898C40CCD069D4F91FCD69C9EFBF096060512EB@txamashur004.ent.textron.com" type="cite">In the proposed approach, there is only one request context, which is initially populated byErik seems to appreciate my objection to David's BTG proposal, which has nothing to do with stateful or stateless PDPs, but with my desire to restrict (or at least not to sanction) the use of the request/response mechanism to directly change attribute values in the request context. the request from the PEP. It can subsequently have "additional" attributes set during Policy evaluation if a referenced attribute is not present and the PDP calls out to a PIP to supply the attribute. The response does not get created until policy evaluation has completed, and once created, the request context is no longer used for anything. i.e. I don't understand what you mean when you refer to your "desire not to sanction the use of the request/response mechanism to directly change attribute values". That is not what is happening here. The original attributes are left intact. Additional attributes may be "read" from a PIP. 3898C40CCD069D4F91FCD69C9EFBF096060512EB@txamashur004.ent.textron.com" type="cite">I think that is exactly what the proposal is. The "StateDB" would generally sit behind a PIP andIf one wants to analyze the request context one should only have to look at how the PIP is implemented (and of course the attribute instances conveyed by the original request). Introducing a distinguished action-id value or specialized attribute id that has the power to modify the request context makes it harder to analyze. The only virtue of this approach is convenience, and it seems a slim virtue at that. It should be possible to set up a 3rd-party service that can communicate with the PEP and PIP as necessary to set and retrieve BTG state. the Policy can request the BTG state attribute, or the PEP can get it in advance and send it in. 3898C40CCD069D4F91FCD69C9EFBF096060512EB@txamashur004.ent.textron.com" type="cite">I don't believe there is anything in this proposal at variance with this. All information is comingThe patient's medical condition, whether or not the building is on fire, and the client's bank account history are all things that are outside the scope of XACML. Information about them should come into the XACML system in the normal ways: either from a trusted source via the PEP, or a PIP. in normal ways thru trusted PEP or PIP. 3898C40CCD069D4F91FCD69C9EFBF096060512EB@txamashur004.ent.textron.com" type="cite">Regards, --Paul -----Original Message----- From: Davis, John M. [mailto:Mike.Davis@va.gov] Sent: Friday, March 18, 2011 13:34 To: Rich.Levinson; Erik Rissanen; David Chadwick Cc: xacml@lists.oasis-open.org Subject: RE: [xacml] BTG comment I think we are agreed. The attributes of the StateDB can refer to both the policy set and the attribute used to evaluate the request, eg. "Normal Healthcare Rules", or "BTG Rules" plus "Normal Healthcare attributes" or "BTG Attributes". The implication is that the user request would include the requester purpose of use (setting the state), and associated attributes which combined with existing attributes about the (from various sources) relative to that POU allows for decision. User asserted information, and in particular purpose of use, is included in the XSPA profiles of XACML, SAML and WS-Trust as a mandatory attribute. Regards, Mike Davis, CISSP Department of Veterans Affairs Office of Health Information Security Architect 760-632-0294 -----Original Message----- From: Rich.Levinson [mailto:rich.levinson@oracle.com] Sent: Friday, March 18, 2011 10:13 AM To: Erik Rissanen; David Chadwick Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] BTG comment Hi Erik, Paul, Mike, Hal, and David, I believe David's position: http://lists.oasis-open.org/archives/xacml/201103/msg00017.html is consistent with the position I recommended: http://lists.oasis-open.org/archives/xacml/201102/msg00042.html and originally, when this discussion began last year: http://lists.oasis-open.org/archives/xacml/201011/msg00040.html so, I think David and I are pretty much in agreement on the concepts at this point. The bottom line is that any "state" that is evaluated by the PDP policies is contained in the request context in attributes. Who maintains those attributes and how they get into the request context is dependent on the system designers, and the Policy designers. But the PDP, itself, should not require any changes from XACML 2.0 or 3.0 to implement this. From my perspective, "StateDB" is nothing more than an attribute repository, whose attributes can be referenced in Policy statements. Also, from my perspective, a "profile" might be useful, but is not required for anyone to use this system design strategy with either XACML 2.0 or XACML 3.0. Thanks, Rich Erik Rissanen wrote:Paul, all, I am not sure if there is a motivation for it, but there would be a need for an XACML state component if the desired behavior is that "state is changed when an access decision says Permit" (Or deny). Thisis distinct from "state is changed when an access to a resources is performed". In the bank case, clearly it should be the latter case, that is, the PEP enforces the Permit, by which the banking application will change the amount in the account. I cannot think if a specific real world example of the case where the decision by the PDP itself would cause a state change. Also It might be useful from a purely practical implementation point of view though. Not sure. Anybody? Best regards, Erik On 2011-03-15 21:42, Tyson, Paul H wrote:The 3rd example differs from the previous 2 in that the XACML requestissimultaneously *changing* the request context and requestingpermissionto perform an action. Nothing in the XACML spec prevents this (as far as I can see), but it overloads the request message unnecessarily. I would not want to sanction this behavior in an official profile. I believe itsimplifiesanalysis to assume that the request/response sequence is idempotentwithrespect to the request context. Nothing prevents an implementation from using other communication channels to modify the environment to cause a change in theevaluationcontext. In the bank account examples, it would seem a very poordesignto make the XACML system update account information--surely thathappensoutside of the XACML system. Each time a request is received, it evaluates with new values for withdrawal amount and frequency. Why shouldn't the same design principle apply to a BTG attribute? I raised this and other concerns in my note of 22 February 2011: http://lists.oasis-open.org/archives/xacml/201102/msg00037.html. Regards, --Paul -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] Sent: Tuesday, March 15, 2011 15:10 To: Davis, John M. Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] BTG comment <<<first 2 examples omitted - pht>>> All you need is thevalue of the current attribute for retry count. No change of state. However, if you link this to a system change that says the user mustnowauthenticate by providing "Mothers maiden name" and other personally known information, then the policy state has changed from "Normal authentication used" to "Alternate authentication used". In otherwordsaccess policies may change under alternate (can only resetpassword).3*. BTG*. Here we require the system to go from a "Normal" access toanew rule set "BTG" which would have new expectations of systemAgain we can have a fixed policy with the following conditionattachedto a rule If BTG = True then grant access We can have the following fixed rules as well If Action=BTG and .... then grant with obligation set BTG to True in StateDB. If Action=ResetBTG and .... then grant with obligation set BTG toFalsein StateDB regards davidperformance caused by changing the policy set referenced by the PAP.Forexample, the rule set for patient privacy might be much differentfornormal "treatment" than for "emergency" where imminent harm or deathwasinvolved. Regards, Mike Davis, CISSP Department of Veterans Affairs Office of Health Information Security Architect 760-632-0294 -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] Sent: Monday, March 14, 2011 10:20 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] BTG comment Hal, Erik is some sort of consensus arising that we need an entity in theXACMLmodel (call it a StateDB for now) that holds the state of the systeminthe form of one or more attributes, whose values can be changed.Whenanattribute value changes this represents a state change of thesystem.The PDP is and remains stateless. The request context carries the current state of the system to thePDP.A component of the XACML system (might be a PIP, or it might be something new) picks up the current state of the system from theStateDBand inserts these attributes into the request context for passing tothePDP. When certain authz decision requests are granted (or denied) thismightcause a change in the state of the system. A new component is needed which updates the StateDB when this occurs. This type of state based system is more generic than BTG, and can incorporate BTG as one of its use cases. You can for example usethistype of state based system to - support withdrawals from a credit card machine up to a dailylimit,- block a user's account after 3 concurrent denies, - implement BTG by setting the glass to broken when a user isgrantedpermission to break the glass Does this also answer Mike's suggestion that BTG is an example of something more generic? regards David On 24/02/2011 17:48, Erik Rissanen wrote:Hal, Yes, I agree that a special entity with the explicit purpose of maintaining authorization state would be something good to add.It'snot unusual for real world access control needs to depend onstate,which may be itself affected by an access decision. XACML should support this, but not in the PDP itself. Erik On 02/24/2011 06:04 PM, Hal Lockhart wrote:When we say that the PDP is stateless, what is meant is that nostateis carried by the server from one decision to the next. Policy decisions are purely a function of policies in force and thecontentof the request context. I agree with the general view that this is a valuable propertywhichnot should be lightly changed across the board. However, I amkeepingan open mind on the desirability of explicitly defining entities within the access control architecture which do maintain state. For example, the RBAC profile as it currently exists implies some kind of stateful mechanism to keep track which dynamic roles have been enabled. The exact mechanism was deliberately not specifiedasit was recognized that many designs were possible. Hal -----Original Message----- *From:* Rich.Levinson *Sent:* Wednesday, February 23, 2011 11:57 AM *To:* Davis, John M. *Cc:* erik@axiomatics.com; xacml@lists.oasis-open.org *Subject:* Re: [xacml] BTG comment [WAS: [xacml] Proposed Agenda 10 February 2011 TC Meeting] Hi Mike, Erik, Paul, and David, Here's my two cents on what I've taken from the emails on this thread, David's BTG profile and protocol description. I agree w Erik's statement that the XACML model does not have state built in, and that there is not yet a compelling reason to add it. However, my interpretation of "state" is wrt the Policydefinitions.i.e. the Policy defns themselves are "static". However, for "Policy evaluation", the "state" is theRequestContext,namely whatever values are in the Attributes in the RequestContext at Policy evaluation time may be regarded as the "state". So, for "BTG", what I see as the essential ingredient is the defnofa BTG-State Attribute, that can be supplied by the PEP, or some PIP that supplies it to an attribute finder during policyevaluation.Testing the attribute would be triggered by its presence in aPolicywith it MustBePresent xml attribute set to true, and the Policy should be defined, so that the BTG-State Attribute is not tested unless the request is not permitted without it. This is equivalent to what we did in the RSA-2008 Interop, where the "BTG-State" attribute was "hl7:pea-001", which would allow an external user access, where they would otherwise be denied. i.e. the presence of hl7:pea-001 effectively changed the "state" of Policy evaluation, which enabled BTG logic to be applied. With respect to David's documents, I basically agree with the approach, except for statements like in the protocol descr step 8, where it says: "The PDP sets the relevant BTG-state variable to true ...". I think it is fine to return an Obligation as the Profiledescribes,and that this be used as the basis of the User obtaining a "BTG-State" Attribute, which can be submitted in the follow-up request. I think the presence of this attribute is sufficient "state" for the Policy to evaluate properly. Thanks, Rich Davis, John M. wrote:I still think BTG is a subset of a more general use case. Following along with the obligation, my impression was that thismust be followed with an ageement to abide by the obligation constraints, e.g. a "promise". The promise could act to tell the PDPtochange the policy set (in this case to BTG). With the "state" changethedecision is now correct.Mike Davis ----- Original Message ----- From: Erik Rissanen<erik@axiomatics.com> To:xacml@lists.oasis-open.org<xacml@lists.oasis-open.org> Sent: Wed Feb 23 04:42:41 2011 Subject: Re: [xacml] BTG comment [WAS: [xacml] Proposed Agenda 10 February 2011 TC Meeting] Hi Paul and Mike, I agree, but isn't this exactly what David is proposing? That ishow Iunderstand it, at least for the "PEP state" mode. The otheralternativewith the PDP maintaining state is something I don't think is agoodidea.To make David's proposal better, it needs: - Drop the PDP state approach since this goes against thecapability ofthe XACML model which does not have a state built in. - Define identifiers for at least the BTG obligation/advice(advice isbetter, but for XACML 2.0 an obligation needs to be used), theaction-idfor breaking glass (as well as giving some kind of direction ofwhat theBTG request should look like in relation to resources beingaccessed).- It would be nice with a full, worked through example. Best regards, Erik On 2011-02-23 05:06, Davis, John M. wrote:Concur with Paul's analysis. We also see BTG as a state change. Regards, Mike Davis, CISSP Department of Veterans Affairs Office of Health Information Security Architect 760-632-0294 -----Original Message----- From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com] Sent: Tuesday, February 22, 2011 7:48 AM To: David Chadwick;xacml@lists.oasis-open.org Subject: [xacml] BTG comment [WAS: [xacml] Proposed Agenda 10February2011 TC Meeting] I have some reservations about David's BTG proposal, primarilybecausethe semantics are not well specified, and because it muddies the distinction between what should happen within the XACML system,andwhatshould happen outside of XACML. Obligations, as currently defined, require the PEP to take someactionprior to executing or acting on the PDP's decision for aparticularrequest. The proposed BTG obligation is entirely different: itsays"you can't have access, but you can break the glass if youchoose". Weadded Advice in XACML 3 to accommodate this sort of message-passing--messages which may or may not have anything todo withthe original request or the decision. I don't think the TCshouldencourage the use of Obligations for anything other than whatthey are:an obligation to discharge certain actions regarding the PDP'sdecision.This is the only way to assure predictable system behavior--ortodetecta faulty system. As we discussed on the last call, the scope and definition of"glass"should be specified. If not, we are just standardizing somefeatures ofthe request/response protocol without knowing what effect thesefeatureshave, either on the PDP or the PEP. Does the glass cover aspecificrequest, a specific class of subjects, a class of resources, orwhat?Or is glass-condition just another attribute in the requestcontext,whose effective meaning is given by the policy rules? However you define glass-condition, it will have to beimplemented as aXACML attribute in the request context, or as some extra-xacml functionality. Either way, you are now using the XACML request mechanism to change the policy evaluation state directly. Whilethisisn't prohibited by the standard, it makes it harder to reasonabout thebehavior of the system. David's "BreakTheGlass" action-id is egregious in that it is notjust arequest for permission to do something (outside the XACMLsystem)--it isa directive to change the state of the policy evaluation withregard toa particular (non-XACML) resource, subject, or action. Now, ifstate ismaintained in PEP, you could say this is a normal request, but nevertheless it has muddied the distinction between requests for permission to do something (outside of XACML) and directives todosomething "inside" of XACML. I would favor one of two alternative approaches (or somecombination):1. Simply return an Obligation (along with a Permit decision) iftherequestor is authorized to "break the glass". The PEP would beobligedto display the list of consequences associated with accessingtheresource, and the user could choose to accept the consequencesand seethe resource, or cancel the request. The consequences couldincludechanging the state of the system to allow access to otherresources, orallow other people to see the same resource, or whatever thebusinessmeaning of "break the glass" carries in a specific application.Theobligations would be discharged outside the XACML system. (I'mnot surethat this approach really warrants a standard profile, unless wejustwant to provide a distinguished obligation id value for BTG.) 2. Write policies specifically to allow "break-the-glass"actionstocertain subjects in certain conditions. The PEP would request permission to break the glass, and if allowed would use somenon-XACMLmechanism to change the policy evaluation state. Obligationscould bereturned with the decision to advise user of the consequences.Then theapplication would request access to the desired resource. (AgainIquestion whether this is worthy of standardization, unless wewant toname a distinguished "break-the-glass" action id.) Either of these approaches would meet the BTG use case withoutalteringthe semantics or conventional usage of XACML. Regards, --Paul-----Original Message----- From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] Sent: Thursday, February 10, 2011 05:22 To:xacml@lists.oasis-open.org Subject: Re: [xacml] Proposed Agenda 10 February 2011 TC Meeting Dear All, in preparation for this evening's call, I attach a revisedversion ofthe BTG profile for you consideration regards David<snip>---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TCthatgenerates this mail. Follow this link to all your TCs in OASISat:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TCthatgenerates this mail. Follow this link to all your TCs in OASISat:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TCthatgenerates this mail. Follow this link to all your TCs in OASISat:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php-- ***************************************************************** 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.htmlEntrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is0xBC238DE5*****************************************************************---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]