Kristofer PISTER writes: > Tero - you bring up a good point that after all of the discussion of > this issue we have still not done a good job explaining it, since > it's clear that there are still misunderstandings.
Clearly. > The text in section 4.6 says "This specification assumes the > existence of two cryptographic keys." That is incorrect, and should > be changed. I propose "This specification assumes the existence of > one protocol identifier, P1, and one cryptographic key K2. P1 > provides no security." I do not undestand why you want to throw away the protection K1 can provide? If you have two cryptographic keys, K1 and K2, they both will provide protection against different types of attack. K1 makes sure that no outsider who does not know K1 can create fake EBs. This means that sleeping nodes waking up and wanting to resync themself to the network, which has not changed its K1 during the nodes sleep, can do so by just seeing K1 protected EB. It also means that there is at least some protection for the devices already in the network against malicious EBs which could try to change the network parameters of the network. If K1 is not secret, then both of these protections are lost. K2 is used to provide confidentiality and authenticity of the other messages than EBs. There is actually no reason why K1 and K2 needs to be separate, but both of them needs be secret and unique. > Let me go over the reasoning behind having P1. Any implementation > of 6TiSCH has one of > three choices for message integrity on the EBs: > 1) use no message integrity > 2) use a well-known protocol identifiier, with no security value > 3) use a secret key And only option 3 makes any sense if any security is needed. If you are willing to run network without any security you can then go with option 1 and 2, but don't use them if you want security. > There is ample evidence that sending 15.4 frames without message > integrity is problematic, so we'd prefer not to do option 1. I think most of that evidence is based on the 802.15.4 frames and not 802.15.4-2015 EB frames with TSCH related IEs. Yes, getting random garbage looking like 11-21 byte beacon frame with valid checksum is going to happen every now and then. Having random garbage with length 48 bytes to match EB with acceptable TSCH related IEs is much more improbable. As joining process is only very small amount of the use of the network, we should not try to optimize the performance during joining process, and sacrifice the security of the rest of the network use time. After the joining process is done, the node knows K1, and then it can get much better protection against random garbage. > Option 2 provides no security, but it does provide message > integrity, and it provides some level of confidence that the sender > of the frame is using the same version of the protocol that the > receiver is using. Yes, it does provide that for the joining process, but sacrifices the security of the rest of the time, i.e., after the node has joined the network. Also option 2 only causes issues for the nodes trying to join the network. I.e., they might try to join network they think are there, because they see random garbage that looks like valid EB. So what. They waste a bit of resources there, but if they see valid EB they can pick that. Also easy solution to that is to wait for two valid EBs from the same coordinator before trying to join. I.e., when node sees first EB, they will know where the next EB can be, so they can jump to that channel to listen for it and so on on until it finds second copy of the same EB. After that they can be sure that there is network there. They still do not know if that network is correct for them to join in, but using option 2 does not provide that information either. It only tells that there is some (or multiple) networks using same P1. And if we put P1 in the RFC everybody will be using that same P1. > Option 3 provides all of the benefits of option 2, plus some level > of security. It is a fine option, but it assumes the existence of a > pre-distributed cryptographic key K1, which is a non-starter. No, it does require pre-distributed cryptographic K1. It requires clients to join the network without knowing K1, and after they have joined the network they will learn the K1 and K2, and after that they can start using K1 and K2 to secure the traffic in the network. The 802.15.4 do provide a way for nodes to parse EBs and join the networks WITHOUT knowing the key used to protect the EB. Also even if you do know K1, you still cannot use that to protect the first EB. The first EB contains the ASN, which is needed to validate the EB, and before the ASN can be read from the IE contained in the EB, the EB frame needs to be authenticated, which is not possible as the ASN is not known... I.e., chicken and egg problem. Because of this the 802.15.4 do allow EBs to be passed higher layer even if their security processing failed (either because of not knowing the key to protect it, or not knowing the ASN used to calculate Nonce). So the higher layer can then take the ASN out from there, configure that to the MAC layer, and send some unprotected joining messages to the coordinator, asking to join the network, and the coordinators are using the SecExempt flag to allow those joining nodes to bypass the security checks for the incoming traffic for those joining messages so those messages can be processed in clear tetx even when everything else is mandated to be protected. So to repeat this one more time: Using known K1 or P1 or whatever it is called, is BAD idea, and it is better to use unique K1, which is distributed to the network at the same time as K2 is generated for the network nodes. -- kivi...@iki.fi _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
