Subject: [6tisch] joining security start and end states

From: Kris Pister <[email-masked]>
Date: Tue, 05 May 2015 09:39:14 -0700

Let's see if we can get agreement at a high level on what we're trying to do
during the joining process.

Things that a mote might start with (one or more of):
A) nothing
B) PSK(s)
C) raw public/private key
D) certificate(s) from
    i) manufacturer/distributor/installer
    ii) consortium (e.g. Corner Grocers Alliance)
    iii) end user/owner (e.g. Charlie's Market)
    iv) desired network(s)

Things that a mote might end with:
1) L2 key(s) for MIC (and optionally encryption)
2) DTLS session with JCE if present
3) DTLS session with PCE if present
4) L2 keys for 6top communication to neighbors
5) locally-significant certificate for future joins

The mote might start with things in {B, C, D} at manufacture, or by some 
out of band
commissioning step as suggested by Tero and Timothy.

The keys that a mote gets in 1 and 4 may all be generated by a single 
entity (e.g. JCE)
or they may be generated locally from one or more Master Keys.

Some of the things in the desired end state (like 1 or 5) might have 
been installed
already (like B or D.iv).

We need a way for people who say "I don't want the hassle of security, 
and I can't
afford a chip with ECC" (e.g. start state A) to still transition to 
something that is
secure after the join process is over.

ksjp

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2015 14:32:45 -0400

> 5) locally-significant certificate for future joins

I agree with your characterisation, but (A) can't be correct.

    > and I can't afford a chip with ECC" (e.g. start state A) to still
    > transition to something
    > that is

I can design/pick an online protocol where such a device that has been
provisioned at manufacturing time with a (larger) symmetric key could join.
To make this work requires that the manufacturer always be online and
available, that the devices are never resold or repurposed without the
participation of the manufacturer, and the privacy footprint of the solution
may poor.  Such a join process may lack PFS, and maybe some forms of replay
attack may be possible; that suggests that the device, once provisioned may
never be factory defaultable.

I would prefer to leave (A) out for now.

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 May 2015 14:58:31 +0300

> I would prefer to leave (A) out for now.

Note, that A is from the security point of view, exactly same as
well-known shared key.
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 7 May 2015 16:20:42 +0200

Kris,

We need a way for people who say "I don't want the hassle of security, and
> I can't

That would be great, but if a node starts from A, I don't see how it can
authenticate the network, and the network authenticate the node. I must be
missing something.

The simplest is B: a node is configured during commisioning with a key, a
shared secret withe the JCE. If the node/JCE can challenge each other with
that key, they have authenticated each other. Through this mechanism, the
JCE can setup all the keying material used during the operational stage of
the network.

I feel like the above paragraph is generally agreed upon.

Thomas

On Tue, May 5, 2015 at 6:39 PM, Kris Pister <[email-masked]> wrote:

> Some of the things in the desired end state (like 1 or 5) might have been
> installed
> We need a way for people who say "I don't want the hassle of security, and
> I can't
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Tom Phinney <[email-masked]>
Date: Thu, 07 May 2015 08:01:02 -0700

This discussion keeps circling back to a need for some type of
private initial binding process between a device that is to be newly
introduced to a network and some agent of the network. In ISA100.11a
and other industrial protocols, we tend to call that process
"provisioning" to keep the terminology distinct from the later
"commissioning" process when the device is actually installed in a
physical plant and brought actively into the network.

In the industrial space the provisioning process often can be
performed months in advance, when a device is placed in inventory at
a plant site as a usable spare, although when the physical device is
itself large -- e.g., a 3 m diameter valve -- initial provisioning
is likely to occur as the first phase of installation and
commissioning.

Consideration of the above scenario makes it clear that the
provisioning process needs to communicate one or more site-specific
credentials (of some type), in a local temporal and spatially secure
manner, that later forms the basis for establishing mutual
authentication, even though the identity of the eventual target
network for the device may not be determinable at the time that the
provisioning process occurs (e.g., when the device is placed in
inventory).

Rather than go on and on about alternative A) below, perhaps our
time would be better spent in focusing on the above-summarized
process to find acceptable secure alternatives to alternative A)
that can provide the needed basis for subsequent mutual
authentication. In other words, I am suggesting a change in focus
for this discussion based on the presumption that alternative A)
will be seen in the future as always unacceptable. If that is the
case, what can we propose as a relatively painless, virtually
product-cost-free alternative that all 6TiSCH devices can be
required to support.

It was in that spirit that I proposed using an LED as a
low-sensitivity photodiode (which admittedly is a 2-terminal device,
not what I had sleepily misstated as a 3-terminal device), together
with a smartphone. The smartphone need not be connected to the
target network if it merely serves as an optical relay proxy to
convey credentials between a device currently in the network and the
new device.

Conveying a device credential to a network agent or proxy might be
performed simply by having the smartphone scan a QR code on the
device or its packaging, then conveying that optically or by RF to
the proxy or agent, or by normal WiFi or cell connection to a site
JCE.

Clearly the above is an inadequate solution as stated, which would
require further extension; it is placed on the table only to
stimulate thought about how a human agent and a contemporary
ubiquitous device such as a smartphone might be used as a
short-duration relatively-secure channel between the device and a
network proxy. The key element is that, for many IoT devices, it is
the human installer or human agent for the site where the device
will be installed that is acting as an authenticating intermediary
in tying the device-to-be-installed to the site's network(s).

-Tom

=====

On 2015.05.07 07:20, Thomas Watteyne
wrote:

Kris,

We need a way for
people who say "I don't want the hassle of security, and I
can't

afford a
chip with ECC" (e.g. start state A) to still transition to
something that is

secure after
the join process is over.

That would be
great, but if a node starts from A, I don't see how it can
authenticate the network, and the network authenticate the
node. I must be missing something.

The simplest is
B: a node is configured during commisioning with a key, a
shared secret withe the JCE. If the node/JCE can challenge
each other with that key, they have authenticated each
other. Through this mechanism, the JCE can setup all the
keying material used during the operational stage of the
network.

I feel like the
above paragraph is generally agreed upon.

Thomas

On Tue, May 5, 2015 at 6:39 PM, Kris
Pister <[email-masked]>
wrote:

Let's see
if we can get agreement at a high level on what we're trying
to do

A) nothing

B) PSK(s)

D) certificate(s) from

iv) desired network(s)

The mote might start with things in {B, C, D} at
manufacture, or by some out of band

The keys that a mote gets in 1 and 4 may all be generated by
a single entity (e.g. JCE)

or they may be generated locally from one or more Master
Keys.

Some of the things in the desired end state (like 1 or 5)
might have been installed

We need a way for people who say "I don't want the hassle of
security, and I can't

afford a chip with ECC" (e.g. start state A) to still
transition to something that is

ksjp

6tisch mailing list

[email-masked]

---

From: "Timothy J. Salo" <[email-masked]>
Date: Thu, 07 May 2015 10:58:47 -0500

> It was in that spirit that I proposed using an LED as a low-sensitivity
> photodiode (which admittedly is a 2-terminal device, not what I had
> sleepily misstated as a 3-terminal device), together with a smartphone.
> The smartphone need not be connected to the target network if it merely
> serves as an optical relay proxy to convey credentials between a device
> currently in the network and the new device.
>
> performed simply by having the smartphone scan a QR code on the device
> or its packaging, then conveying that optically or by RF to the proxy or
> agent, or by normal WiFi or cell connection to a site JCE.

This seems like an area where a specification should include
requirements, but not solutions.  That is, it might be reasonable
to require that devices include some process by which certain values
are configured as part of the provisioning and/or commissioning process.

Typically, some vendors will do this better than others.  For example,
some vendors might enable customers to do this themselves with a
smartphone app, while vendors may require a trip to the factory.
Personally, I don't think that standards should try to minimize
the advantage that a vendor might gain by making greater
investments in technology (in commissioning/provisioning technology,
in this case).

Some beacon vendors are starting to do some interesting things in this
area.  In particular, some beacons can be configured from a smartphone.
Of course, beacons have the advantage that they have a Bluetooth LE
interface.

And, at least one beacon vendor permits customers to load new firmware
into a beacon from a smartphone.  (Shouldn't the ability to load
new firmware into be node be a security requirement?)

-tjs

---

From: Alper Yegin <[email-masked]>
Date: Fri, 8 May 2015 11:07:53 +0300

I'd recommend we document consecutive steps that bring a piece of 6tisch product from manufacturing to full operation to EOL -- in the context of security.
Agreeing to naming the steps (e.g., provisioning, bootstrapping, commissioning, etc.) and input&output of each step would be useful.

Once we do that and get on the same page, then we can proceed to what parts of that we can standardize in this WG.

A lot of early-steps are very scenario- (product type, deployment type, etc.) specific. So, we cannot possibly reach the ideal IETF case: mandating one and only credential/algorithm/protocol to use. 

my o.o2 cents

Alper

---

From: Rene Struik <[email-masked]>
Date: Fri, 08 May 2015 09:49:03 -0400

Dear colleagues:

Great suggestion.

I would suggest a systematic approach to this, where we start with the 
join protocol scenario described in great detail in Section 1.3 of 
draft-struik-6tisch-security-architectural-considerations-01. While the 
description in that section does not cover all deployment scenarios 
(yet) {as also acknowledged in that draft}, it provides a good starting 
point. This also seemed to be in line of what was suggested as next step 
during the informal (non-IETF) discussion on Thursday evening, March 24, 
2015, by various stakeholders in Dallas.

In my mind, I think we can capture most deployment scenarios and 
ultimately view these as an extension of the approach in that section.

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Kris Pister <[email-masked]>
Date: Mon, 11 May 2015 12:12:22 -0700

> if a node starts from A, I don't see how it can authenticate the network,
 > and the network authenticate the node.

Thomas - you and Michael and Robert and Tom are all correct that option A is
not good and should be avoided.  Certainly anyone who cares about 
security will
not use it.  I don't want to waste too much time on it, other than to 
say that:
1) I hope that 6TiSCH is deployed broadly, in many applications
2) many product developers don't think that they need security, or they 
think
that it will be too hard, or too burdensome on installation, ..., e.g.
* "I can't afford a processor that will run ECC."
* "my installers/customers won't be able to type in numbers, or take 
pictures with
cell phones, etc."
The result is that products show up with lousy or zero security, as in 
option A.
I'm not a fan of option A, but I'm enough of realist to know that there 
will be
products that end up there.  If there's anything that we can do in the 
joining
process to minimize the vulnerability of such products then that's a 
"nice to have".

ksjp

On 5/7/2015 7:20 AM, Thomas Watteyne wrote:
>     afford a chip with ECC" (e.g. start state A) to still transition
>     to something that is
> That would be great, but if a node starts from A, I don't see how it 
> can authenticate the network, and the network authenticate the node. I 
> must be missing something.
>
> The simplest is B: a node is configured during commisioning with a 
> key, a shared secret withe the JCE. If the node/JCE can challenge each 
> other with that key, they have authenticated each other. Through this 
> mechanism, the JCE can setup all the keying material used during the 
> operational stage of the network.
>
> On Tue, May 5, 2015 at 6:39 PM, Kris Pister <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The mote might start with things in {B, C, D} at manufacture, or
>     by some out of band
>     The keys that a mote gets in 1 and 4 may all be generated by a
>     single entity (e.g. JCE)
>     Some of the things in the desired end state (like 1 or 5) might
>     have been installed
>     afford a chip with ECC" (e.g. start state A) to still transition
>     to something that is
>     [email-masked] <mailto:[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 May 2015 17:58:20 -0400

> 2) many product developers don't think that they need security, or
    > they think

The problem with the "push button" to validate the DH exponent is that
you still have to do the DH exponentiation... (whether ECDHA or not).

If one can do the DH to get the pfs, then one could also use a
pre-established shared secret to authenticate, with a trip back to the
vendor.   But, that's (B).

One can also use (B) without the DH, SIM-card-like.

Can we agree that (A) is out of scope for now?

---

From: Kris Pister <[email-masked]>
Date: Mon, 11 May 2015 16:15:35 -0700

> Can we agree that (A) is out of scope for now?
OK.
I want to come up with a good solution for (B), (C), etc.  We should 
certainly
focus on that.  We all dislike (A), but hopefully everyone has also read
http://embedded-computing.com/articles/understand-the-risk-associated-with-the-internet-of-things-why-would-a-hacker-attack-my-toaster/
(forwarded to me by several people on the list :) )
A lot of toaster makers are going to say "We don't need security". The 
house you save
may be your own. :)

ksjp