Pascal Thubert (pthubert) writes: > The only questions left are: > > 1) should we provide a default value for K1 in the security section?
Do you actually mean that the draft would specify some preconfigured key for K1? I hope not, as I am pretty much sure that would be really bad idea. I think it is bad idea for the security considerations section to mention "well-known keys" at all in there. I would be much more happy if the text would be changed to "Key distribution is out of scope of this document, but examples include pre-configured keys at the nodes or shared keys among peers.", i.e. removeal of the well-known keys from the text completely. Especially as we are talking about the security section. Anyways it is unclear for me what is the use for this minimal. The draft lists uses like: - Early interoperability testing - Network bootstrap before any schedule is installed - Fall-back mode in case that dynamic scheduling mechanisms fail or are not available For early interoperability testing pre-configured keys works fine, i.e. people doing interoperability testing can define the "well-known key" they are going to be using in the testing. This is what we had in early IPsec testing, i.e. we used keys like "0123456789abcdef" or "makemetastygoat" as pre-shared key in interop testings. For the fall-back mode it looks like the minimal and EBs would be used for real production cases, not just bootstrapping, so the claims that EB protection does not matter is not true. I myself think that minimal could be used as only mechanism in certain types of environments, but for those cases the real keys would be needed to protect EBs. For bootstrapping I still think there is no benefit from using well-known keys compared to having no security at all, and for no security it would be clear that there is no security, there would be no false sense of security. I.e. if EBs do not have any use in security sense (which I do not really belive, I think they do have security implications), then it would be same to not to protect them at all. Vendor specific IE to tell that this network is for this use would provide much better multiplexing and network selection properties than well-known keys used by everybody. > 2) which IEEE document should the spec reference? > > For 1) it was suggested that it would help interop if we did. So the proposal > on the table is to add a well-known key as a default that can be modified at > commissioning time. > > For 2) the spec makes explicit references deep into 802.15.4e so the proposal > on the table is to maintain the reference to 802.15.4e as it stands now. I would update it to use 802.15.4 without year, or without reference to the 4e. The 802.15.4 reference do include all amendments for it, including 4e. This is same think that we do say that this uses TCP, we do not say that it uses TCP as specified in RFC793, but not the updates done in the RFC1122, 3168, 6093, 6528). For TCP we should use STD0007 as the reference, and similarly we should use "IEEE Std 802.15.4" here. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
