Subject: [Ace] Home Automation Use Case

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 06 Dec 2014 13:12:24 +0100

I read through the home automation case and I have a few remarks.

In Section 2.2.2. "Seamless Authorization" you write:

"
   Jane buys a new light bulb for the corridor and integrates it into
   the home network (how she does that is not in scope).  George is not
   at home, but Jane wants him to be able to control the new device with
   his smart phone without the need for additional administration
   effort.
"

Could you be a bit more specific about what is out of scope? I could
imagine that the way how Jane configures access control policies when
she integrates the light bulb into her home is quite similar to the way
how she would do that for George.

I am also wondering what you mean by "Jane wants him [George] to be able
to control the new device with his smart phone without the need for
additional administration effort.". I am sure it again requires some
configuration. It might not require any effort for George but someone
has to do that since otherwise how should the authorization server know
that it has to grant permissions to George to turn the light on or off.

In Section 2.2.3. you describe the case for remotely letting in a
visitor. Would it be possible to add a scenario that is less
sophisticated since this scenario requires some form of messaging
infrastructure to exist.

Here is what I have in mind:

-----

Jane and George have equipped their home with Internet connected door-locks.

Joe, a friend of George, frequently visits them and they would like to
give them access to their home. Once, when Joe was at their home George
uses his smart phone to create a digital access token. He
transfers that access token to Joe's phone using short range radio
communication technology. The token allows Joe to open the door.

Jane and George know that they can revoke access at any time and are
also able to modify the permissions with that access token. Joe is also
not able to use the obtained access token to mint new access tokens to
grant his friends to gain access to the house of Jane and George.

-----

I would delete this sentence from the description in Section 2.2.3 since
it is difficult to compare a regular door lock with the features of the
Internet connected door lock scenario currently described in that section.

"

   The security system controlling the door-locks and alarm system needs
   to be at least as secure as for a comparable unautomated home.
"

In Section 2.2.4. you describe the challenges of the presented use case.
You use the term "home owner" while the scenario talks about two
persons. I would either explain somewhere earlier that the two persons
are actually the owners (since you quite likely do not assume that there
only has to be one owner) or change the term home owner to Jane & George

In Section 2.2.4 you write "
  o  U2.4 A home owner wants to apply context-based conditions
      (presence, time) to authorizations, and the devices need to be
      able to verify these conditions.
"

I could not see how you got to this problem description from the use
cases. I think what you want to say is that
"George and Jane want to put time restrictions to the permissions they
grant to others."

I believe the following items are outside the scope of the work in ACE:

"
   o  U2.6 The access control configuration of the automated home needs
      to be secure by default.

Reason: I guess you want to have a default policy of deny at the
beginning. I don't think it will impact the technical work.

   o  U2.7 The access control policies need to be easy to edit, even
      remotely and it needs to be easy to get access with correct
      authorization.

This problems deals with the UI of the authorization policy editor and
this is clearly outside the scope of our work.

   o  U2.8 The owners of the automated home wants to prevent
      eavesdroppers form being able to deduce behavioral profiles from
      the home network.

I believe this item calls for a communication security solution. Right?

   o  U2.9 Usability is particularly important in this scenario since
      administrative tasks such as installation, configuration and
      decommissioning of devices likely need to be performed by the home
      owners who in most cases have little knowledge of security.

This again a UI issue.

   o  U2.10 Home Owners want their devices to seamlessly (and in some
      cases even unnoticeably) fulfill their purpose.  The
      administration effort needs to be kept at a minimum.

This calls partially for a good UI but also for a solid implementation.

"

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 08 Dec 2014 10:07:56 +0100

> how she would do that for George.

The exact procedure how the bulb is integrated into the home network is 
out of scope for this document.  It might for example require Jane to 
read a QR-code off the package of the bulb and set a few attributes for 
the newly installed device (e.g. type=lightbulb  location=livingRoom).

> that it has to grant permissions to George to turn the light on or off.

I envision the following procedure: When the light bulb is installed, it 
will be configured as part of the lighting system of the house. Besides 
enabling the bulb for the corresponding switches, it also makes all 
existing access control policies apply to that bulb, including the ones 
that gave George access to the old light bulb in that place.

Therefore "no additional administration effort" (besides the normal 
installation procedure) is needed to give George access.

> grant his friends to gain access to the house of Jane and George.

Ok, I'll put that into the next update

>     to be at least as secure as for a comparable unautomated home.

Ok

> "George and Jane want to put time restrictions to the permissions they

Yes I was trying to generalize from "time restrictions" to other 
context-based restrictions. I think originally we also had "presence" in 
mind, i.e. that certain users cannot turn on lights unless they are in 
the right room. I will see if I can fit that into the description.

> this is clearly outside the scope of our work.

Both correct, I'll remove them.

> I believe this item calls for a communication security solution. Right?

If I recall correctly, we introduced this as a reaction to comments, 
that we also should address privacy concerns. Perhaps this would be 
better addressed in the "Privacy Considerations" section.

> This calls partially for a good UI but also for a solid implementation.

Thank you for your comments.

Regards,

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: Stefanie Gerdes <[email-masked]>
Date: Mon, 08 Dec 2014 18:26:10 +0100

Hi all,

>> this is clearly outside the scope of our work.

I don't think we should dismiss UI problems so easily as not in scope.
An important limitation of constrained devices is that they may not have
any user interfaces. An authorization solution needs to deal with that fact.

Moreover, I don't think that this section is primarily about UI
problems. It states two problems: Remotely editing the authorization
policies and usability for authorized users. Maybe some rephrasing would
help.
How about:

U2.7.1 The home users want to be able to configure authorization
policies remotely.
U2.7.2 Home Users may have litte technical skills.
U2.7.3 Authorized users want to be able to obtain access with little effort.

> better addressed in the "Privacy Considerations" section.

I think privacy is essential to consider, especially for home use cases.
Therefore it is a good idea to mention it in the problem summary section
for the home automation use case.

I don't think it is a problem if the use case document states problems
that may be solved by a communication security solution. But I think it
is a problem if we don't see the relevant problems when we try to design
an authorization solution. I guess an authorization solution would use
communication security at some point, e.g. DTLS. So it would be helpful
to have in mind why we need it.

If we really don't want to address specific problems in ACE, we might
just say so. That might be more helpful than to pretend that some
problems are not there.

>>        owners who in most cases have little knowledge of security.

Usability is also essential to consider in home use cases since the
users may not have the technical knowledge to conduct complex security
configurations. It is important for an authorization solution to have
this problem in mind. I don't think that installation, configuration and
decommissiong of devices are simply UI problems.

Steffi

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Dec 2014 18:33:20 +0100

> just say so. That might be more helpful than to pretend that some

In particular, the use cases document is not the place for “requirements engineering”, i.e., the changing of requirements until they fit the solution that somebody wants to promote.

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 09 Dec 2014 08:56:15 +0100

> U2.7.3 Authorized users want to be able to obtain access with little effort.

Alternatively we could dedicate a paragraph to UI problems and usability 
in the security considerations. I don't deny these are important 
problems (and I don't think Hannes does either), but I'm unsure it is 
within the scope of ACE to solve them.

> just say so. That might be more helpful than to pretend that some

I don't pretend these problems do not exist, I just suggested we move 
the description to the Privacy Considerations section, in order to avoid 
bloating the use cases.

/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: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Dec 2014 15:00:33 +0100

Hi Ludwig,

> the newly installed device (e.g. type=lightbulb  location=livingRoom).

This makes sense.

> installation procedure) is needed to give George access.

This is useful additional information that the existing access control
policies are inherited by the newly installed lightbulb by the nature of
the device.

It is useful to state such assumptions because this is ensured by some
form of policy automation and the same might not apply to other users or
to other devices.

> Ok, I'll put that into the next update

Thanks.

> the right room. I will see if I can fit that into the description.

Thanks.

> Both correct, I'll remove them.

Thanks.

> better addressed in the "Privacy Considerations" section.

Makes sense.

Ciao
Hannes

> Regards,
> 
> Ludwig
> 
> 
> 
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Dec 2014 15:10:45 +0100

Hi Steffi,

> U2.7.3 Authorized users want to be able to obtain access with little effort.

I agree that the IoT device most likely does not have a UI but some
other device (like a smart phone or tablet) will and somehow the
policies need to be maintained at the authorization server.

We are not going standardize a UI for editing these policies. We could,
however, standardize an authorization policy language (like XACML) or
standardize the protocol that allows editing (such as WebDAV).

Currently, these things would be outside the ACE WG charter but that's
something that one could imagine. Is this your intention with these
requirements?

> just say so. That might be more helpful than to pretend that some

Ludwig suggested to discuss the topic in the privacy consideration
section and that appears to be the right place. The problem is, as I
mentioned, the scope of what we are trying to do in ACE. For example, if
you are concerned about the ability of a energy company to learn about
the use of home appliances by a household based on the reported energy
consumption then there is nothing in the scope of ACE we can do about
it. Even thought it is an interesting privacy aspect we still shouldn't
list it as a requirement for our work.

> decommissiong of devices are simply UI problems.

The items marked as Ux.x should have something to do with the protocol
work we are doing. If there are protocol related implications in this
item then we should list them. If there aren't, then we need to move the
text somewhere else (or delete it).

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Dec 2014 15:13:53 +0100

Hi Carsten,

On 12/08/2014 06:33 PM, Carsten Bormann wrote:
> In particular, the use cases document is not the place for
> “requirements engineering”, i.e., the changing of requirements until
> they fit the solution that somebody wants to promote.

I still believe it is important to focus on problems we want to solve
and to label others as outside the scope (even though the are important).

I fully agree that good user interfaces, built-in security, privacy by
default, etc. are important.

It does not make them worse if we say that they are outside the scope of
our standardization work (particularly if we know that we cannot solve
them as part of the standardization work we are doing).

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Dec 2014 15:16:22 +0100

Ludwig,

if you could add a section about user interface challenges to gather
existing text concerning UI aspects that would be good for me. One could
use that text as a call for help from the research community.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Dec 2014 15:36:39 +0100

Hi Carsten,

re-read this email and I think my earlier response was actually off-topic.

I believe the issue you raise is about the separation of the solution
from the actual use case description.

In an ideal world these would of course be completely separate but in
practical terms we are of course documenting user stories that assume a
certain architecture to be in place.

The case that Steffi raised earlier about the heart rate sensor is such
an example. You can, in the use case description, assume that the access
control would be done at the heart rate sensor or it could be done at
some other device.

We could, of course, keep the description at such an abstract level that
this difference vanishes but it will then also give us less input for
the work we are doing.

The discussion also raised the question how much we want to leverage
existing industry practices or whether we want to design new approaches.
The healthcare example with excluding certain doctors was an example in
that category of designing some new approaches.

I guess we will not able to able to come up with answers to those
questions but it is nevertheless useful for us to understand where we
standardize existing practices and were we are entering new territory.

I agree with you that we shouldn't tailor the use cases in such a way
that they fit our preferred solution. Of course, this will happen
nevertheless but we can at least try.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Dec 2014 15:57:28 -0500

>> for the home automation use case.

...

    > list it as a requirement for our work.

a) It might be useful to have a use case that addresses the goals, even if only
   so that we can rule it out of scope.

b) so, I agree we can't do anything when the utility polls their meter to
   find out about my energy use.  There are existing situations, not captured
   in our Smart Meter use case.  The case I'm aware of comes from Floria,
   where the energy company sends out (an analog) signal that causes aircon
   systems in homes to turn of for awhile.  Essentially, it's a rolling
   selective blackout on cooling.
   https://www.clearlyenergy.com/residential-demand-response-programs

   so imagine the IoT post-ACE situation.  You want to authorize the power
   company to turn off your AC in your home. The layer-2/3 connectivity could
   be via your meter, or via your Internet connection.
   This part seems like a simple authorization process.

   But, the energy supplier might want to know if your device is on;
   afterall, if your device is not on, they won't save anything by turning it
   on.  Further,if there is a financial incentive to accepting this system,
   you might want to lie (the existing systems have a switch inline with the
   power supply to the chiller which the energy company controls).

So now we have a situation where the power company can monitor the on/off
status of a bunch of appliances.  Do you want to give them access to the
minute by minute data, or some other average situation?  The details do not
exactly matter... what I have in mind is that your privacy could be protected
if you can provide authorization for what appears to be resource "FOO",
but really, you have authorized access to resource "FOOPRIME", in a way
detectable to your device, but not detectable by others.

Possibly, the privacy situation is aided by providing for private aliases.
This might have no protocol  implications, only location implementation
issues, or maybe it has protocol implications.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Dec 2014 08:51:26 +0100

Hi Michael,

thanks for your feedback.

>    This part seems like a simple authorization process.

This use case seems relevant for our authorization work.

I was, however, more thinking about a scenario where the energy
companies learns about detailed device use through the data collected
via smart metering, as shown in this figure:
http://spectrum.ieee.org/image/1711246

> detectable to your device, but not detectable by others.

To protect against the leakage of individual device usage aggregation
helps. Your example sounds a bit like aggregation of resources to me.

If aggregation is the solution then one could think about providing
features in the access control system that deny too regular read
requests (since the aggregation interval would be too small) or just
return the same value within the given time period.

> issues, or maybe it has protocol implications.
I don't think that this will help since you have a nailed-up connection
with your energy company and since the energy company wants to know you
(since they have to charge you) a pseudonym would only help for someone
looking on the messages transmitted over the wire. We are, however,
assuming communication security using DTLS/TLS for most of these
applications.

Ciao
Hannes

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 12 Dec 2014 16:55:25 +0100

Hi Hannes,

On 12/11/2014 03:10 PM, Hannes Tschofenig wrote:
>>>> o  U2.7 The access control policies need to be easy to edit,
>>>> even remotely and it needs to be easy to get access with
>>>> correct authorization.
>>>> 
>>>> This problems deals with the UI of the authorization policy
>>>> editor and this is clearly outside the scope of our work.
>> 
>> I don't think we should dismiss UI problems so easily as not in
>> scope. An important limitation of constrained devices is that
>> they may not have any user interfaces. An authorization solution
>> needs to deal with that fact.
>> 
>> problems. It states two problems: Remotely editing the
>> authorization policies and usability for authorized users. Maybe
>> some rephrasing would help. How about:
>> 
>> policies remotely. U2.7.2 Home Users may have litte technical
>> skills. U2.7.3 Authorized users want to be able to obtain access
>> with little effort.
> 
> 
> I agree that the IoT device most likely does not have a UI but
> some other device (like a smart phone or tablet) will and somehow
> the policies need to be maintained at the authorization server.
> 
> We are not going standardize a UI for editing these policies. We
> could, however, standardize an authorization policy language (like
> XACML) or standardize the protocol that allows editing (such as
> WebDAV).
> 
> Currently, these things would be outside the ACE WG charter but
> that's something that one could imagine. Is this your intention
> with these requirements?

I agree that topics such as the appearance of graphical user
interfaces are not in scope. But users need to be able to configure
authorization policies in a way that fits their skills, e.g. by using
a device with a pretty user interface instead of pressing five
different buttons in the correct order. This influences the required
architecture, since the constrained devices often don't have any user
interfaces. Therefore, one task that needs to be performed by the
actors in the ACE architecture is obtaining authorization policies
from the owner (see also draft-gerdes-ace-actors [1]).

The authorization policies defined by the owner then have to be
provided to the constrained device since this device needs to be able
to enforce the authorization policies of the owner.

Referring to the architecture introduced in draft-gerdes-ace-actors,
this applies to the communication between the constrained device and
its respective Authorization Manager (constrained to less-constrained
level). How the communication between these actors works should be
defined by ACE. The communication between the less-constrained level
and the principal level must be possible, but the details will be out
of scope, I guess (BTW, defining the required tasks, actors and
architecture as done in draft-gerdes-ace-actors therefore would be
really useful for the work in ACE).

>>>> eavesdroppers form being able to deduce behavioral profiles
>>>> from the home network.
>>>> 
>>> If I recall correctly, we introduced this as a reaction to
>>> comments, that we also should address privacy concerns. Perhaps
>>> this would be better addressed in the "Privacy Considerations"
>>> section.
>> 
>> I think privacy is essential to consider, especially for home use
>> cases. Therefore it is a good idea to mention it in the problem
>> summary section for the home automation use case.
>> 
>> I don't think it is a problem if the use case document states
>> problems that may be solved by a communication security solution.
>> But I think it is a problem if we don't see the relevant problems
>> when we try to design an authorization solution. I guess an
>> authorization solution would use communication security at some
>> point, e.g. DTLS. So it would be helpful to have in mind why we
>> need it.
>> 
>> If we really don't want to address specific problems in ACE, we
>> might just say so. That might be more helpful than to pretend
>> that some problems are not there.
>> 
> 
> section and that appears to be the right place. The problem is, as
> I mentioned, the scope of what we are trying to do in ACE. For
> example, if you are concerned about the ability of a energy company
> to learn about the use of home appliances by a household based on
> the reported energy consumption then there is nothing in the scope
> of ACE we can do about it. Even thought it is an interesting
> privacy aspect we still shouldn't list it as a requirement for our
> work.

We cannot prevent on a technical level that authorized entities may
misuse the data they are allowed to access. But a well-designed
authorization solution can prevent unauthorized entities from
accessing data, thus protecting the privacy of users.

Steffi

[1] http://tools.ietf.org/pdf/draft-gerdes-ace-actors

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Dec 2014 11:40:42 -0500

> http://spectrum.ieee.org/image/1711246

Yes, I gathered that.  I don't see a way that a home-owner can "defend"
against this directly.  It's the utilities' meter.  The home-owner could
have a bank of batteries that they charge regularly in order to obscure
the traffic analysis that this diagram shows. This might ultimately be a good
thing for the energy system.

    > helps. Your example sounds a bit like aggregation of resources to me.

A bit, but that's not what I had in mind.
Rather, when I want to provide an authorization token that appears to say:
        "Energy company can access resource FOO"
but, really, when the device looks at it, it says:
        "Energy company can access resource FOOPRIME"

    > assuming communication security using DTLS/TLS for most of these

It's not an alias for me.
It's an alias for the resource in the appliance.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Dec 2014 19:41:10 +0100

Hi Michael,

thanks for your quick response.

>         "Energy company can access resource FOOPRIME"

Hmmm.

I was only involved a little bit in the smart grid/smart metering space
and my understanding was that the device sends the data to the energy
company. Then, you (as a user) can use your browser/app to look at your
energy consumption on the website of the energy company. That was the
story, as I understood it. (I believe that this is also the story for
how the NIST Green Button initiative works but I have not been involved
in that work myself; a few of the guys from the OAuth group have been
active there.)

In that model the energy company was implicitly authorized (by
configuring the meter to send the data to a specific server) to get the
data but let us for a moment assume the model is different. Let us
assume a CoAP server running on a smart meter and the energy company
sends a request to the device to retrieve the info.

For an interoperability point of view I hope that there is some story on
how the resource is discovered and accessed. The OMA LWM2M model, as
Michael presented it at the last IETF meeting is one such possibility.
Here is the slide deck:
http://www.slideshare.net/MichaelKoster/ietf91-ad-hoccoaplwm2mipso-41542196

The name of the URI can be changed without any impact but what would be
the benefit? The energy company knows that this is household X and it
also knows that resources it is going to get. If TLS/DTLS is used then
hopefully nobody between the meter and the energy company will be able
to read the communication.

> It's an alias for the resource in the appliance.

I mentioned the alias thing because that was the "privacy story" for
smart metering in Germany (at least at the time I was involved). I hope
it had changed in the meanwhile.

As argued in the previous paragraph I do not think that the alias for
the resource actually adds a privacy value.

Ciao
Hannes