Subject: [Ace] draft-garcia-core-security-06

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Dec 2013 17:47:05 +0100 (CET)

Dear Oscar, Sandeep, Sye Loong, Rene^2,

thanks for submitting this document. I took a look at the scenario part, which talks about Building Automation and Control (BAC).

I ran into a few questions:

•    You illustrate the lifecycle of an IoT device and the device identity and the secret keys are provided to the device during the "installation" and "commissioning" phase. You seem to assume that there is no keying material provided to the device during the manufacturing process? Is that correct?

•    I also wasn’t quite sure whether you assume that there are different credentials being used for network access, and for access to the different services.

•    How is authorization accomplished in the BAC environment?

•    Why did you pick the BAC environment as an example use for the document? Is it because of your experience with this sector? Or does it have specific characteristics not found in other areas?

Ciao

Hannes

---

From: Sandeep Kumar <[email-masked]>
Date: Fri, 13 Dec 2013 11:20:41 +0100

Hi Hannes

On Thu, Dec 12, 2013 at 5:47 PM, Hannes Tschofenig <
[email-masked]> wrote:

> thanks for submitting this document. I took a look at the scenario part,
> which talks about Building Automation and Control (BAC).
>

This document has been around for quite some years now and gives a general
overview of the security considerations in the constrained environments and
goes beyond authorization.

> •    You illustrate the lifecycle of an IoT device and the device identity
> and the secret keys are provided to the device during the "installation"
> and "commissioning" phase. You seem to assume that there is no keying
> material provided to the device during the manufacturing process? Is that
> correct?
>

We do assume there is some form of security material (device identities,
keys, etc) on the devices after manufacturing that enables a secure
installation and commissioning. However the identities and keys (that you
mention) provided during commissioning are for the operational phase which
in most cases are different from the original manufacturing phase
identities and keys.

"device identity and the secret keys used during *normal operation* are
provided to the device during this phase"

>  •    I also wasn’t quite sure whether you assume that there are different
> credentials being used for network access, and for access to the different
> services.
>

Yes, there are a whole bunch of security associations that need to be
created based on what the device intends to do, if it needs just network
access or be part of a secure multicast group or access a particular
backend service, etc. Different credentials need to be then provided during
the commissioning/re-commissioing phase and preferably using a common
protocol.

> •    How is authorization accomplished in the BAC environment?

Presently authorizations in BAC are quite static for obvious reasons,
things don't change much dynamically after the commissioning phase where it
is known before hand which device service needs to be authorized to which
other device service. An ACL at the service layer works pretty well in such
a static environment. In home automation, things may be slightly different
where new devices may need to be added without a professional
installer/commissioner, and then there can be a need for "easier" solutions.

> •    Why did you pick the BAC environment as an example use for the
> document? Is it because of your experience with this sector? Or does it
> have specific characteristics not found in other areas?
>

Professional lighting (in offices, hospitals, malls, etc) is often part of
BAC and we do have a pretty good view of the issues in this domain. There
are very specific characteristics due to the deployment sequence in
buildings for e.g. the BAC is connected to the backend IT infrastructure at
a quite later stage, to name one.

regards
Sandeep

Ciao
Hannes

______________________________
>
> _________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace