Kris Pister writes:
> If I generate a secure random 128 bit number to use as K1, and I
> program that number into five motes sitting on my desktop, there is
> no standard-compliant way that those motes can use K1 to protect MAC
> frames without using a 9-octet key identifier?
For that you can use KeyIdMode 0b01 with one octet KeySource
consisting the KeyIndex you distributed along the K1.
I.e. you say that there is group key using KeyIdMode 0b01 identified
with KeyIndex xx having key K1 during the bootstrap, and then you can
use that key to protect joining.
> I'm pretty sure that there *is* a way. I'm pretty sure that I can
> set Key Identifier Mode to 00, and have 0 additional bytes in the
> security header, and determine the key implicitly ("use K1!"), as
> described in 7.4.1.2 of 802.15.4-2011 .
No. The KeyIdMode 0b00 is not meant for group keys. It is meant to be
used for pairwise keys between peers. I.e. where the keys can be known
because the source and destination addresses of the peers are known.
To be able to use it you need to already know the macPanId and the
macCoordExtendedAddress. Before you join the network you do not know
those, so you cannot really fill in the information.
The bigger problem is that there is only one such key between pairs,
i.e. there is no way to have K1 and K2 both using KeyIdMode 0b00.
> Perhaps Tero can tell us if this is still true in -2015.
This is still mostly unchanged in 2015. We did change it a bit, mostly
because 802.15.4e added ability to have PAN ID Compression modes where
we do not have any PAN ID in the mac header, even when we are not
using DeviceAddressingMode of NONE, and the KeyDescriptor lookup
procedure assumed that we always have device PAN ID.
We also cleaned up the macDefaultKeySource from the KeyIdMode 0b01. It
was comparing PIB constant with non-existing field in the mac header
i.e. there is no point of comparining the PIB macDefaultKeySource
value to the KeySource field of the mac header, as the KeySource field
is empty when using KeyIdMode 0b01.
Anyways, for minimal I think we could use KeyIdMode 0b01, but that
requires us to use some kind of bootstrap case where we distribute
which KeyIndex is used for K1 and K2. Note, that KeyIndex changes
every time you rekey the group keys in the network.
If you want uniquely identify the well-known keys, then you really
need to use KeyIdMode 0b11 with well-known extended-address and
KeyIndex associated to K1 as Rene described.
Of course this 9-octet KeySource field provides a way to identify
proper network to join in much cleaner way than checking MIC with
well-known keys... I.e. if the EB has proper KeySource identifying our
well known extended address of our network this will cleanly separate
multiple different networks from each other.
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
