Kris Pister writes: > This is my proposed text for all of section 8. This does not force > anyone to > use well-known keys, or 32 bit MICs, or send EBs unencrypted.
EBs cannot be encrypted ever, so that is not a point. > It does make it easy to do interop. People who want to use > pre-configured secret keys, long MICs, encrypted EBs, or no keys at > all, are free to do so. > > ksjp > --------------- > 8. Security > Minimal assumes the existence of two keys, K1 and K2. EBs MAY be > authenticated with key K1 using security level 1 (32 bit MIC). Is there any reason to specify the security level 1 there? I mean if it is MAY, then there is no point of mentioning it. On the other hand EBs cannot be sent using security levels 5-7, so that most likely should be mentioned. > DATA, ACKNOWLEDGEMENT, and MAC COMMAND frame types SHOULD be > authenticated with key K2 using security level 1. For this I would just say that those frame types SHOULD be protected using key K2, and leave the security level unspecified. I do see why you have SHOULD NOT encrypt for DATA frames. > For early interoperability, K1 MAY be set to "6TiSCH minimal15". This would need to provide explination why this is done, and what are the effects caused by sing such key, i.e. that no protection is offered in that and it is exactly same as not using K1 at all, but instead sending everything without MIC (note, that this is security considerations section, so for security those two are identical, even when there are other differences (filtering, different packet lengths etc) in frames. Of course when you end up having paragraph or two explaining that in here, I would expect that in last call phase people will be asking, "why are you then doing that", so be prepared to explain that too. Or you could move all of that out from here, and say that EBs might be unauthenticated and unprotected, and then have separate section explaining that in such cases the security level 1 could be used to filter minimal implementations from other 802.15.4 TSCH networks. > K2 SHOULD be a randomly generated high entropy cryptographic key. > Key distribution is out of scope. That text is ok. > EBs MAY be filtered based on PANID. No they really cannot be. The PAN ID is generated by the PAN coordinator when he forms the network. The exact algorithm to pick one is left outside the scope of 802.15.4, but "This is achieved by choosing a PAN ID that is not currently used by any other network within the radio communications range." Also if somehow there is another PAN in the radio range which has same PAN ID then "If this conflict happens, the PAN coordinator and its devices shall perform the PAN ID conflict resolution procedure". Then: "The next higher layer of the PAN coordinator may then perform an active scan and, using the information from the scan, select a new PAN ID. The algorithm for selecting a suitable PAN ID is outside the scope of this standard". Note, that if it does not pick new PAN ID then next beacon will trigger this PAN ID Confliction notification again. If it does pick new PAN ID, it will send that to everybody using broadcast coordinator realignment MAC command, which will then reconfigure the whole network to use PAN ID. I.e. the PAN ID can be changed at any time during the normal operation of the network. Thus PAN Coordinator cannot know which PAN ID it is going to be using. Also while doing active or passive scanning, the 802.15.4 MAC will return all networks (and their PAN IDs) in radio range. What you can do, is to select the network you want to join by selecting the best network in radio range from those returned by scanning. That selecting function might use PAN ID as selector in some unspecified manner, but sa PAN ID is not stable nor it cannot be fixed, that is bit hard. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
