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

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Jul 2015 17:36:17 -0400

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 =-

---

From: Qin Wang <[email-masked]>
Date: Tue, 14 Jul 2015 14:05:47 +0000 (UTC)

Hi Michael,
Since a new version of the interface draft with YANG model has been published last week, I think we can bring it to the group ML now. I will start a new thread about the topic on 6tisch ML. Could you please send your comments to that thread?
Many thanksQin  

     On Tuesday, July 14, 2015 5:36 AM, Michael Richardson <[email-masked]> wrote:

Qin Wang <[email-masked]> wrote:
    > Thank you very much for your comments. Can I bring the discussion thread to
    > 6tisch ML?

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.

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*

    > leaf-list PSK {
    > type uint8;
    > min-elements 128;
    > description "A list of bytes for the PSK while using PSK method";
    > }

---

From: Michel Veillette <[email-masked]>
Date: Tue, 14 Jul 2015 15:45:49 +0000

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.

    > 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

    > Thank you very much for your comments. Can I bring the discussion thread to

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.

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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-