2015-04-13 15:28 GMT-03:00 Kris Pister <[email protected]>: > > Isn't there also a NONCE in the L2 MIC? > Yes. That's the nonce that I've been writing about. > > > well, I don't think this is something we can assume for 6tisch, so we > have > > this very real problem in 6tisch. > Hmm. I guess this is where having a concrete plan laid out for security > would > be helpful. I've just been talking about L2 MIC nonce, and that anything > beyond > that was a separate discussion. > > For example, I have a network of dozens or hundreds of fixed nodes in a > campus. > I have hundreds or thousands of mobile nodes wandering through. Using > Minimal, it's very convenient (and secure) for a mobile node with a unique > 2B > short address to form and expect nonces using short addresses. As it > wanders, > it doesn't need to know or provide extended addresses. Mobile nodes may > not > have much memory, and not want to keep a large table of DeviceDesciptors. > Fixed devices sending enhanced beacons might not want to add their > extended address to every packet. > > Fixed devices may have a much fancier schedule than the mobile devices > which may > just use minimal. Fixed devices may use OTF to schedule additional > bandwidth. > OTF commands probably want to be encrypted, and a nonce will be involved. > Even here a unique 2B short address is not security risk. >
I have a couple of questions regarding OTF security: Since 6top manages 6top-6top communication between nodes to enable OTF to negotiate bandwidth requests, I think there is no need to encrypt OTF commands themselves (since OTF communicates directly with 6top on the same node). I think that any message that uses the 6top-6top communication capability should be encrypted by 6top, including OTF. Do we need to authenticate all the internal 6tisch modules apart from the node itself? > If there is a risk of > non-uniqueness in the short address and duplicate keys on devices with the > same short address, then this is indeed a security hole. My advice would > be > that we design the 6tisch OTF security protocol so that > (shared short address) && (same OTF key) == 0 > I believe that any rationally designed security protocol will enforce that. > Maybe the solution in this case is that > (short address) = 0 > which is fine by me for 6tisch OTF security. I just don't like it for L2 > MIC > security because it's an unnecessary constraint that requires either more > bytes > of payload or more packets exchanged. In some cases this is not a big deal > as Tero has pointed out. In other cases, it's a pain. > > ksjp > > > On 4/13/2015 10:59 AM, Michael Richardson wrote: > > Kris Pister <[email protected]> <[email protected]> wrote: > >> Wrong. It leaks the whole content of both packets. > > > Tero - it's the L2 MIC that we're talking about. The packets aren't > > encrypted at L2. > > Isn't there also a NONCE in the L2 MIC? > > > The entire contents of both packets is transmitted in the clear, by > design. > > End-to-end transport payloads SHOULD be encrypted (in my opinion), > > but that's a different topic. > > well, I don't think this is something we can assume for 6tisch, so we have > this very real problem in 6tisch. > > -- > Michael Richardson <[email protected]> <[email protected]>, Sandelman > Software Works > -= IPv6 IoT consulting =- > > > > > > > _______________________________________________ > 6tisch mailing [email protected]https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- DIEGO DUJOVNE Académico Escuela de Ingeniería en Informática y Telecomunicaciones Facultad de Ingeniería UDP www.ingenieria.udp.cl (56 2) 676 8125
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
