> 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:
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 protected]
<mailto:[email protected]>> wrote:
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
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
