Subject: Re: [6tisch] attributes of 6top interface YANG model corresponding to K1 and K2

From: Thomas Watteyne <[email-masked]>
Date: Fri, 25 Sep 2015 12:26:30 +0200

Qin,
Any feedback on Michel's question?
Thanks,
Thomas

On Tue, Jul 14, 2015 at 5:45 PM, Michel Veillette <
[email-masked]> wrote:

> Hi Michael
>
> Why keys are defined using "leaf-list uint8" (RFC 6020 section 7.7)
> instead of "binary" (RFC 6020 section 9.8) ?
> And why min-elements 128? It's not 16 bytes?
>
> leaf-list define an array of nodes all sharing the same data type.
> A binary define a single node.
>
> See below:
>     > leaf-list PSK {
>     > type uint8;
>     > min-elements 128;
>     > description "A list of bytes for the PSK while using PSK method";
>     > }
>
> Should it be replaced by
>     > leaf PSK {
>     > type binary;
>     > length 16;
>     > description "Pre-Shared Key while using PSK method";
>     > }
>
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> [email-masked]
> www.trilliantinc.com
>
>
> -----Original Message-----
> From: 6tisch [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: 13 juillet 2015 17:36
> To: tisch; Qin Wang
> Cc: Thomas Watteyne; Pascal Thubert (pthubert); Xavier Vilajosana
> Subject: Re: [6tisch] attributes of 6top interface YANG model
> corresponding to K1 and K2
>
>
> Qin Wang <[email-masked]> wrote:
>     > Thank you very much for your comments. Can I bring the discussion
> thread to
>     > 6tisch ML?
>
> Yes, you can forward, or I can reply.  I will include my entire email if
> you want...  yeah let me just write.
>
> I was asked privately if I could provide some YANG content for the 6top
> document wrt to the K1/K2 usage specified in MINIMAL.
>
> I wrote:
>     > So, I'm trying to figure out, in the context of *MINIMAL* why there
> would
>     > be a way to set K1 and K2.
>
> I amend to:
>     > By definition, K1 is used to "authenticate" the beacon (MIC only
> mode)
>     > It may be well known, or might be provisioned through
>     > out-of-scope-magic to some value.
>     >
>     > A node that does not know the correct K1 can still get on the network
>     > by observing the beacon, but it won't be able to authenticate it.
>
> I then wrote:
>     > K2 would be used to authenticate and encrypt the rest of the traffic,
>     > including the Informational Elements on which the 6top-layer-2
> commands
>     > would be sent. So setting K2' would require knowing K2.
>
> So knowing K2, one can set K1 and/or K2 (or program
> schedules/timeslots/etc).
> Since K2 is shared across the network, it's a pretty weak group key, and I
> feel squimish about allowing K2 to be replaced knowing only K2.
>
> Further:
>     > And one could set K1/K2 on a device, and then bring the device to a
> new
>     > network. So having this available is useful for doing key management
> once
>     > joined, but I'm not convinced it belongs in *minimal*
>
> But, if we want to have some YANG, the definition we have for 6top
> security is exactly what we need:
>
>     > leaf-list PSK {
>     > type uint8;
>     > min-elements 128;
>     > description "A list of bytes for the PSK while using PSK method";
>     > }
>
> So, maybe rename it to PSK_K1_beacon, and add PSK_K2_production.
>
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>