Qin,
Any feedback on Michel's question?
Thanks,
Thomas
On Tue, Jul 14, 2015 at 5:45 PM, Michel Veillette <
[email protected]> 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 protected]
> www.trilliantinc.com
>
>
> -----Original Message-----
> From: 6tisch [mailto:[email protected]] 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 protected]> 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 protected]>, Sandelman Software Works -=
> IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
