Subject: [Ace] Constrained Devices and Off-Loading

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Oct 2015 10:01:19 +0200

Hi all,

I wanted to raise a point that has bothered me in the discussions on
constrained devices already for some time. As the text from the
architecture document shows the way how the story is painted is that
constrained devices cannot (due to their limitations) perform certain
functions on their own and hence they need some third party.

Here is one example of such a text:

"
   The limitations of the constrained nodes ask for security mechanisms
   which take the special characteristics of constrained environments
   into account; not all constituents may be able to perform all
   necessary tasks by themselves.  In order to meet the security
   requirements in constrained scenarios, the necessary tasks need to be
   assigned to logical functional entities.

   In order to be able to achieve complex security objectives between
   actors some of which are hosted on simple ("constrained") devices,
   some of the actors will make use of help from other, less constrained
   actors.  (This offloading is not specific to networks with
   constrained nodes, but their constrainedness as the main motivation
   is.)
"

I see the story a bit differently.

What I see is that in general there is a need for third parties to
centrally manage authorization. This is not a unique aspect of
constrained devices. You can look at pretty much every sector and you
will see that there is a desire to centrally manage devices for a
variety of reasons, most of them have nothing to do with device
limitations. It is just convenient to do that.

If I look at the identity management industry then I see them also
introducing capabilities for authorizing IoT devices (and not just users
and service access, an effort that has been going on the last 15+ years).

In that spirit I believe it is worthwhile to phrase the story in a bit
broader style so that these companies recognize themselves and their
work again in this environment, particularly since many of the deployed
IoT devices are not as constrained some some would think.

What I would do is to describe the story as an evolution. Today we have
companies doing device management and with the increasing IoT deployment
they are also moving over to the management of smaller devices.

I could contribute text if there is actually interest. I hate to
contribute text that gets trashed.

What do others think about this approach?

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 01 Oct 2015 10:16:49 +0200

Hannes Tschofenig wrote:
> centrally manage authorization.

I'm not so sure about that "centrally", but yes.

The difference may be that there are additional reasons to do this here:
the constrainedness, the thingness, etc.  That may influence the
selection of solutions.

So that hammer may not fit that specific nail very well.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Oct 2015 10:56:58 +0200

Hi Carsten

thanks for your quick response.

> I'm not so sure about that "centrally", but yes.

Centrally is a loose term. I have looked at two use cases in detail,
namely the physical access control and the lighting use case.

In the physical access control centrally refers to the enterprise
identity management system. In the lighting sector centrally means two
different things (as described in the draft we submitted to the group),
namely the device the installer uses for entities that are fixed in the
building (such as light switches and their luminaries). The installer
will then disappear once the job is done but may show up again when
there is a need to re-configure the devices in the building. Then, there
is the more dynamic case where dynamic access is needed and that has to
be done via a dedicated server in the network. Smaller companies may not
necessarily care about the dynamic use case and so they do not need a
dedicated server.

In other scenarios the story may be different but I just haven't looked
at them in detail. I actually takes a while to understand these
scenarios in detail since you have to talk to domain experts.

> the constrainedness, the thingness, etc.  That may influence the

I guess it would have been too far fetched to assume that you like my
proposal.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 01 Oct 2015 12:15:47 +0200

> I guess it would have been too far fetched to assume that you like my

Hey, I did say "yes".
Just added a caveat.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2015 17:12:54 -0400

We manage constrained devices centrally because the devices are incapable of
making the decision locally.

We manage non-constrained devices (like desktop PCs) centrally because the
end-users are either untrusted, or incapable of making the decision locally.

> broader style so that these companies recognize themselves and their work
> again in this environment, particularly since many of the deployed IoT
> devices are not as constrained some some would think.

I strongly agree with making the situation a bit broader, so go ahead...

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

---

From: Göran Selander <[email-masked]>
Date: Wed, 7 Oct 2015 07:07:44 +0000

Hi Hannes

>and service access, an effort that has been going on the last 15+ years).

Note that the quote above does not explicitly mention “authorization”.

It also applies to other security services, for example, authentication
and key establishment, where trusted third parties provide security
context information such as keys and other parameters that dependent nodes
use to establish secure connections. Such examples also exist in the
unconstrained world and carry over to the constrained setting, and may be
necessary for the service to work in the constrained setting.

And there are yet other examples of third party services which are not
specific to networks with
   constrained nodes but their constrainedness is the main motivation,
such as the message broker in a publish-subscribe setting, which offloads
a constrained publisher from interacting with each subscriber (in which
case one security objective is end-to-end security between publisher and
subscriber).

Such examples are behind in the text you quoted, please consider that when
you propose new text - which I also encourage you to do!

Göran