Hi Christian, > On 10 Sep 2022, at 12:30, Christian Amsüss <[email protected]> wrote: > > * Do RFCs 9030/9031 allow that a device uses an explicit frame counter, > which it increments in its own pace?
As mentioned, we’ve made every attempt to make RFC 9031 applicable to non-TSCH use cases, as well. Construction of the link-layer nonce is not mentioned in RFC 9031 and, as Tero notes, the procedure is defined by IEEE 802.15.4. That means that we can use RFC 9031 to distribute the keys with Key Usage set to the values from Table 6. The rekeying procedure also does not depend on the common notion of time that is specific to 6TiSCH/TSCH, so that also applies. > > * If yes, shouldn't there be more stern words in 9031 about allowing a > new key to be used with the same EUI-64 (considering that the device > may not get a short identifier)? As Tero notes, this procedure is defined by IEEE 802.15.4 standard: Once a new key is provisioned to the device, the device resets its frame counter. > > (Plus all concerns about the use of OSCORE Appendix B.2 or its > replacement KUDOS would be relaxed, because if a device can use its > own frame counter, it could use the same facilities to not lose its > OSCORE sender sequence number). I would say that the text on the use of OSCORE Appendix B.2 in RFC 9031 still applies for non-TSCH use cases as 8.3.3. talks about a particular case when the JRC fails and looses the mutable security context parameters. JRC is not part of the mesh and we’ve never considered the JRC hosted at a constrained device. That means that the JRC does not follow 802.15.4 security procedures as it is likely using another Layer 2 technology. Mališa
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
