Early Review of draft-richardson-6tisch--security-6top-04
review-richardson-6tisch--security-6top-04-secdir-early-kivinen-2014-12-04-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. This is an early review, so these comments are mostly useful for
the draft authors. This is first of the early reviews, I assigned this
to myself in addition to normal round robin assignment. This is
because I have been involved with 802.15.4 quite a lot lately, and I
assumed that I would have something to say about this draft...

This draft describes the part of the security architecture of the
6tisch. This draft describes how new node bootstraps itself to be part
of the network and how to configure the node to be part of the 6tisch
schedule.

This document suggest a method where there is sepearate joining
network with well-known key to be used when joining the network, i.e.
device would first find out this joining network, talk to devices
there, and then get the authorization to join the real network and get
keys for that.

This method does not work that well. First of all, I am not sure how
many 15.4 coordinators can actually send out multiple becons at the
same time. Usually a node starts sending beacons by calling
MLME-START.request operation and while it does not say it directly it
seems to indicate that new call to it will change the existing
parameters of the beacon configuration, not start sending both sets,
i.e. there is no way to use that to send two different set of beacons
with that call. There is manual call MLME-BEACON.request to send
beacons out, but it takes lots of its configuration from PIB, thus it
cannot really be different from the normal beacon (that call is mostly
meant for non-beacon enabled PANs where beacons are sent when other
node asks for them by sending beacon request frame).

So I do not think it is possible to have separate network for joining
only. This would mean that there would be only one network, i.e one
set of beacons, and all those beacons would be protected by the same
key, and in draft proposes that to be the well-known key.

The security of the TSCH depends on the fact that all nodes in the
network knows the globally shared unique timestamp called ASN
(absolute slot number). This value is used when calculating the
AES-CCM Nonce, and if node can be tricked to belive ASN is lower than
it was when the node last time sent packets out this can cause
security vulnerability. The ASN is distributed to the nodes inside the
beacon frames (inside the TSCH Syncronization IE, that is inside the
Nested MLME Payload IE).

If the beacons are protected by the well known key, then attackers
will know that key, thus they can fake the beacons and perhaps trick
the already existing members joining the network to use wrong ASN, or
use wrong TSCH parameters / schedule.

Regardless what key is used protecting the beacon, the attacker can
always replay old frames giving out old ASN, so protection against
wrong ASN needs to be done so that each node will store the last ASN
they have seen to the stable storage, and does not allow the ASN to go
backwards ever (same thing is done for the non-TSCH nodes for each
frame counter they are using for sending or receiving). This storing
of the ASN needs to happen every time device goes to sleep (or it
needs to know time itself).

Protection against the invalid TSCH parameters / schedule would also
be very useful and using well-known key for beacons would not provide
that.

Because of all those reason, I would recommend that the beacons do use
separate beacon key, which is NOT well known, but which is generated
by the PAN coordinator, and distributed to everybody in the network
(i.e. global broadcast key for beacons). 

As the joining node will need to know the parameters of the network,
before it can know when it is allowed to send data to network, it
needs to be able to read the beacon, so the beacon would need to use
authentication only, i.e. no encryption would be used. The 802.15.4
has special text in there saying that when doing beacon scanning the
device will store the information from the beacons it see even when it
cannot do security processing for the frame. I.e. even if the node
does not know the authentication key used to protect the beacon, it
can see the beacon, parse it, and extract all parameters from it.

The nodes knowing the beacon key, can actually verify the beacon MIC
(message integrity code) and be sure it is proper and generated by the
coordinator belonging to the network.

As I described earlier, this does not protect the nodes who has lost
sync with network (i.e. who has been sleeping so long that they do not
know the current schedule and current ASN) against replays of the
beacons by attacker. On the other hand as the AES-CCM nonce also has
the extended address of the sender there, it is enough for the node to
make sure he will never go backwards for ASN when sending packets
using current network key. If he is tricked to send frames using wrong
ASN, then other real nodes in the network will not be able to read
those, but that is just DoS, not real security vulnerability, which
would happen if he would generate frame with old ASN he has already
used, which would generate same AES-CCM nonce.

--

Another thing that could be clarified in this draft is the use of
802.15.9. The 15.9 allows generating pairwise keys between the nodes
in the network and after those are created, it allows distributing the
multicast or broadcast keys from one peer to another.

So when looking at the figure 1 in the draft, the 802.15.9 would
happen between the beacon and the router solicitation. I.e. when
joining node sees the beacon from a coordinator it can start 15.9
negotiation with the coordinator and create pairwise keys with the
coordinator. This connection could either be properly authenticated
using for example raw-public keys, certificates or EAP (depending what
key management protocol is used inside the 15.9), or it could be just
unauthenticated first step protection. Then all future communications
from the joining node to the coordinator (== joining assistant
(proxy)) would be protected by that key.

If real authentication method is used between the joining node and
joining assistant, then this would actually be only thing needed to
set up the security.

For example if the joining node uses raw-public key and the join
assistant then makes query to the JCE whether this key (or more
accurately hash of key) should be allowed to join the network or not,
then the JCE could verify that hash of the key is one of the devices
that should be allowed to join the network. I.e. the manufacturer
could create the raw public key on the device when it is manufactured,
and then give the hashes of the keys of all devices shipped to site in
electronical format (CD, over the network, whatever), and those hashes
could be listed in the JCE before the device is ever turned on. When
the device is turned on, the JCE would already know that this device
is one of the new devices...

This of course does not protect the device from joining wrong network.

It is not clear for me how the current draft plans to solve the
authentication problem. It has some text about using certificates and
chains and certificates with serial numbers in format of extended
address etc, but I do not think it really solves the problem. I do not
think it is enough for the JCE to know that this device is in fact
manufactured by company X, i.e. it has certificate from CA from X. JCE
would rather know that this is actually the device that was supposed
to be installed on site, i.e. I think it will need some kind of
whitelist listing devices allowed to connect. For that whiteliste it
is better to use hash of the public key on the device, than the
extended address.

--

One more aspect that is missing in the draft (or it might be, that it
is on some other draft), is the fact that security in 15.4 is quite
low level, i.e. almost everything is left for the upper layer (== this
layer) to solve.

For example the AES-CCM keys are identified using the Key Source and
Key Index (and Key Identifier mode specifying how those are
interpreted), but the management which Key Source and Key Index is
used, is left for the upper layer to solve. I.e. when this draft says
we use some key to protect the beacons (whether it is the well known
key, or the per network broadcast beacon key), we need some document
to map that to Key Source and Key Index. I.e. how does the node know
which key is to be used when sending beacons, and how is it
identified.

This document (or some other document) can either specify protocol to
distribute this information, or we can use fixed set for those. I.e.
we could for example say that the beacon broadcast key is always
"owned" by the JCE, which means that the Key Source of the key is
always extended address of the JCE (== 8 octet KeySource). Or we can
specify that short address of 0xfff0 from PAN 0xfff0 is reserved for
the beacon broadcast key (== 4 octet KeySource field).

I.e. we need to specify how different keys in the network are really
identified.

--

Hopefully these comments are useful for going forward with this draft.
This draft is still in quite early phases, and actually reviewing it
for more concrete proposals is hard, but on the other hand reviewing
it in this early phases means that bigger changes can be done... 
-- 
kivinen at iki.fi