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