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 extra security review of this draft, this document was also assigned another security reviewer, but as I am very familiar with 802.15.4-2015 I wanted to review this document also. This draft explains how the IEEE Std 802.15.4 TSCH mode can be used with IETF protocols, and what would be the minimal setup to get the network running so much that more complicated things can be done over it. This document has serious issues. First of all there is no security considerations section at all. There is section 4.6 which contains certain security related issues, but it mostly just lists the required security features (or misfeatures) but does not do any kind of security analysis. Secondly this document includes text suggesting fixed cryptographic key ("6TiSCH minimal15") which can be used to protect some parts of the 6TiSCH network. As there is no security considerations there is no analysis what attacker can do when it knows this key K1. We have seen several attacks lately against IoT devices where attackers have found out the default admin key and used it to attack the network. By proposing static fixed key in the RFC it gives indication that such setup might be secure, thus vendors implementing this might do similar thing, and use fixed key. As this key would be known by everybody joining the network, it will not stay secret, and that will mean it will leak out and it does not protect anything anymore. This document should require that both K1 and K2 keys MUST be unique to the network and the bootstrapping procedures specified later (there is already work ongoing in the 6TiSCH WG to do them) will be used to distribute them to new joining nodes. ---------------------------------------------------------------------- Another major issue is that the section 4.6 also forbids using any clear text frames, even for the joining process. This will make it impossible to actually to run the bootstrap procedure over the same network that will be used later for normal traffic. The IEEE Std 802.15.4 do allow exemptions so that nodes which have configured security to be on for all frames, can temporarely receive clear text frames from the certain nodes just for this kind of joining procedures. This document does not explain how they can be used, and actually forbids using them. ---------------------------------------------------------------------- The missing security section should include at least following information: - If attacker knows the K1 key, what kind of damage can it do. This is especially important even if unique keys are used per network, as those keys might be shared using weak methods and might be short to make the setup easy. Even if we say in this document that static K1 MUST NOT be used, people are going to use it, so we need to tell implementors what the attackers can then do. - Most likely also explain that running networks might not want to accept completely new set of parameters through the EBs even if they are authenticated, and perhaps suggest that the whole networks is first shut down before new set parameters are taken in to use. - Explain that using static key is never safe if there is possibility that the network might be restarted, as the security of the AES CCM relies on that the ASN never goes back (which might happen if the network is restarted). - Explain that 802.15.4 link security do provide authentication and encryption, but it DOES NOT provide replay protection for the TSCH mode. This means that all protocols run over 802.15.4 TSCH network must provide replay protection themselves. There might be others, but this came to my mind in few minutes of thinking this issue. ---------------------------------------------------------------------- Other serious issues are (and actually some of the things above in more detail): -- Section 4.6 has text saying that: All link-layer frames MUST be secured by the link-layer security mechanisms defined in IEEE802.15.4 [IEEE802154-2015]: link-layer authentication and link-layer encryption. Enhanced Beacons cannot have link-encryption as the joining node needs to be able to see the ASN contained in the payload IE. Thus Enhanced Beacons MUST be authenticated, but MUST NOT be encrypted. All other frames MUST be both encrypted and authenticated. Also the initial joining node does not know the K1 nor K2, thus it cannot use link-layer security mechanisms at all, thus this paragraph is completely wrong. Remove this whole paragraph. -- Section 4.6 has text saying: Key K1 is used to authenticate EBs. As defined in Section 4.5.2, EBs MUST be authenticated only (no encryption). This facilitates logical segregation of distinct networks. This is also wrong. Firstly the 4.5.2 does not define that EBs MUST be authenticated. Perhaps it is trying to say that "EBs, as defined in section 4.5.2, MUST be authenticated only (no encryption)." The last sentence "This facilitates logical segregation of distinct networks." does not have any meaning. The extended address and the PAN ID of the coordinator sending EB, will tell which network this is. The K1 is not visible in the frames, thus it cannot provide logical segregation. If unique K1 key is used for every single network, it can provide good way of verifying that the node sending the EB is part of the same network than the receiving node. I would just remove the last sentence. -- Section 4.6 has text saying: For early interoperability testing, value 36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1. This text does not belong to this document at all. We do have policy saying we do not do clear text passwords in the IETF, and having fixed password in clear in the RFC do count as clear text password at least for me. Also if we provide any key in the RFC, the changes are that most implementations will simply use that key, meaning the K1 does not provide any protection at all after that. Remove the whole section, or if you want to keep it, then replace the title of the section to "Link-Layer Insecurity", and add note in the abstract telling that this document proposes insecure way of doing things. Note, that K1 is used to authenticate the EB, thus anybody who knows the K1, can start sending fake EB messages, and mess up the network by changing the channel offsets or similars, i.e., knowning K1 will provide very easy way of doing DoS attack against the whole network, and the network will most likely need to be completely reformed before the single packet DoS attack is recovered. Also early interoperability testing keys should be agreed with the people doing interoperability testings, or in the interoperability events, not in the drafts or RFCs. ---------------------------------------------------------------------- Nits, and smaller issues: -- I think IEEE wants that their standards are referenced as "IEEE Std 802.15.4", not IEEE802.15.4. Might be good idea to replace use that, and if shorter version is needed just add "802.15.4" to terminology and define it to mean IEEE Std 802.15.4, and then use the shorter version in rest o fthe document. We would not want people to write "RFC.6550", as that would just look funny... -- In this document the term "Slotframe length" is used to specify the number of timeslots in slotframe. All other documents (802.15.4-2015, 802.15.4e-2012 and draft-ietf-6tisch-terminology-07) use term "Slotframe size" for that. See IEEE Std 802.15.4-2015 section 7.4.4.3 TSCH Slotframe and Link IE. Why not use same term for the same thing? -- IEEE Std 802.15.4-2015 also section 7.4.4.3 TSCH Slotframe and Link IE also has field called "Number of Links", which match Number of scheduled cells (active) in Figure 1. Terminology document has both Cell and Link, and Link uses the IETF meaning of it, not the IEEE meaning of it. Should we provide both names for the field, especially as the Appendix A uses the IEEE naming. 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. Also as slotOffset/Timeslot and chOffset/Channel Offset are 16-bit numbers, it might be better to express them as 0x0000 instead of 0x00. The macLinkType is bit funny as it is one TSCH MAC PIB attribute in per link structure in macLinkTable. It might be better to refer it as LinkType given to the MLME-SET-LINK.request primitive, which will then create the new entry for the macLinkTable and fill in the values given to the primitive. Note, that this value is not transmitted in the EB, it specifies that this link is used to send EBs. -- In Figure 2 the legend specifies TX and RX, but the actual figure uses Tx and Rx. Change the legend to use Tx and Rx too. -- In the section 4.5.1 the reference to the IEEE Std 802.15.4-2015 is wrong. The value of the PAN ID compression bit is not in the Table 7-6, but is Table 7-2. I.e. change The value of the PAN ID Compression bit is specified in Table 7-6 of the IEEE802.15.4 2015 specification, and depends on the type of the destination and source link-layer addresses (short, extended, not present). to: The value of the PAN ID Compression bit is specified in Table 7-2 of the IEEE Std 802.15.4-2015 specification, and depends on the type of the destination and source link-layer addresses (short, extended, not present). (also change the 802.15.4 2015 to 802.15.4-2015). -- The text While listening for EBs, a joining node set its own PAN ID to 0xffff in order to meet the filtering rules in the IEEE802.15.4 specification [IEEE802154-2015]. is wrong and should be removed. The IEEE Std 802.15.4-2011 required setting PAN ID to 0xffff when doing active or passive scan, but that kludge was removed in the IEEE Std 802.15.4-2015, and now the filtering rules specifically checks whether we are doing scanning and if so, we do not do normal filtering rules, but do special filtering rules needed for scanning. -- Typo in 4.5.2 the TSCH Slotframe and Link IE is misspelled with SlotFrame. Replace SlotFrame with Slotframe. -- In section 7.2 there is text saying: Frame types BEACON and COMMAND are queued with higher priority than frame types DATA and ACK. This is wrong. The ACK is sent inside the same timeslot than the frame it is acking to. It is never sent through queue. Remove the "and ACK" from the sentence. -- In the appendix the examples have mostly the same field names than in the IEEE Std 802.15.4-2015, but some of the fields have bit different spelliongs. Is there reason for this? Spelling changes: "GroupID" vs "Group ID" "SubID" vs "Sub-ID" (all MLME IEs) "TimeSlot" vs "Timeslot" "TimeSlot template ID" vs "Timeslot ID" "Ch. Hopping" vs "Channel Hopping" "Channel Hopping Sequence ID" vs "Hopping Sequence ID" "SlotFrame Handle" vs "Slotframe handle" "SlotFrame Size" vs "Slotframe size" "Link Option" vs "Link Options" "tx,rx,shared,timekeeping" vs "TX Link, RX Link, Shared Link, Timekeeping" -- In the A.4 example the example uses old name for the bit 6, i.e. the "Frame Counter Size" was renamed to "ASN in Nonce" in 802.15.4-2015 to better reflect what it really means. -- kivinen@iki.fi