+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]> 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]> 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] >> > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
