+1 as well. I like the idea of K1 with the notion that the stack understands the granularity of security that it gets. I understand from René that today, the upper layer code path may be the wrong one if there was crypto as opposed to in-the-clear. I gather that there may be a need to specify something there so that the quality of the key is qualified for upper layers to proceed accordingly. This being said:
If K1 is hardcoded in the standard, we are getting a standard compatibility check (an Ethertype of sorts) and a MIC If the admin overrides K1 with a largely shared key within his admin domain, we are getting an administrative subnetting and a MIC If the admin tightly controls the distribution of K1 to a few well–managed devices, we can encrypt the beacons and we are getting a rather protected network that leaks minimal information on its operation. I’m reading that that if we encrypt the beacon, and the nonce containing the ASN is needed to decrypt, then we need to get the ASN some other way, or we need to leave some piece of the frame in the clear, which CCM* could do if that’s what we want to do. I’m not sure I have the full story there but that looks OK. Lots of flexibility there. The alternate to K1 seems to be a new IE with a managed network ID + a MIC that cannot be verified until later in the process. Pro of the alternate: absolute network identification as opposed to potential 10 ^MICsize error. Con: more bytes in the air, and no protection against transmission errors until the key is obtained. As a human, I’m bad at fathoming very large numbers, but the chances that the K1 key that a device has matches a frame from the wrong network and then that the frame still looks good baffles me. And if that happens, probably the beginning of the join process will discover the mismatch anyway, so the ultra-rare occurrence would only delay the join, not screw up things. So the alternate does not look like a great competition to K1. What am I missing? Pascal From: 6tisch [mailto:[email protected]] On Behalf Of Thomas Watteyne Sent: vendredi 24 avril 2015 00:39 To: Kristofer PISTER Cc: [email protected]; Tero Kivinen Subject: Re: [6tisch] EBs are only used in joining, not normal operation (Re: a little puzzle) +1 I feel very unconfortable with the idea of receiving a packet for which authentication fails, but nevertheless use the data inside it. I know that you can read the 15.4 state machine to do this, but I just disagree with it completely. Option 4 involves a secret key for EBs which the joining node doesn't have, but then trusts the EBs nevertheless, and then learns the key from the JCE when it's already joined. I don't get why this offers any more security than no MIC at all. On Thu, Apr 23, 2015 at 6:52 PM, Kristofer PISTER <[email protected]<mailto:[email protected]>> wrote: Charlie is excited to hear more about option 4! :) > Use MICs on EBs, with a secret key distributed during the joining > process, and add vendor specific IE to identify the network. This seems like a chicken and egg problem. In order to get the secret key for the EBs, you need to go through the joining process...which starts with receiving an EB... I think that the confusion here is in thinking that EBs are involved in normal network operation. They are not. EBs are just used during joining, to get a new mote aware of the existence of a network, so that it can go through the joining process, and receive the secret keys that are used in normal network operation. Having Mallory forge EBs does NOT mess up the existing network. No mote which has joined the network is listening to EBs. EBs are not used in synchronization of motes that are already in the network, or anything else. EBs are just used to initiate the join process, and nothing more. Once motes are joined to a network, they use a randomly generated secret key(s) K2. They do not use EBs for anything. ksjp On Thu, Apr 23, 2015 at 6:48 AM, Tero Kivinen <[email protected]<mailto:[email protected]>> wrote: Kris Pister writes: > Alice and Bob make wireless temperature sensors that run a 6tisch stack. > Charlie owns a nationwide chain grocery store and is rolling out 6tisch > everywhere. > Zelda sells wireless toys that use 802.15.4e. > Mallory is always lurking. > > Charlie needs to decide if and how to use message integrity checks on > enhanced beacons. > He thinks that he has three options: > 1) don't use MICs on EBs. > 2) use MICs on EBs, with a secret key > 3) use MICs on EBs, with a well-known key But the best option is to use option 4 4) Use MICs on EBs, with a secret key distributed during the joining process, and add vendor specific IE to identify the network. In this case the EBs are authenticated with MIC, but when the Alice and Bob's devices try to connect it they do not know the key, so they cannot verify the authentication information, but as the frames are not encrypted they can still see the vendor specfic IE, and check that it matches what they expect it to match. This way they will be able to filter out EBs which they want to hear. I.e. after finding the EB which has suitable IE they start joining process to that network. During that joining process they will get the secret key used to protect the EBs and secret key used to protect the normal data traffic. After that they can use the draft-ietf-6tisch-minimal to talk to the network, and they can use it securely as they can now authenticate the IEs sent in the EBs, and they know Mallory cannot fake those, as Mallory does not know the secret key, so they do not need to do any other protocol. If they would be using the option 3, they cannot trust anything EBs have, thus they cannot use draft-ietf-6tisch-minimal at all, as Mallory could mess up the network very easily by just sending few EBs with wrong data in IEs. Also now as the Charlie has IE which is used to separate the networks from each other, when it makes new network used for its cashier machines, and it does not want to share the cashier machine keys with the temperature sensors it wants to use different keys, and it also wants to make sure that the temperature sensors do not needlessly try to join the other network, he can just use different content for that IE. Also as the those two networks use different secret keys, both networks can trust the data sent on their EBs. This EB secret key is different for every site, and might even be rekeyed every now and then. And yes, Mallory can still send fake EBs with same IE content, trying to trick the temperature sensors to join his network, but as the joining process authentication fails, the temperature sensors will not join his network, but try to find better network i.e the real network. > But if Charlie uses option 3, a well-known key, Mallory will be able to > spoof EBs. > Of course, if he uses no MIC at all, Mallory will also be able to spoof EBs. And if Mallory can spoof EBs he can easily mess up the network completely. This also means that devices cannot use draft-ietf-6tisch-minimal as they cannot trust anything that is sent in the EBs, so some other protocol is used to know even the shared slots used to talk to anybody. > What should Charlie do? Use option 4... -- [email protected]<mailto:[email protected]> _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
