Subject: [Ace] Context-based Authorization

From: Likepeng <[email-masked]>
Date: Tue, 15 Jul 2014 03:19:28 +0000

Hi all,

Personally I am wondering whether or not we should support context-based authorization indicated in http://tools.ietf.org/html/draft-seitz-ace-usecases-01.

For U2.4, do we want to achieve something like this: if time is 9:00 ~ 18:00, Client A is allowed to turn on a light, but Client B is not allowed?

To me, this is purely Resource Server side policy setting and enforcement. Does it require any information exchange with Authorization Server? Is it necessary?

About presence, does it mean online / offline status? If yes, this should be covered by another requirement U5.2, which was discussed in another discussion thread "offline operation".

   o  U2.4 Jane must be able to apply context-based conditions
      (presence, time) to authorizations, and the devices (door-lock or
      alarm) need to be able to verify these conditions.

For U3.1, how to define an emergency context?

   o  U3.1 John must be able to pre-configure access rights to the

      position data for persons or groups, in the context of an

      emergency.

Thanks,

Kind Regards

Kepeng

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 15 Jul 2014 08:10:30 +0200

On 07/15/2014 05:19 AM, Likepeng wrote:
> Hi all,
>
> Personally I am wondering whether or not we should support context-based
> authorization indicated in
> http://tools.ietf.org/html/draft-seitz-ace-usecases-01.
>
> For U2.4, do we want to achieve something like this: if time is 9:00 ~
> 18:00, Client A is allowed to turn on a light, but Client B is not allowed?

Yes that's one example.

>
> To me, this is purely Resource Server side policy setting and
> enforcement. Does it require any information exchange with Authorization
> Server? Is it necessary?

We are moving away from requirements here and getting into solutions, 
but for the sake of clarification: I don't think this kind of policy 
should be on the RS, it should be maintained and managed by the AS, for 
the same reasons we want all the other authorization policies to be on 
the AS. The solution I have in mind are conditional authorization 
decisions in the style: "You are permitted to turn on the light, 
provided it is between 9:00 and 18:00".

> About presence, does it mean online / offline status? If yes, this
> should be covered by another requirement U5.2, which was discussed in
> another discussion thread “offline operation”.
>

No I meant physical presence, like "you get to control the HVAC if you 
are in the room, but from elsewhere"

> For U3.1, how to define an emergency context?

In medical access control scenarios there is the concept of 
"break-the-glass policies". This means that medical personnel can just 
declare an emergency context (similar to breaking the glass to access a 
fire alarm, see attached image) in order to get additional 
authorization. This declaration is then subject to auditing at a later 
point, to ensure that there really was an emergency situation.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 15 Jul 2014 07:29:44 +0000

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
>
> > Personally I am wondering whether or not we should support
> > context-based authorization indicated in
> > enforcement. Does it require any information exchange with
> > Authorization Server? Is it necessary?
>
> We are moving away from requirements here and getting into solutions, but
> for the sake of clarification: I don't think this kind of policy should be on the
> RS, it should be maintained and managed by the AS, for the same reasons we
> want all the other authorization policies to be on the AS. The solution I have
> in mind are conditional authorization decisions in the style: "You are
> permitted to turn on the light, provided it is between 9:00 and 18:00".
>

[SK] Completely agree with Ludwig. Context-based policies are very relevant in IoT if they need invisibly mesh with our daily lives.
How to implement it is something we need to discuss during the solution phase. However to me this does not sound like only a
RS side policy setting, since RS still needs to figure out if it was A or B who is allowed within that context. Enforcement could be RS side depending on the ability of RS to verify context.

regards
Sandeep

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 15 Jul 2014 16:17:47 +0100

I think we do need to consider context based authentication and it 
should be possible to establish the bases for the context without having 
to go into solutions, e.g.

* Time-based
* Identity-based
* Role-based
* etc.

It may sound simple/obvious but access is simply a boolean evaluation of 
an expression, which could be really simple ("true") or more complex 
("if (ID is X) AND (time is after 2.30pm) AND (time is before 6.30pm) 
AND (day is Monday)). The tricky bit is actually authenticating the LHSs 
of the components of the boolean expression, whether they come from the 
accessor (e.g. ID) or the accessee (e.g. time)

Robert

On 15/07/2014 8:29 AM, Kumar, Sandeep wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 16 Jul 2014 10:34:08 +0200

On 07/15/2014 06:10 PM, Erik Wahlström wrote:
> Consider it? Sure, absolutely. But building it into the protocol I’m not that sure of. It’s a rather tricky thing and a slippery slope. Isn’t it better to let the AS decide for each request by using inspection endpoints
(or something like it depending on what solutions and technologies we 
will end up working with). The RS asks the AS for validity of a token 
within a specific context.

That wouldn't work in use cases were the RS has intermittent connectivity.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Robert Cragie <[email-masked]>
Date: Wed, 16 Jul 2014 10:46:27 +0100

I think the model should clearly identify the different roles the AS can 
play and treat them as separate entities. When it comes to allow/deny, 
the RS will have to make a decision. It could consult some co-located 
decision maker or potentially ask a remote decision maker or a 
combination of the two. The rules for decision making could be based on 
prior interactions and resulting token delivery in conjunction with 
current parameters. All a token is saying is "don't ask me (the AS) now, 
this token shows I have already said yes". Considering the earlier 
EAP/AAA discussion - tokens should be optional.

Maybe we could extend the notion of context-based authorization with 
triggers, i.e. if a condition fails, it triggers some remedial action so 
it hopefully won't subsequently fail.

Robert

On 16/07/2014 9:34 AM, Ludwig Seitz wrote:
>> Consider it? Sure, absolutely. But building it into the protocol I'm 
>> not that sure of. It's a rather tricky thing and a slippery slope. 
>> Isn't it better to let the AS decide for each request by using 
>> inspection endpoints

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Jul 2014 13:00:50 +0200

On 15 Jul 2014, at 17:17, Robert Cragie <[email-masked]> wrote:

> I think we do need to consider context based authentication and it should be possible to establish the bases for the context without having to go into solutions, e.g.
> 
> * Time-based
> * Identity-based
> * Role-based
> * etc.

(I hope this is about authorization.)

So which components need to interoperate to make this work?
It seems any agreement about information that leads up to such a capability would need to be between RS and AS.
(C or AM may also be interested, but that seems to be a supplementary capability.)

In the architecture underlying DCAF, the ticket being transported from AS to RS contains “authorization information”, which is an entity with an Internet media type.  AS and RS just need to communicate their authorization parameters via a media type they both support.
So evolution of this format is built right in; this can be done orthogonally to any other evolution in the system.

(I don’t think we have a good answer for context-based authorization of an RS to represent a resource R.
That is architecturally a bit more complicated.
But maybe this is not really required as much as context-based authorization of a client to access R.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jul 2014 19:57:39 -0400

> point, to ensure that there really was an emergency situation.

I immediately thought of the "break-the-glass" concept as well, and then
went to read 3.1 again.  As written, 3.1 doesn't seem to imply that to me:
     U3.1 John must be able to pre-configure access rights to the
     position data for persons or groups, in the context of an
     emergency.

Let me explain what I interpret as "break-the-glass".
1) anyone near the glass can break it, not just some set of persons/groups.

2) the glass, having been broken, leaves a clear audit trail that someone
   has broken it.  Many fire-alarms emit dye when set off so that the person
   who "broke the glass" is clearly identified.  My high school didn't have
   that; and the fire department visited us three weeks in a row, just before
   period 4 on day 2.. when I guess someone had a test they didn't want to
   write.  I mention this situation because; despite a record of "crying
   wolf", the fire department had to show up each time.

3) the glass, having been broken, can not be broken again; it needs an
   explicit reset.

If I were I solve the break-the-glass situation, I would look to some kind
of skey-like solution based upon chained-hashes.
    http://research.microsoft.com/en-us/um/people/lamport/pubs/password.pdf
although I'm not quite sure how to use it yet.

HOWEVER, my reading of section 3.1 says that actually "John" simply is going
to want to configure that his spouse, children and best friend can grant
access to whomever needs it, when they see an emergency.

Going into a solution space, I would imagine that John's RS/AS generates a
series of unbound access tokens, and encrypts each one to each of them to the
set of friends/family that should have it.
Those encrypted tokens should be stored somehow on the RS itself, to be
retrieved by the person in the emergency, decrypted, and then delegated.

Such a solution may create some new requirements:
   1) ability to create a access token that is not bound to a specific
      client, but to anyone who possesses it.  In some solutions, this
      would be entirely a matter local to the RS, but I can see how many
      solutions need the RS and AS to interoperate on this.

   2) ability to retrieve such an encrypted access token from a well known
      resource.

   3) ability to securely pass such an encrypted access token on from
      one client to another.

Part 2/3 must occur "offline".
Much of the details are out of the scope for ACE.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ludwig Seitz <[email-masked]>
Date: Sun, 20 Jul 2014 15:51:09 +0200

> 1) anyone near the glass can break it, not just some set of persons/groups.

I totally agree with the other two points. It is in this one our 
interpretations differ. When I worked for Swedish National Healthcare, 
they had me define a break-the-glass access control policy for Swedish 
medical doctors and paramedics. The crucial information missing here is 
perhaps that there is a nationwide identification card (using X.509 
certificates) [1] for medical practitioners in Sweden. With that they 
can authenticate at any terminal in a hospital and access medical files.

Normally the access control policy would only allow access to a medical 
file if you had a care relation (an attribute linking patients to 
medical personnel), but when you "broke the glass" you could access any 
file.

The difference to what you suggested ("John" simply is going
to want to configure that his spouse, children and best friend can grant
access to whomever needs it, when they see an emergency.) to what I 
meant is that in my case a paramedic first responder could immediately 
"break-the-glass" and access John's heart rate monitor without first 
having to get permission by some relative of John's.

So yes I meant "bread-the-glass" and I should have written so in the use 
case document. I'll try to clarify in the next update.

/Ludwig

[1] For those who understand Swedish, information on the identification 
card for medical practitioners: 
http://www.e-identitet.se/index.php?page=vard_omsorg_general

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Jul 2014 10:33:45 -0400

Ludwig Seitz <[email-masked]> wrote:
    > The difference to what you suggested ("John" simply is going to want to
    > configure that his spouse, children and best friend can grant access to
    > whomever needs it, when they see an emergency.) to what I meant is that
    > in my case a paramedic first responder could immediately

okay, so it's good that we established that the requirement was mis-written.
I'm struggling to imagine a break-the-glass protocol which is first responder
to medical device, and which can operate securely "offline", and yet can not
be easily abused.

I can easily see how one can break the glass at a full computer terminal in a
hospital where the entire system is online (and is likely sufficiently
replicated and provisioned with backup generators...)

Are there some examples in the literature?