Michael Richardson writes:
>     > * Do RFCs 9030/9031 allow that a device uses an explicit frame counter,
>     > which it increments in its own pace?
> 
> They don't say anything about it, I think.
> It's an IEEE/802.15.4 issue.
> 
> 6tisch specifies TSCH mode, which includes the ASN. (To be clear:
> Christian is trying to come up with something non-TSCH that can be
> used for plain 802.15.4, but which does not use 802.15.9 to do
> per-pair keying)

If you are using in TSCH then there is implicit 40-bit ASN that is
used as frame counter and there is no way of transmitting explict
frame counter.

If you are using non-TSCH mode, the 32-bit frame counter is always
included in the frame, and it must be increment for every single
frame. If you using 802.15.4 revision before 2015, then the frame
counter is global to the device, and IS NOT RESET when key is changed.
It will get incremented every time you send a packet, and when it
reaches 0xfffffffe you can't sent any frames ever again (== meaning
device should be replaced with new one).

This was fixed in IEEE Std 802.15.4-2015 by adding
secFrameCounterPerKey to secKeyDescriptor which tells that frame
counter is per key, thus when key is reset you also reset the outgoing
frame counter, and the outgoing frame counter is separate for each
key.

For incoming frames you are supposed to keep frame counter for every
single device you have ever received frames from, to detect replays.
If you are using the secFrameCounterPerKey then when you remove the
key, the incoming frame counter is removed at the same time. 

If you are using TSCH then you can use short addresses in the nonce,
but if you are not using TSCH then the nonce is always generated using
the extended address of the recipient, i.e., you use the extended
address to generate nonce, even when the actual frame might use short
addresses. See 9.3.3.1 AEAD nonce for non-TSCH mode of IEEE Std
802.15.4-2020.

The RFC9030 only applies to TSCH mode, and the restriction there is to
be more strict than in the IEEE Std 802.15.4-2020 which says:

9.3.3.2 AEAD nonce for TSCH mode
...
NOTE—When using short addresses in the nonce, it is important that the
coordinator assign unique short addresses.
...

One of the reasons for this is that when you are rejoining the
network, and have lost your information what is the current ASN, but
you still have the old keying material, you listen to beacons, and get
ASN from there, and then start rejoining process. Now if the beacon
was replay of old beacon and you use short address that was already
given to someone else during your time of absence, you might get nonce
collision, and in that case the attacker can take your message and the
old message from other device using same short address, and can xor
them together to remove encryption.

This does not work if the same short address is not given to multiple
device, i.e., nobody else than you cannot use the same short address
with the key you have. This of course assumes that you yourself
remember the last ASN you have seen before going to sleep, and will
not trust ASN that is earlier than that.
-- 
[email protected]

_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to