Re: [xacml] Break the Glass policies

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

Hi Seth

I guess we will just have to disagree on your point about the semantics 
of the actual return code (see more below).

The real difference is that the BTG response requires a stateful PDP in 
order to work correctly, because once the glass is broken the PDP will 
return grants instead of BTG responses. Thus the PEP can be dumb but a 
high quality of service can be given to the user.

In your approach the indeterminate response works with a stateless PDP, 
which is why the state has to kept by the PEP if a high quality service 
is to be given to the user.

So, if the PDP remains stateless the format of the actual return is not 
that important as the behaviour will be the same in both cases. But if 
the PDP becomes stateful then the BTG response has clear advantages over 
indeterminate (but at a cost of complexity in implementing the PDP).

Seth Proctor wrote:
> 
> Hi David. You raise some interesting points, but respectfully I have to 
> disagree with you.
> 
>> Firstly the PEP must operate by never sending this BTG attribute in 
>> its first request context
> 
> I have built *many* systems where the user knows that they are supplying 
> an attribute in the initial request to "break the glass." This can 
> happen for many reasons, through the usual use-cases have to do with 
> emergency medical access or other "first-responder" systems. I don't 
> think this is required, but it's definitely a common scenario that I've 
> come across in practice in many systems.#


What you are doing here is putting an extra burden on the user (who is 
probably already stressed in an emergency situation) by requiring them 
to behave differently by providing an extra attribute in the emergency 
situation that they dont normally need to provide in a normal situation. 
Its a bit like them having a Get Out of Jail Free card in Monopoly, and 
having to present this when an emergency arises and not presenting it in 
normal situations. One has to ask, is this a reasonable and user 
friendly thing to do? Or is it better for the user to simply ask for 
access and then be told they can if they BTG and take the consequences.


> 
>> [...]
>> i) does a clever PEP anticipate that the attribute is needed and 
>> therefore provide it, so that two calls are not needed?
> 
> This is entirely application-specific, as is everything else that you 
> raise. It is *impossible* to know if a give application will want to 
> query the user to ask if it's ok to "break the glass" with each request, 
> if it wants to implement SSO, or if it wants to implement this silently. 

You see this is the burden that your mechanism requires, which is 
removed once you have a stateful BTG PDP.


> This is a fact. It has nothing to do with the given system. No matter 
> what is supported directly in XACML, each system will have its own 
> requirements, and I can say this confidently based on many years of 
> working with teams who are trying to support exactly these kinds of 
> use-cases.
> 
> It doesn't matter if there's some special BTG return or an 
> Indeterminate, it's the same scenario.

Same scenario but different semantics attached to the return code.

> In both cases, the PDP says that 
> it can't make a decision and provides detail about what it's missing to 
> make that decision.

No the above is the semantic of your response and of your response only.

The semantic of the BTG response is quite different. The semantic is 
more definite as the PDP has made a decision and it means "this user 
will be granted access if (s)he decides to first break the glass and 
take the consequences".


> The PEP is left to interpret this and decide what to 
> do.

that is correct in both cases. But the interpretation is different in 
both cases even if the PEPs actions are similar in both cases. However, 
with a BTG response (supplemented with standard obligations) the PEP can 
do much more tailored and sophisticated actions (unless you also allow 
obligations to be returned with indeterminate).

Furthermore, on the second and subsequent calls if the PEP behaves the 
same each time, the effect is different in the BTG case. In the 
indeterminate response case, the same sequence of actions will be 
repeated each time, but in the BTG case the second and subsequent 
responses will be Grant (up until the broken glass is repaired).


> It can be the current Indeterminate response or some new kind of 
> response, but that will have *no* effect on the PEP, which will still be 
> application-specific and have to decide how it responds to the PDP's 
> decision.

I assert that the BTG response with a stateful PDP will have a 
significant effect on the code that needs to be written for the PEP - it 
will be much simpler and will also give a better quality of service to 
the end user.


> 
> In other words, any issues of how "smart" or "dumb" or "stateful" a PEP 
> is doesn't come into play here. There is simply no difference between 
> returning a special return type and retuning Indeterminate for a known 
> attribute, except that the later is already part of the standard and can 
> be modeled in the current XACML policy format.


You are correct if the PDP remains stateless, since BTG cannot operate 
correctly in this case (since after the glass is broken the PDP will not 
remember that it has been broken and will ask for it to be broken again, 
so it is not true BTG, its BTG with unbreakable glass :-).


> 
> The only issue here is whether there is some *standard* behavior for a 
> resposnse from the PDP which specifies that we're in a BTG scenario and 
> more detail is required. This has nothing to do with the response format 
> itself, but could be defined by a profile that defines well-known 
> attributes and well-known behavior based on those attributes.

I agree that with your scenario and a stateless PDP it would be useful 
to profile the indeterminate response code and the missing attribute, 
and also give examples of how it is used.

regards

David

> 
> 
> seth
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, 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

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