I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. This is an early review, so these comments are mostly useful for the draft authors. This is first of the early reviews, I assigned this to myself in addition to normal round robin assignment. This is because I have been involved with 802.15.4 quite a lot lately, and I assumed that I would have something to say about this draft... This draft describes the part of the security architecture of the 6tisch. This draft describes how new node bootstraps itself to be part of the network and how to configure the node to be part of the 6tisch schedule. This document suggest a method where there is sepearate joining network with well-known key to be used when joining the network, i.e. device would first find out this joining network, talk to devices there, and then get the authorization to join the real network and get keys for that. This method does not work that well. First of all, I am not sure how many 15.4 coordinators can actually send out multiple becons at the same time. Usually a node starts sending beacons by calling MLME-START.request operation and while it does not say it directly it seems to indicate that new call to it will change the existing parameters of the beacon configuration, not start sending both sets, i.e. there is no way to use that to send two different set of beacons with that call. There is manual call MLME-BEACON.request to send beacons out, but it takes lots of its configuration from PIB, thus it cannot really be different from the normal beacon (that call is mostly meant for non-beacon enabled PANs where beacons are sent when other node asks for them by sending beacon request frame). So I do not think it is possible to have separate network for joining only. This would mean that there would be only one network, i.e one set of beacons, and all those beacons would be protected by the same key, and in draft proposes that to be the well-known key. The security of the TSCH depends on the fact that all nodes in the network knows the globally shared unique timestamp called ASN (absolute slot number). This value is used when calculating the AES-CCM Nonce, and if node can be tricked to belive ASN is lower than it was when the node last time sent packets out this can cause security vulnerability. The ASN is distributed to the nodes inside the beacon frames (inside the TSCH Syncronization IE, that is inside the Nested MLME Payload IE). If the beacons are protected by the well known key, then attackers will know that key, thus they can fake the beacons and perhaps trick the already existing members joining the network to use wrong ASN, or use wrong TSCH parameters / schedule. Regardless what key is used protecting the beacon, the attacker can always replay old frames giving out old ASN, so protection against wrong ASN needs to be done so that each node will store the last ASN they have seen to the stable storage, and does not allow the ASN to go backwards ever (same thing is done for the non-TSCH nodes for each frame counter they are using for sending or receiving). This storing of the ASN needs to happen every time device goes to sleep (or it needs to know time itself). Protection against the invalid TSCH parameters / schedule would also be very useful and using well-known key for beacons would not provide that. Because of all those reason, I would recommend that the beacons do use separate beacon key, which is NOT well known, but which is generated by the PAN coordinator, and distributed to everybody in the network (i.e. global broadcast key for beacons). As the joining node will need to know the parameters of the network, before it can know when it is allowed to send data to network, it needs to be able to read the beacon, so the beacon would need to use authentication only, i.e. no encryption would be used. The 802.15.4 has special text in there saying that when doing beacon scanning the device will store the information from the beacons it see even when it cannot do security processing for the frame. I.e. even if the node does not know the authentication key used to protect the beacon, it can see the beacon, parse it, and extract all parameters from it. The nodes knowing the beacon key, can actually verify the beacon MIC (message integrity code) and be sure it is proper and generated by the coordinator belonging to the network. As I described earlier, this does not protect the nodes who has lost sync with network (i.e. who has been sleeping so long that they do not know the current schedule and current ASN) against replays of the beacons by attacker. On the other hand as the AES-CCM nonce also has the extended address of the sender there, it is enough for the node to make sure he will never go backwards for ASN when sending packets using current network key. If he is tricked to send frames using wrong ASN, then other real nodes in the network will not be able to read those, but that is just DoS, not real security vulnerability, which would happen if he would generate frame with old ASN he has already used, which would generate same AES-CCM nonce. -- Another thing that could be clarified in this draft is the use of 802.15.9. The 15.9 allows generating pairwise keys between the nodes in the network and after those are created, it allows distributing the multicast or broadcast keys from one peer to another. So when looking at the figure 1 in the draft, the 802.15.9 would happen between the beacon and the router solicitation. I.e. when joining node sees the beacon from a coordinator it can start 15.9 negotiation with the coordinator and create pairwise keys with the coordinator. This connection could either be properly authenticated using for example raw-public keys, certificates or EAP (depending what key management protocol is used inside the 15.9), or it could be just unauthenticated first step protection. Then all future communications from the joining node to the coordinator (== joining assistant (proxy)) would be protected by that key. If real authentication method is used between the joining node and joining assistant, then this would actually be only thing needed to set up the security. For example if the joining node uses raw-public key and the join assistant then makes query to the JCE whether this key (or more accurately hash of key) should be allowed to join the network or not, then the JCE could verify that hash of the key is one of the devices that should be allowed to join the network. I.e. the manufacturer could create the raw public key on the device when it is manufactured, and then give the hashes of the keys of all devices shipped to site in electronical format (CD, over the network, whatever), and those hashes could be listed in the JCE before the device is ever turned on. When the device is turned on, the JCE would already know that this device is one of the new devices... This of course does not protect the device from joining wrong network. It is not clear for me how the current draft plans to solve the authentication problem. It has some text about using certificates and chains and certificates with serial numbers in format of extended address etc, but I do not think it really solves the problem. I do not think it is enough for the JCE to know that this device is in fact manufactured by company X, i.e. it has certificate from CA from X. JCE would rather know that this is actually the device that was supposed to be installed on site, i.e. I think it will need some kind of whitelist listing devices allowed to connect. For that whiteliste it is better to use hash of the public key on the device, than the extended address. -- One more aspect that is missing in the draft (or it might be, that it is on some other draft), is the fact that security in 15.4 is quite low level, i.e. almost everything is left for the upper layer (== this layer) to solve. For example the AES-CCM keys are identified using the Key Source and Key Index (and Key Identifier mode specifying how those are interpreted), but the management which Key Source and Key Index is used, is left for the upper layer to solve. I.e. when this draft says we use some key to protect the beacons (whether it is the well known key, or the per network broadcast beacon key), we need some document to map that to Key Source and Key Index. I.e. how does the node know which key is to be used when sending beacons, and how is it identified. This document (or some other document) can either specify protocol to distribute this information, or we can use fixed set for those. I.e. we could for example say that the beacon broadcast key is always "owned" by the JCE, which means that the Key Source of the key is always extended address of the JCE (== 8 octet KeySource). Or we can specify that short address of 0xfff0 from PAN 0xfff0 is reserved for the beacon broadcast key (== 4 octet KeySource field). I.e. we need to specify how different keys in the network are really identified. -- Hopefully these comments are useful for going forward with this draft. This draft is still in quite early phases, and actually reviewing it for more concrete proposals is hard, but on the other hand reviewing it in this early phases means that bigger changes can be done... -- kivinen at iki.fi