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

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 10 Feb 2017 17:33:58 +0100

Dear Tero,

thanks for your detailed review. I will proceed with the revision in the
following days and provide a new version.

have a nice weekend,
Xavi

2017-02-10 17:15 GMT+01:00 Tero Kivinen <[email-masked]>:

> 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.
> --
> [email-masked]
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Tue, 14 Feb 2017 17:56:34 +0100

Dear Tero,

thanks so much for your reviews. Find inline our responses. We proceed to
publish another version of the draft including the resolutions proposed in
this email.

regards,
===============================================================================

===============================================================================

-----------------------------
REMARK 1
-----------------------------

In section 4.6 the text

Perhaps rewrite that:

-----------------------------
ANSWER 1
-----------------------------

We have adopted the proposed text. Thanks.

===============================================================================

-----------------------------
REMARK 2
-----------------------------

-----------------------------
ANSWER 2
-----------------------------

We have adopted the proposed text. Thanks.

===============================================================================

-----------------------------
REMARK 3
-----------------------------

-----------------------------
ANSWER 3
-----------------------------
We have changed the organization of Section 8 by commenting two possible
situations:

1) when the attacker knows the keys (K1, K2)
2) when the attacker does not know the keys.

The discussed text refers when the attacker do not know the keys.

===============================================================================

-----------------------------
REMARK 4
-----------------------------

The text

-----------------------------
ANSWER 4
-----------------------------

secExempt parts have been removed.

===============================================================================

-----------------------------
REMARK 5
-----------------------------

Then we have text:

-----------------------------
ANSWER 5
-----------------------------

A sentence is added to indicate that in Section 4.5.2.

===============================================================================

-----------------------------
REMARK 6
-----------------------------

-----------------------------
ANSWER 6
-----------------------------

A paragraph have been added, thanks for the suggestion.

===============================================================================

-----------------------------
REMARK 7
-----------------------------

-----------------------------
ANSWER 7
-----------------------------

We set this requirement to the 6TiSCH Layer as proposed.

===============================================================================

-----------------------------
REMARK 8
-----------------------------

> 6)EDITORIAL ISSUE 4
>
> Same for other names (slotOffset == Timeslot, chOffset == Channel Offset).
in it

           Timeslot = 0x0000 (2B)

to

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

-----------------------------
ANSWER 8
-----------------------------

Thanks Tero we corrected this following your advice.

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Feb 2017 14:11:05 +0200

> publish another version of the draft including the resolutions proposed in

The resolutions implemented in the draft-ietf-6tisch-minimal-20 are
ok, and I think the document should be ready now.
-- 
[email-masked]