Mališa Vučinić writes: > Thanks Tero for the proposal. Is the current "key_usage" registry enough to > fully configure the security tables for the non-index modes?
I guess so. I mean in most cases the KeyIdModes 1-3 are similar, i.e., multicast/broadcast keys which are owned by somebody. In the KeyIdMode 1 the owner is implicit (usually coordinator or similar well known node on the network), in case of KeyIdModes 2 and 3 it is explicit. So any of those modes can be used with any ke y usage. For pairwise (KeyIdeMode 0) things are bit different, for example sending beacons using pairwise keys is not really useful. So for pairwise keys key usages like 6TiSCH-K2-* are something that are usuful. > When a pledge/node receives a Link_Layer_Key corresponding to > KeyIdMode 2, how does it know which other node to use it for? i.e. I > want to encrypt data towards node B with K3 and data towards node C > with K4. In here the KeyIdMode 2 could be used as replaced of KeyIdMode 1 for any key usage values. I.e., you have multiple JRCs in the network and you want to make sure each of them can generate broadcast keys, you could use KeyIdMode 2 instead of 1, and use the PanID + Short address of the JRC to indicate which of JRC created the key. Of course the JRCs would still need to distribute those keys to everybody, and share them between each other also, but they could create them independently, i.e., they would not need to coordinate which key index is going to be used. This would add 4 octets to each frame, so KeyIdMode 1 is better, but some environments this could be useful. To negotiate K3, or K4 or similars, would most likely require more complicated protocol than what is here, i.e., that would need to include for example the multicast group address for which this key is used etc. That protocol could then still share this exactly same Link_Layer_Key structure to transport keys (and it could use new key usage value like 6TiSCH-GRP-ENC-MIC-128 or similar to indicate this is key for multicast traffic for DATA and ACKNOWLEDGEMENT frames). -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
