Xavier Vilajosana writes: > after the last call we would like to close the security section in > minimal. We wrapped up all comments from the previous days and from > the meeting and here is our proposal:
As you can guess, I disagree with the text. Does this text replace the whole "Security considerations" section or only some of it? > This draft assumes the existence of two cryptographic keys, K1 and > K2. EBs SHOULD be authenticated with key K1. First of all, the correct therm is data integrity, not authenticate. Authenticate would mean that we would actually provide verification that the identity of a peer entity in a current association is as claimed. Here we just provide protection that data is not modified. See RFC 4949 for "data integrity", "data integrity service", "authenticate", and "authentication". In which cases it is ok not to integrity protect the EBs with K1? What happens if EBs are not protected by K1. I.e. what kind of attacks are possible in such case, and why do you think we do not need to care about them here. This is security consideraions section so you should explain those things here. Note, that answers to those depends a lot where the minimal is used. In the bootstrap case we can say that the bootstrap process provides its own authentication and data integrity services for its messages, thus L2 protection for the EBs are not really needed. For the fall-back mode of operation when no dynamic scheduling solution is availabe or functional, this is not true and in such cases I think K1 protection is mandatory. For the third use case i.e. "during early interoperability testing and development" this is mostly non-issue, as none of those networks are used in real production use. > DATA, ACKNOWLEDGEMENT, and MAC COMMAND frame types SHOULD be > authenticated and encrypted with key K2. If I have understood correctly there are actually lot of cases where the other frame types are not encrypted, but are only integrity protected. At least that was my understanding from the comments people made earlier. Here we still say that they SHOULD be both integrity protected and encrypted. Again in which case this SHOULD is not needed, i.e. why it is not MUST. What are the exceptions where you can send those frames without integrity protection? I agree that encryption might not be needed, if upper layer protocols provide end to end data confidentiality service, so that might be reason why we do not need encryption, but hop by hop L2 data integrity would still be useful to save resources in the network level, especially if there is routing protocol routing traffic between multiple nodes. The attacker could inject packets to the network and cause them to be forwarded through the network and consume resources on the network unless data frames are not protected. Also this assumes that K2 is in the devices already before they start running the joining process if all data, acknowledgement, and mac command frames need to use it. I do not think this is true, so most likely while using minimal for the bootstrap case the K2 might not be there yet, thus those frames needs to be sent without protection, and also those packets might need to forwarded in the network wasting resources from the network. On the other hand during the fall-back case the K2 should already be there, and we should use it always. > For early interoperability, K1 MAY be set to "6TiSCH minimal15". This again would need to explain what kind of attacks attacker can do when he knows the K1. It does not change anythign for the bootstrap case, but there is huge issues in the fall-back mode case. And if this is only meant for the interoperability testing case, then I do not think we should mention it here, but instead add it to the test specification that is used when running those interoperability tests. This is how it is done normally. And if you still claim that there would be uses for well-known K1 because of "network spearation issue", then this needs to be mentioned, and explainined why you think this is true. On the other hand that text does not belong to the security considerations section as it is not security issue, as well-known K1 does not provide any security services. So this K1 definition should be moved away from security considerations section to its own separate section, and in security considerations section there should only be the warnings saying that if well-known key is used for K1, then that does not provide ANY security benefits, and it MUST NOT be used in production network requiring any kind of security. > K2 SHOULD be a randomly generated high entropy cryptographic key. > Key distribution is out of scope. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
