RE: [xacml] BTG comment

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

The 3rd example differs from the previous 2 in that the XACML request is
simultaneously *changing* the request context and requesting permission
to 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 it simplifies
analysis to assume that the request/response sequence is idempotent with
respect to the request context.

Nothing prevents an implementation from using other communication
channels to modify the environment to cause a change in the evaluation
context.  In the bank account examples, it would seem a very poor design
to make the XACML system update account information--surely that happens
outside 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 the
> value of the current attribute for retry count. No change of state.
> However, if you link this to a system change that says the user must
now
> authenticate 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 other
words
> access policies may change under alternate (can only reset password).
>
> 3*. BTG*. Here we require the system to go from a "Normal" access to a
> new rule set "BTG" which would have new expectations of system

Again we can have a fixed policy with the following condition attached 
to 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 to False 
in StateDB

regards

david


> performance caused by changing the policy set referenced by the PAP.
For
> example, the rule set for patient privacy might be much different for
> normal "treatment" than for "emergency" where imminent harm or death
was
> involved.
>
> 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 the XACML
> model (call it a StateDB for now) that holds the state of the system
in
> the form of one or more attributes, whose values can be changed. When
an
> attribute value changes this represents a state change of the system.
>
> The PDP is and remains stateless.
>
> The request context carries the current state of the system to the
PDP.
>
> 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 the
StateDB
> and inserts these attributes into the request context for passing to
the
> PDP.
>
> When certain authz decision requests are granted (or denied) this
might
> cause 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 use this
> type of state based system to
> - support withdrawals from a credit card machine up to a daily limit,
> - block a user's account after 3 concurrent denies,
> - implement BTG by setting the glass to broken when a user is granted
> permission 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's
>>  not unusual for real world access control needs to depend on state,
>>  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 no
state
>> > is carried by the server from one decision to the next. Policy
>> > decisions are purely a function of policies in force and the
content
>> > of the request context.
>> > I agree with the general view that this is a valuable property
which
>> > not should be lightly changed across the board. However, I am
keeping
>> > an 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 specified as
>> > it 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 Policy
definitions.
>> > i.e. the Policy defns themselves are "static".
>> >
>> > However, for "Policy evaluation", the "state" is the
RequestContext,
>> > 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 defn
of
>> > a BTG-State Attribute, that can be supplied by the PEP, or some
>> > PIP that supplies it to an attribute finder during policy
evaluation.
>> > Testing the attribute would be triggered by its presence in a
Policy
>> > with 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 Profile
describes,
>> > 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 this
> must be followed with an ageement to abide by the obligation
> constraints, e.g. a "promise". The promise could act to tell the PDP
to
> change the policy set (in this case to BTG). With the "state" change
the
> decision 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 is
how I
>> >> understand it, at least for the "PEP state" mode. The other
alternative
>> >> with the PDP maintaining state is something I don't think is a
good
> idea.
>> >>
>> >> To make David's proposal better, it needs:
>> >>
>> >> - Drop the PDP state approach since this goes against the
capability of
>> >> the XACML model which does not have a state built in.
>> >>
>> >> - Define identifiers for at least the BTG obligation/advice
(advice is
>> >> better, but for XACML 2.0 an obligation needs to be used), the
action-id
>> >> for breaking glass (as well as giving some kind of direction of
what the
>> >> BTG request should look like in relation to resources being
accessed).
>> >>
>> >> - 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 10
February
>> >>> 2011 TC Meeting]
>> >>>
>> >>> I have some reservations about David's BTG proposal, primarily
because
>> >>> the semantics are not well specified, and because it muddies the
>> >>> distinction between what should happen within the XACML system,
and
> what
>> >>> should happen outside of XACML.
>> >>>
>> >>> Obligations, as currently defined, require the PEP to take some
action
>> >>> prior to executing or acting on the PDP's decision for a
particular
>> >>> request. The proposed BTG obligation is entirely different: it
says
>> >>> "you can't have access, but you can break the glass if you
choose". We
>> >>> added Advice in XACML 3 to accommodate this sort of
>> >>> message-passing--messages which may or may not have anything to
do with
>> >>> the original request or the decision. I don't think the TC should
>> >>> encourage the use of Obligations for anything other than what
they are:
>> >>> an obligation to discharge certain actions regarding the PDP's
> decision.
>> >>> This is the only way to assure predictable system behavior--or to
> detect
>> >>> a faulty system.
>> >>>
>> >>> As we discussed on the last call, the scope and definition of
"glass"
>> >>> should be specified. If not, we are just standardizing some
features of
>> >>> the request/response protocol without knowing what effect these
> features
>> >>> have, either on the PDP or the PEP. Does the glass cover a
specific
>> >>> request, a specific class of subjects, a class of resources, or
what?
>> >>> Or is glass-condition just another attribute in the request
context,
>> >>> whose effective meaning is given by the policy rules?
>> >>>
>> >>> However you define glass-condition, it will have to be
implemented as a
>> >>> XACML 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. While
this
>> >>> isn't prohibited by the standard, it makes it harder to reason
> about the
>> >>> behavior of the system.
>> >>>
>> >>> David's "BreakTheGlass" action-id is egregious in that it is not
just a
>> >>> request for permission to do something (outside the XACML
> system)--it is
>> >>> a directive to change the state of the policy evaluation with
regard to
>> >>> a particular (non-XACML) resource, subject, or action. Now, if
state is
>> >>> maintained 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 to
do
>> >>> something "inside" of XACML.
>> >>>
>> >>> I would favor one of two alternative approaches (or some
combination):
>> >>>
>> >>> 1. Simply return an Obligation (along with a Permit decision) if
the
>> >>> requestor is authorized to "break the glass". The PEP would be
obliged
>> >>> to display the list of consequences associated with accessing the
>> >>> resource, and the user could choose to accept the consequences
and see
>> >>> the resource, or cancel the request. The consequences could
include
>> >>> changing the state of the system to allow access to other
resources, or
>> >>> allow other people to see the same resource, or whatever the
business
>> >>> meaning of "break the glass" carries in a specific application.
The
>> >>> obligations would be discharged outside the XACML system. (I'm
not sure
>> >>> that this approach really warrants a standard profile, unless we
just
>> >>> want to provide a distinguished obligation id value for BTG.)
>> >>>
>> >>> 2. Write policies specifically to allow "break-the-glass" actions
to
>> >>> certain subjects in certain conditions. The PEP would request
>> >>> permission to break the glass, and if allowed would use some
non-XACML
>> >>> mechanism to change the policy evaluation state. Obligations
could be
>> >>> returned with the decision to advise user of the consequences.
Then the
>> >>> application would request access to the desired resource. (Again
I
>> >>> question whether this is worthy of standardization, unless we
want to
>> >>> name a distinguished "break-the-glass" action id.)
>> >>>
>> >>> Either of these approaches would meet the BTG use case without
altering
>> >>> the 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 revised
version of
>> >>>> the BTG profile for you consideration
>> >>>>
>> >>>> regards
>> >>>>
>> >>>> David
>> >>>>
>> >>>>
>> >>> <snip>
>> >>>
>> >>>
---------------------------------------------------------------------
>> >>> 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.p
>> >> hp
>> >>
>> >>
>> >
>>
>
> --
>
> *****************************************************************
> 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
>
> *****************************************************************
>
> ---------------------------------------------------------------------
> 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
>

-- 

*****************************************************************
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

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

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