Malisa Vucinic writes:
Lets assume you could run this process inside the MAC, and check the
rest of the stuff here.
Right, so in the worst case the join-specific routine can be invoked
after we have discarded one EB and for the subsequent one everything
should be in place. Otherwise, one will have an upper-layer callback
within MAC, as this part of the spec is usually implemented in
software i.e. firmware, that invokes the join-specific routine and
prepares everything for the first received EB. Would that be non
standard compliant? :)
Such implementation might not be against standard, but to get some
existing implementation to do that, might be really hard.
Of course if your implementation does everything on software, then you
can do that, but if you have hardware doing the security processing
for frames, it might be really hard to be able to hook into that.
Now you of course have the problem how to identify the K2 key for the
network... You cannot use KeyIdMode 0b00, as you can only have one of
them.
Well, consider that beacons can also be sent with short Destination
Addressing Mode and 0xffff Destination Address field.
We are talking about source addresses here, not destination. Source
address should not be broadcast...
And KeyIdMode 0b00 cannot be used with broadcast addresses for
non-beacon frames. See the note at the end of KeyDescriptor lookup
procedure which says:
NOTE—For broadcast frames, the KeyDescriptor lookup procedure
will result in Status set to FAILED if implicit key
identification is used. Hence, explicit key identification
should be used for broadcast frames.
Given that KeyDescriptor Lookup in case of KeyIdMode 0b00 (implicit)
differentiates among different keys based on device address, PAN and
addressing mode, you could use the short broadcast address (0xffff)
to instantiate the KeyDescriptor, no?
The keys are identified by the source address. Destination address
does not matter when finding the key (of course it will matter who
will actually do the incoming frame security procedure, i.e. which
device receives the frame).
It is possible in the sending end to have multiple KeyIdMode 0b00 keys
for different addresses. but for receiving end will just use the
source address of the frame to find the key. So if the device A has
KeyIdMode 0b00 key for coordinator B the device A will find the same
key always for same address.
Each EB would be secured using the KeyDescriptor that corresponds to
the 0xffff address. The question then is if there is a way to
differentiate between DATA broadcast frames and beacons for K1
during the outgoing security procedure. Since the incoming procedure
checks the key usage policy (7.2.7) I don’t see a problem on the
receiving side.
Key Usage Policy is done after we have found the key. It does not
affect the key lookup. I.e. the incoming frame security policy will
find the key using the KeyDescriptor lookup procedure, and then it
will later check whether that key was ok to be used for those frames.
secKeyDescriptor(K1)
secKeyUsageList = { (secFrameType = beacon) }
secKey = <K2 key>
I believe you mean <K1 key>.
Yes.
Now, if the ASN is right, it will be able to authenticate the next EB
that comes in (or if it has ability to push old received EB back to
mac for security check after filling in the tables).
The K2 would use same KeyIdMode 0b01 but with different KeyIndex.
KeyIdMode 0b01 for both K1 and K2 is more flexible but I am not sure
if this is necessary for minimal.
I think it is mandatory if you want to use two different keys.
Otherwise, we can consider using K1 with KeyIdMode 0b01 (one extra
byte for Key Index) and K2 with KeyIdMode 0b00 (implicit, no extra
bytes).
That is fine as long as K2 key is never used with broadcast keys...
KeyIdMode is not supposed be used with broadcast keys (or actually any
group keys).
Also this makes it impossible for K2 to be rekeyed. With KeyIdMode
0b01 you can rekey by installing new key with new index, and
distribute the new key to all devices. When that is done, you can
switch the network to use new key, and then remove the old key.
With KeyIdMode 0b00 this is not possible, as there you need to do this
atomically for the whole network.
The bad thing here is that devices would try to do this for all
possible networks using KeyIdMode 0b01 and same KeyIndex, thus
this will not provide full network separation…
Device will try to authenticate the EB (whichever EB the
implementation-specifics allow it to authenticate) with K1 it has
preinstalled. Wrong network and this will fail, no?
Yes, but people were concerned that we try to connect to wrong
networks, and if you need to wait for EB, install keys etc, wait for
next EB, and then notice that the network is wrong, this is quite slow
process...
Having random KeyIndex for minimal would provide additional filter
when selecting network, but it is weaker than what can be done with
well-known extended address in KeySource or vendor specific IE
containing network id in EB...
