Kris Pister writes:
Isn't there also a NONCE in the L2 MIC?
Yes. That's the nonce that I've been writing about.
No, we have been talking about the onnce protecting the 802.15.4
security, that covers both the nonce used for L2 encryption and MIC.
The encryption is optional per frame basis, but the same nonce is used
for both in TSCH.
In non-TSCH modes the nonce also includes the security level, thus
nonce will be different if you have encrypt + MIC, or if you have only
MIC.
In TSCH the nonce is same for all security levels.
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.
I have never been talking about the L2 MIC nonce only, I have been
talking about the 802.15.4 nonce in general and that covers both MIC
and encrypt + MIC cases.
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
^^^^^^^
What is that "Minimal"? Are you talking about the
draft-ietf-6tisch-minimal?
Btw, that document do recommend that you keep EUI64 of the neighbor in
the section 6.1 in the neighbor table.
It also has two keys, one for authentication of Enhanced Beacons, and
another for "authenticate and encrypt payload of DATA,
ACKNOWLEDGEMENT, and MAC COMMAND frame types and respective header
IEs".
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.
But it can do end-to-end encryption on the application level? Which
protocol it is using for that?
I mean extended address is 8-bytes, and if you have hunderd fixed
devices in the network, that will be less than kilobyte even if you
store all of the devices. Of course it only needs to store
DeviceDesciptors for only those devices it is actually talking to,
i.e. its neighbors.
Fixed devices sending enhanced beacons might not want to add their
extended address to every packet.
That would be a problem, as unless you know the nonce, you cannot
authenticate the frame. So better would be to use extended address for
the enhanced beacons.
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.
So now you are suddenly again talking about L2 encryption, not only
MIC.
Btw, what is OTF command? It is not defined in the
draft-ietf-6tisch-terminology document.
Ah, most likely on-the-fly? As in draft-dujovne-6tisch-on-the-fly?
Even here a unique 2B short address is not security risk.
Why not? And you never use extended addresses, only short address? Not
even in the joining process?
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.
What guarantees in your system that there will never be duplicate
short addresses?
My advice would be that we design the 6tisch OTF security protocol
so that (shared short address) && (same OTF key) == 0
Hmm.. draft-dujovne-6tisch-on-the-fly do not define any keys, so I
have no idea what that text is supposed to say. Or is that just trying
to say that if you have duplicate short addresses they must have
different keys?
I believe that any rationally designed security protocol will
enforce that.
Ensuring in the meshed environment that there never will be duplicate
short address when devices move around and sleep is not that easy
task. When you have given short address 0x1234 to device, when do you
know when you can reuse that short address?
If we are never going to reuse short addresses, that means we might
run out of them at one point, what do we do at that case?
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.
I do not think we should limit 6tisch so much on this level to say
that we cannot use L2 encryption, and we cannot use extended addresses
in any of the secured frames.
Those two are features which are there in 802.15.4 and there are
applications which would like to use those. For example if your setup
is so that you have tens of thousands of "listen" only devices, which
do not really transmit anything ever. In that case allocating short
addresses for each for them is just wasting resources. Those devices
could be some kind of sensors which initially join the network,
register themselves to some server, and then just wait for someone to
connect and ask their measurements. After the initial join they never
transmit anything unless asked first.
So, they are going to stay there for days without nobody ever
connecting them, just keeping track of EBs and time. When someone
wants to contant them and ask for information, that someone will
simply send a message to them on the TxRxS/EB slot using their
extended address. For them the L2 encryption might be enough for
protection, so they might be so simple that they cannot do any upper
layer security protocols.
If we say you cannot use extended address and L2 encryption in 6tisch
this kind of setups are out of question.
