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
