Michael Richardson writes: > But, 6tisch (minimal) is not targetted at that kind of use. > It's targetted at industrial users that need deterministic work.
I have always wondered for what this 6tisch is meant for, as everybody seems to have different requirements. Some say, we cannot do provisoning as nobody touches the devices before they are installed. This is not true in industrial users, there they can do provisioning before sending them to factory. There was complains that neighbour toy store messes up networks for new devices, but for deterministic work you do not care about the bootstarpping phase, as that is only one time operation etc. All of this of course makes discusissons about issues hard, as everybody is talking about different things. > Minimal is further targetted at well... interop. If it is only for interop, there is no point of publishing it as RFC at all. If so then I do not care whether there is well-known key put in to the internet-draft. https://tools.ietf.org/html/draft-ietf-ipsec-internet-key-00 On the other hand I still think it is better to put that in the test specification for the interop event. > Let me put it differently: Bluetooth didn't specify a default key, and didn't > do enrollment for headsets sanely, and now the "K1" *and* "K2" keys are "0000" > We can't keep people from doing stupid things. Yes. On the other hand for most headsets you need to put them in pairing mode before they initiate setup and I think they exchange some kind of random keys during that phase that is then used later... > We need known K1 in order to bootstrap to a KMP in order to set up > K2. No we dont. The K1 can be completely random, and the joining node does not need to know it. I repeat: The K1 can be completely random and the joining node does not need to know it. Only device who really needs to know the K1 is the device sending out EBs, as he needs it to be able to calculate the MIC... All other devices who know K1 are able to verify that EB is sent by device who knows the key. Those who do not know the K1 cannot verify the MIC, but they can still get all information in the EB. The 802.15.4 standard mandates that devices joining the network must be able to extract all information from beacons even if they do not know the keys. And when using TSCH the beacon cannot be encrypted, thus it has only MIC, meaning all information from it can be extracted. > If K1 has to be provisioned, then K2 will get set at the same time, > and K1 and K2 will get set to "0000". The K1 and K2 can both be generated by running KMP during the joining process. The K1 will protect the EBs and every coordinator sending EBs in the network should use the same key to provide data integrity for EBs. If EBs are not used at all after the initial bootstrap phase (which some people seem to say will happen), then this K1 protection does not provide anything. On the other hand on some networks I can see some real uses for EBs also after the initial bootstrap, but those uses will require the EBs to integrity protected for those devices who are already part of network. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
