Thanks Tero for this feedback! Could you check if this commit takes care of it:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/dee6cf8074f2 The algorithm identifier is added, it is optional and if it is not present the IEEE802154-AES-CCM-128 algorithm is assumed. Apart from the key length, I also added the nonce length in the description of the algorithm in the registry. Mališa On Tue, May 15, 2018 at 11:47 PM Tero Kivinen <[email protected]> wrote: > Mališa Vučinić writes: > > I also worked out a new key signaling mechanism using a "key usage" > parameter, > > where a single uint value from the registry specifies the IEEE 802.15.4 > > security level to be used and the appropriate frame types the key can be > used > > with. The mechanism is flexible in that it allows us to transport a key > that > > is both K1 and K2, separate K1 and K2, different security levels for > each, and > > we can also define new combinations of security levels/frame types in > future. > > The solution only supports KeyIndex mode of IEEE 802.15.4. Supporting > other > > modes required mimicking 15..4 security structures to configure the > security > > module and would have required maps everywhere and extensive overhead. > If you > > have any better idea how to add support for other keying modes of > 802.15.4, > > let me know. > > Note, that there is work ongoing in the IEEE to add algorithm agility > to the IEEE 802.15.4, i.e., make it possible to use other algorithms > than AES-CCM with 128-bit keys. To make it so that this structure > would also allow that it would be good idea to include algorithm > parameter to the Link-Layer Key structure with only one value of > AES-CCM-128 now. Also restructuring the text about the key_value to > say "key length of the algorithm" instead of fixed 16, i.e., say that > ignore this key if the length of the key_value does not match the > length of the key specified by the algorithm. > > This TG15.4y SECN work is just starting and will most likely be > finished in few years time. The main reason for that work, is to add > AES-CCM-256 option for the IEEE 802.15.4. This will make it possible > for 802.15.4 to conform with requirements that some organizations > have, i.e., allow using 256 bit keys to provide some protection > against quantum computers. > > Makeing this minimal-security draft to only allow AES-CCM-128 and not > even allow easy extensibility for other algorithms would be bad idea > now. > -- > [email protected] >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
