> 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. 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]> 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]>, 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
