Subject: [secdir] Secdir review of draft-ietf-6tisch-minimal-17

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Dec 2016 18:08:41 +0200

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This is my extra security review of this draft, this document was also
assigned another security reviewer, but as I am very familiar with
802.15.4-2015 I wanted to review this document also. This draft
explains how the IEEE Std 802.15.4 TSCH mode can be used with IETF
protocols, and what would be the minimal setup to get the network
running so much that more complicated things can be done over it.

This document has serious issues.

First of all there is no security considerations section at all. There
is section 4.6 which contains certain security related issues, but it
mostly just lists the required security features (or misfeatures) but
does not do any kind of security analysis.

Secondly this document includes text suggesting fixed cryptographic
key ("6TiSCH minimal15") which can be used to protect some parts of
the 6TiSCH network. As there is no security considerations there is no
analysis what attacker can do when it knows this key K1.

We have seen several attacks lately against IoT devices where
attackers have found out the default admin key and used it to attack
the network. By proposing static fixed key in the RFC it gives
indication that such setup might be secure, thus vendors implementing
this might do similar thing, and use fixed key. As this key would be
known by everybody joining the network, it will not stay secret, and
that will mean it will leak out and it does not protect anything
anymore.

This document should require that both K1 and K2 keys MUST be unique
to the network and the bootstrapping procedures specified later (there
is already work ongoing in the 6TiSCH WG to do them) will be used to
distribute them to new joining nodes.

----------------------------------------------------------------------

Another major issue is that the section 4.6 also forbids using any
clear text frames, even for the joining process. This will make it
impossible to actually to run the bootstrap procedure over the same
network that will be used later for normal traffic. The IEEE Std
802.15.4 do allow exemptions so that nodes which have configured
security to be on for all frames, can temporarely receive clear text
frames from the certain nodes just for this kind of joining
procedures.

This document does not explain how they can be used, and actually
forbids using them.

----------------------------------------------------------------------

The missing security section should include at least following
information:

- If attacker knows the K1 key, what kind of damage can it do. This is
  especially important even if unique keys are used per network, as
  those keys might be shared using weak methods and might be short to
  make the setup easy. Even if we say in this document that static K1
  MUST NOT be used, people are going to use it, so we need to tell
  implementors what the attackers can then do.

- Most likely also explain that running networks might not want to
  accept completely new set of parameters through the EBs even if they
  are authenticated, and perhaps suggest that the whole networks is
  first shut down before new set parameters are taken in to use.

- Explain that using static key is never safe if there is possibility
  that the network might be restarted, as the security of the AES CCM
  relies on that the ASN never goes back (which might happen if the
  network is restarted).

- Explain that 802.15.4 link security do provide authentication and
  encryption, but it DOES NOT provide replay protection for the TSCH
  mode. This means that all protocols run over 802.15.4 TSCH network
  must provide replay protection themselves.

There might be others, but this came to my mind in few minutes of
thinking this issue.

----------------------------------------------------------------------

Other serious issues are (and actually some of the things above in
more detail):

--

Section 4.6 has text saying that:

   All link-layer frames MUST be secured by the link-layer security
   mechanisms defined in IEEE802.15.4 [IEEE802154-2015]: link-layer
   authentication and link-layer encryption.

Enhanced Beacons cannot have link-encryption as the joining node needs
to be able to see the ASN contained in the payload IE. Thus Enhanced
Beacons MUST be authenticated, but MUST NOT be encrypted. All other
frames MUST be both encrypted and authenticated.

Also the initial joining node does not know the K1 nor K2, thus it
cannot use link-layer security mechanisms at all, thus this paragraph
is completely wrong.

Remove this whole paragraph.

--

Section 4.6 has text saying:

   Key K1 is used to authenticate EBs.  As defined in Section 4.5.2, EBs
   MUST be authenticated only (no encryption).  This facilitates logical
   segregation of distinct networks.

This is also wrong. Firstly the 4.5.2 does not define that EBs MUST be
authenticated. Perhaps it is trying to say that "EBs, as defined in
section 4.5.2, MUST be authenticated only (no encryption)."

The last sentence "This facilitates logical segregation of distinct
networks." does not have any meaning. The extended address and the PAN
ID of the coordinator sending EB, will tell which network this is. The
K1 is not visible in the frames, thus it cannot provide logical
segregation. If unique K1 key is used for every single network, it can
provide good way of verifying that the node sending the EB is part of
the same network than the receiving node. I would just remove the last
sentence.

--

Section 4.6 has text saying:

   For early interoperability testing, value 36 54 69 53 43 48 20 6D 69
   6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1.

This text does not belong to this document at all. We do have policy
saying we do not do clear text passwords in the IETF, and having fixed
password in clear in the RFC do count as clear text password at least
for me.

Also if we provide any key in the RFC, the changes are that most
implementations will simply use that key, meaning the K1 does not
provide any protection at all after that.

Remove the whole section, or if you want to keep it, then replace the
title of the section to "Link-Layer Insecurity", and add note in the
abstract telling that this document proposes insecure way of doing
things.

Note, that K1 is used to authenticate the EB, thus anybody who knows
the K1, can start sending fake EB messages, and mess up the network by
changing the channel offsets or similars, i.e., knowning K1 will
provide very easy way of doing DoS attack against the whole network,
and the network will most likely need to be completely reformed before
the single packet DoS attack is recovered.

Also early interoperability testing keys should be agreed with the
people doing interoperability testings, or in the interoperability
events, not in the drafts or RFCs.

----------------------------------------------------------------------

Nits, and smaller issues:

--

I think IEEE wants that their standards are referenced as "IEEE Std
802.15.4", not IEEE802.15.4. Might be good idea to replace use that,
and if shorter version is needed just add "802.15.4" to terminology
and define it to mean IEEE Std 802.15.4, and then use the shorter
version in rest o fthe document. We would not want people to write
"RFC.6550", as that would just look funny...

--

In this document the term "Slotframe length" is used to specify the
number of timeslots in slotframe. All other documents (802.15.4-2015,
802.15.4e-2012 and draft-ietf-6tisch-terminology-07) use term
"Slotframe size" for that. See IEEE Std 802.15.4-2015 section 7.4.4.3
TSCH Slotframe and Link IE.

Why not use same term for the same thing?

--

IEEE Std 802.15.4-2015 also section 7.4.4.3 TSCH Slotframe and Link IE
also has field called "Number of Links", which match Number of
scheduled cells (active) in Figure 1. Terminology document has both
Cell and Link, and Link uses the IETF meaning of it, not the IEEE
meaning of it. Should we provide both names for the field, especially
as the Appendix A uses the IEEE naming.

Same for other names (slotOffset == Timeslot, chOffset == Channel
Offset). Also the IEEE Std 802.15.4-2015 moved away from using link
Options as hex number (0x0f), and instead lists the separate
bit-fields in it (tx, rx, shared, timekeeping), as does the Appendix
A.

Also as slotOffset/Timeslot and chOffset/Channel Offset are 16-bit
numbers, it might be better to express them as 0x0000 instead of 0x00.

The macLinkType is bit funny as it is one TSCH MAC PIB attribute in
per link structure in macLinkTable. It might be better to refer it as
LinkType given to the MLME-SET-LINK.request primitive, which will then
create the new entry for the macLinkTable and fill in the values given
to the primitive. Note, that this value is not transmitted in the EB,
it specifies that this link is used to send EBs. 

--

In Figure 2 the legend specifies TX and RX, but the actual figure uses
Tx and Rx. Change the legend to use Tx and Rx too.

--

In the section 4.5.1 the reference to the IEEE Std 802.15.4-2015 is
wrong. The value of the PAN ID compression bit is not in the Table
7-6, but is Table 7-2. I.e. change

     	    	       	    The value of
   the PAN ID Compression bit is specified in Table 7-6 of the
   IEEE802.15.4 2015 specification, and depends on the type of the
   destination and source link-layer addresses (short, extended, not
   present).

to:

     	    	       	    The value of
   the PAN ID Compression bit is specified in Table 7-2 of the
   IEEE Std 802.15.4-2015 specification, and depends on the type of
   the destination and source link-layer addresses (short, extended,
   not present).

(also change the 802.15.4 2015 to 802.15.4-2015).

--

The text

   While listening for EBs, a joining node set its own PAN ID to 0xffff
   in order to meet the filtering rules in the IEEE802.15.4
   specification [IEEE802154-2015].

is wrong and should be removed. The IEEE Std 802.15.4-2011 required setting PAN
ID to 0xffff when doing active or passive scan, but that kludge was
removed in the IEEE Std 802.15.4-2015, and now the filtering rules
specifically checks whether we are doing scanning and if so, we do not
do normal filtering rules, but do special filtering rules needed for
scanning.

--

Typo in 4.5.2 the TSCH Slotframe and Link IE is misspelled with
SlotFrame. Replace SlotFrame with Slotframe.

--

In section 7.2 there is text saying:

      Frame types BEACON and COMMAND are queued with higher priority
      than frame types DATA and ACK.

This is wrong. The ACK is sent inside the same timeslot than the frame
it is acking to. It is never sent through queue. Remove the "and ACK"
from the sentence.

--

In the appendix the examples have mostly the same field names than in
the IEEE Std 802.15.4-2015, but some of the fields have bit different
spelliongs. Is there reason for this?

Spelling changes:

"GroupID" vs "Group ID"

"SubID" vs "Sub-ID" (all MLME IEs)

"TimeSlot" vs "Timeslot"

"TimeSlot template ID" vs "Timeslot ID"

"Ch. Hopping" vs "Channel Hopping"

"Channel Hopping Sequence ID" vs "Hopping Sequence ID"

"SlotFrame Handle" vs "Slotframe handle"

"SlotFrame Size" vs "Slotframe size"

"Link Option" vs "Link Options"

"tx,rx,shared,timekeeping" vs "TX Link, RX Link, Shared Link, Timekeeping"

--

In the A.4 example the example uses old name for the bit 6, i.e. the
"Frame Counter Size" was renamed to "ASN in Nonce" in 802.15.4-2015 to
better reflect what it really means.
-- 
[email-masked]