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 <kivi...@iki.fi> 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.
> --
> kivi...@iki.fi
>
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to