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

[Xavi Vilajosana Guillen <[e-mail]>]

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 <[e-mail]>:

> 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.
> --
> [e-mail]
>



-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
([phone]
[e-mail] <[e-mail]>
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
[image: Universitat Oberta de Catalunya]
­