Pascal, I believe Tero refers to the idea developed in https://tools.ietf.org/html/draft-struik-6tisch-security-considerations-01#section-1.1 in which a JN hears an authenticated EB, tries to authenticate it, which fails as it does not have the key, but still reads the payload of the packet (sent in the clear, since the EB is not encrypted). [personally, I'm not a fan of this approach]
Qin correctly points out that the CRC will provide (weak) protection against transmission errors. You are right that an additional MIC strengthens that protection. All, please correct/amend what I have wrong. Thomas On Wed, May 6, 2015 at 4:41 PM, Qin Wang <[email protected]> wrote: > Pascal, > > The protection against transmission errors on EBs rely on the CRC in PSDU, > right? > > Thanks > Qin > > > > On Wednesday, May 6, 2015 6:34 PM, Pascal Thubert (pthubert) < > [email protected]> wrote: > > > Hum... > > But then, if the JN does not know K1, how can it validate the MIC? Do we > have another way to protect against transmission errors on EBs? > > Cheers, > > Pascal > > > > -----Original Message----- > > From: 6tisch [mailto:[email protected]] On Behalf Of Michael > Richardson > > Sent: mercredi 6 mai 2015 04:07 > > To: [email protected] > > Subject: Re: [6tisch] Shipping minimal > > > > > > Tero Kivinen <[email protected]> wrote: > > >> But, 6tisch (minimal) is not targetted at that kind of use. > > >> It's targetted at industrial users that need deterministic work. > > > > > I have always wondered for what this 6tisch is meant for, as > everybody > > > seems to have different requirements. Some say, we cannot do > > > provisoning as nobody touches the devices before they are installed. > > > This is not true in industrial users, there they can do provisioning > > > before sending them to factory. > > > > They *can*, but they don't want to... too much $$$$. > > The contractors who install the devices haven't the skills, and the > > subcontractors, are often not actually trusted. This is actually in > parts of the > > industrial requirements for ROLL (RFC5673) and was in > draft-ietf-roll-rpl- > > industrial-applicability-02.. that lead to 6tisch. > > > > > There was complains that neighbour toy > > > store messes up networks for new devices, but for deterministic work > > > you do not care about the bootstarpping phase, as that is only one > > > time operation etc. > > > > Tom Phinney gave two examples from the refining situation. > > The first part was that pieces of the refinery are often sold or leased > to > > competitors. That means that the entire sensor network needs to go > through a > > new bootstrap without being disassembled, and needs to do this in the > midst of > > another network. > > > > The toy store could well have two or three networks. > > 1) the control network for the building/mall. > > 2) the control network for the toy store itself. > > 3) the actual junk actually being sold in the toy store. > > > > > All of this of course makes discusissons about issues hard, as > > > everybody is talking about different things. > > > > True. > > > > >> Minimal is further targetted at well... interop. > > > > > If it is only for interop, there is no point of publishing it as RFC > > > at all. If so then I do not care whether there is well-known key put > > > in to the internet-draft. > > > > I don't know if it will have a life beyond the interop. > > > > >> Let me put it differently: Bluetooth didn't specify a default key, > and didn't > > >> do enrollment for headsets sanely, and now the "K1" *and* "K2" > keys are > > "0000" > > >> We can't keep people from doing stupid things. > > > > > Yes. On the other hand for most headsets you need to put them in > > > pairing mode before they initiate setup and I think they exchange > some > > > kind of random keys during that phase that is then used later... > > > > I see your point. > > > > > No we dont. > > > > > The K1 can be completely random, and the joining node does not need > to > > > know it. > > > > > I repeat: > > > > > The K1 can be completely random and the joining node does not > > > need to know it. > > > > > Only device who really needs to know the K1 is the device sending > out > > > EBs, as he needs it to be able to calculate the MIC... > > > > So, really, we don't need to use K1 on the EBs at all, is your point. > > Therefore there is no point in having EBs authenticated at all.... > > > > >> If K1 has to be provisioned, then K2 will get set at the same time, > > >> and K1 and K2 will get set to "0000". > > > > > The K1 and K2 can both be generated by running KMP during the > joining > > > process. The K1 will protect the EBs and every coordinator sending > EBs > > > in the network should use the same key to provide data integrity for > > > EBs. If EBs are not used at all after the initial bootstrap phase > > > (which some people seem to say will happen), then this K1 protection > > > does not provide anything. > > > > Agreed... which is why Kris argues for using it for something else. > > > > > On the other hand on some networks I can see some real uses for EBs > > > also after the initial bootstrap, but those uses will require the > EBs > > > to integrity protected for those devices who are already part of > > > network. > > > > Good... I'd like to hear more. > > > > -- > > ] Never tell me the odds! | ipv6 mesh > networks [ > > ] Michael Richardson, Sandelman Software Works | network > architect [ > > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > > > > > > > > -- > > Michael Richardson <[email protected]>, Sandelman Software Works -= > > IPv6 IoT consulting =- > > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
