Telechat Review of draft-ietf-6tisch-minimal-19
review-ietf-6tisch-minimal-19-secdir-telechat-kivinen-2017-02-15-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.  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 rereview of this draft. My original review found quite a
lot of issues, and most of them have already been taken care of. There
are still some remaining issues.

Summary of the review: There are Issues.

--

In section 4.6 the text

      Key K1 is used to authenticate EBs.  As defined in Section 4.5.2,
      EBs MUST be authenticated only (no encryption).

is bit misleading, as while section 4.5.2 do define EBs it does not
tell anything about the security of them.

Perhaps rewrite that:

      Key K1 is used to authenticate EBs. EBs MUST be authenticated
      only (no encryption), and their contents is defined in the
      Section 4.5.2.

--

In section 4.6 the text about secExempt is bit incorrect.

      If neither key K1 nor key K2 is pre-configured, the JN uses the
      secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process
      EBs, and relies on the key distribution phase to learn K1 and K2.
      Once K1 and K2 are learned, the secExempt mechanism MUST be
      disabled and EBs properly authenticated using K1.

The secExempt is needed both in the the joining node and the node
receiving the frames from the joining node. The joining node usually
do not use secExempt method, as it does not have keys, so it will not
turn security processing of the 802.15.4 on until it has keys. So
while still in joining process, it has security turned off and it can
receive frames without security.

The joining assistant (or was it proxy in new terminology) will then
receive frames without security and when it receives them it should
then configure the security layer or the 802.15.4 so that from that
specific joining node the frames are allowed to come in without
security. After the joining process is finished, those secExempt rules
installed are removed.

So the text should be written as:

      If neither key K1 nor key K2 is pre-configured, the JN will will
      accept EBs as defined in the Section 6.3.1.2 of the 802.15.4,
      i.e., they are passed forward even "if the status of the
      unsecuring process indicated an error". The JN will then run key
      distribution phase to learn K1 and K2. During that process the
      node JN is talking to, uses the secExempt mechanism (IEEE Std
      802.15.4, Section 9.2.4) to process frames from JN. Once the key
      distribution phase is done the node which has installed
      secExempts for the JN MUST clear the exception rules installed.

--

In the section 8 there is text saying:

      If both K1 and K2 are pre-provisioned, a joining node can
      distinguish legitimate from fake EBs, and join the legitimate
      network.  The fake EBs have no impact.

This is incorrect, as just few paragraphs before it was noted, that
"Fixed secrets will not remain secret.".

Same applies also if only K1 is pre-provisioned. I.e., if K1 is
pre-provisioned attacker can physically extract the key from one
device, and then use that K1 to attack whole network by sending
authenticated EBs. So in all cases attacker can most likely cause the
joining node to initiate the joining process to the attacker. If
joining process includes authentication and distributing K2 to joining
node, then joining node will fail, and joining node will notice this.

If both K1 and K2 are pre-provisioned and attacker extracted them from
one of the nodes earlier, joining node will not notice the attack.

--

The text

      If neither K1 nor K2 is pre-provisioned, a joining node uses the
      secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process
      all correctly-formatted EBs.  It therefore may mistake a fake EB
      for a legitimate one and initiate a joining process to the
      attacker. ...

describes the secExempt system again, and does it again incorrectly,
so it would be better to just remove secExempt parts from there, and
leave them only in 4.6. I.e., change this to:

      If neither K1 nor K2 is pre-provisioned, a joining node may
      mistake a fake EB for a legitimate one and initiate a joining
      process to the attacker. ...

--

Then we have text:

   Once the joining process is over, the node that has joined can
   authenticate EBs (it knows K1).  This means it can process their
   contents and use EBs for synchronization.

But if the K1 is pre-provisioned and we can then assume that attacker
knows it, the attacker can then send authenticated fake EBs to the
node even after that. So this section should analyze what those fake
EBs can do. If we limit the minimal so that none of the parameters in
the EBs can be changed during the lifetime of the network (i.e., the
network timing, used channels, slotframe size will remain static etc),
then the attacker cannot gain too much. It can still mess up the nodes
trying to join the network as explained earlier.

We do have the text in the section 1 saying:

      	   When following this specification, the learned schedule is
   the same for all nodes and does not change over time.  

which would indicate that all the parameters sent out in EB (except
ASN and Join metrics), but do we have somewhere the text saying that
nodes MUST ignore EBs which try to change the parameters?

--

The security consideration section is missing the text about the fact
that TSCH does NOT provide replay protection for retransmitted frames.
I.e., if node A transmits frame X and attacker messes up the ACK from
the node B acking that frame, then the node A will retransmit that
frame X again using new ASN. The 802.15.4 layer would normally ignore
the retransmission as it has seen the frame counter before, but as
TSCH uses ASN instead of frame counter, this protection is not
available when using TSCH.

This means that all upper layer protocols MUST be resistant to this
kind of attacks, and they MUST have mechanims to prevent this.

For example if the 6top sends ADD message saying "Allocate 3 new
cells", there must be sequence number (SeqNum) and the 6top protocol
needs to notice that if it gets two ADD message with same SeqNum it
must ignore the replayed one.

This might not be obvious to the users of the 6tisch, as 802.15.4 for
example do provide protection against retransmissions done by link
layer.

--

In section 8 (security consideration) there is text:

   The MAC layer SHOULD keep track of anomalous events and report them
   to a higher authority.  For example, EBs reporting low Join Metrics
   for networks which can not be joined, as described above, may be a
   sign of attack.  

I do not think we should put any requirements for the MAC layer in
this document. Also in the 802.15.4 the Join Metrics etc processing is
done by the higher layer, not by MAC. Perhaps change the "The MAC
layer" to "The 6TiSCH layer".

--

>From my previous review:

> 6)EDITORIAL ISSUE 4
> 
> 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.
> 
> DISCUSSION
>
> Don’t see what change is requested here

I was wondering why we are using two different terms for same things.
I.e. figure 1 uses slotOffset and chOffset, but the appendix A uses
the "Timeslot" and "Channel Offset" instead. Perhaps using "Channel
Offset" for "chOffset" in whole document, and add "slotOffset" to the
Append A.2 similarly than what was done for "(Cells)", i.e. change 

           Timeslot = 0x0000 (2B)

to

           Timeslot (slotOffset) = 0x0000 (2B)

The second item is that the saying "link Option 0x0f" in figure 1 is
incorrect, as Link Options is not numeric field anymore, it is
bitfield having bits "TX Link", "RX Link", "Shared Link",
"Timekeeping" and "Priority" as is already explained in section 4.2.
The figure 1 still insist using 0x0f. I think it is better to change
that to list individual flags, i.e. change

   |                                |   (link Option 0x0f)         |   |

in figure 1 to

   |                                |   (Link Options: TX Link,    |   |
   |                                |    RX Link, Shared Link,     |   |
   |                                |    Timekeeping)              |   |

Also the figure 1 has line:

   |                                |   (LinkType    ADVERTISING)  |   |

as part of the Number of scheduled cells and it has EB marked as "X".
The LinkType is not transmitted over the wire at all, it is parameter
given to the MLME-SET-LINK.request primitive in the 802.15.4 MAC. So
claiming it being part of EB is misleading.

Perhaps removing that LinkType from the figure 1, but add footnote
that applies to the Number of scheduled cells saying that "This cell
is also set to have LinkType of ADVERTISING)".

--

So this document is in much better shape now, but I still think there
is issues that needs to be fixed before it can be approved.
-- 
kivinen@iki.fi