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

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

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,
===============================================================================

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.

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

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

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.

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

We have adopted the proposed text. Thanks.

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

-----------------------------
REMARK 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.

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

We have adopted the proposed text. Thanks.

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

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

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.

-----------------------------
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

      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. ...

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

secExempt parts have been removed.

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

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

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?

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

A sentence is added to indicate that in Section 4.5.2.

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

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

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.

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

A paragraph have been added, thanks for the suggestion.

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

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

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".

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

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

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

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

>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
>
>
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

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

Thanks Tero we corrected this following your advice.

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]
­