Subject: [6tisch] Link_Layer_Key

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Jul 2018 21:15:43 +0300

I think the Link_Layer_Key can very easily changed to send any kind of
keys that are supported by 802.15.4.

If it is updated as follows:

   Link_Layer_Key = (
       key_index          : uint,
     ? key_usage          : uint / nint,
       key_value          : bstr,
     ? key_source	  : bstr,
   )

Then it can include all KeyIdModes of 802.15.4.

For KeyIdMode 0 (pairwise keys), the key_index is set to 0, and
key_source is omitted. The key_index 0 is invalid for other modes, and
KeyIdMode 0 do not have key_index, so this will allow us to transmit
pairwise keys between the peers (the addresses needs to be taken from
the MAC header).

For KeyIdMode 1 (key index only), the key_index is set, and key_source
is omitted. This is what is defined now.

For KeyIdMode 2 (key index + pan id and short address of key owner),
the key_index is set and key_source is set to contain 4 octets,
containing 2 octet pan id, and 2 octet short address.

For KeyIdMode 3 (key index + extended address of key owner), the
key_index is set, and key_source is set to contain 8 octets of
extended address of the key owner.
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 18 Jul 2018 20:41:54 +0200

Malisa,
Can you please comment?
Thomas

On Wed, Jul 18, 2018 at 8:16 PM Tero Kivinen <[email-masked]> wrote:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
________________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Analog Devices
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
________________________________________

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 18 Jul 2018 21:07:30 +0200

Tero,

Thanks Tero for the proposal. Is the current "key_usage" registry enough to
fully configure the security tables for the non-index modes?

When a pledge/node receives a Link_Layer_Key corresponding to KeyIdMode 2,
how does it know which other node to use it for? i.e. I want to encrypt
data towards node B with K3 and data towards node C with K4.

Mališa

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2018 01:47:42 +0300

> fully configure the security tables for the non-index modes?

I guess so. I mean in most cases the KeyIdModes 1-3 are similar, i.e.,
multicast/broadcast keys which are owned by somebody. In the KeyIdMode
1 the owner is implicit (usually coordinator or similar well known
node on the network), in case of KeyIdModes 2 and 3 it is explicit. So
any of those modes can be used with any ke
y usage.

For pairwise (KeyIdeMode 0) things are bit different, for example
sending beacons using pairwise keys is not really useful. So for
pairwise keys key usages like 6TiSCH-K2-* are something that are
usuful. 

> When a pledge/node receives a Link_Layer_Key corresponding to
> KeyIdMode 2, how does it know which other node to use it for? i.e. I
> want to encrypt data towards node B with K3 and data towards node C
> with K4.

In here the KeyIdMode 2 could be used as replaced of KeyIdMode 1 for
any key usage values. I.e., you have multiple JRCs in the network and
you want to make sure each of them can generate broadcast keys, you
could use KeyIdMode 2 instead of 1, and use the PanID + Short address
of the JRC to indicate which of JRC created the key.

Of course the JRCs would still need to distribute those keys to
everybody, and share them between each other also, but they could
create them independently, i.e., they would not need to coordinate
which key index is going to be used.

This would add 4 octets to each frame, so KeyIdMode 1 is better, but
some environments this could be useful.

To negotiate K3, or K4 or similars, would most likely require more
complicated protocol than what is here, i.e., that would need to
include for example the multicast group address for which this key is
used etc. That protocol could then still share this exactly same
Link_Layer_Key structure to transport keys (and it could use new key
usage value like 6TiSCH-GRP-ENC-MIC-128 or similar to indicate this is
key for multicast traffic for DATA and ACKNOWLEDGEMENT frames).
-- 
[email-masked]

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 20 Jul 2018 15:46:22 +0200

Thanks for the clarification. I still have a couple of misunderstandings,
see inline.

Mališa

> any of those modes can be used with any ke

Ok, I understand this better now, thanks!

> pairwise keys key usages like 6TiSCH-K2-* are something that are

I see what you mean. Essentially, key usage will in this case signal to the
node that it should use this pairwise key to send DATA and ACKs.

But my question is related to the signaling of the destination peer.

You say:

I don't understand the part where "addresses need to be taken from the MAC
header". Node A has neighbors B, C, D, and it receives a pairwise
Link_Layer_Key from the JRC. It needs to know to what node it will use that
key to transmit to: B, C, or D. The JRC should in this case, I suppose,
send 3 different keys, each with a different "destination". I am missing
this destination part.

Similar when node A receives a frame, if it comes from B, it decrypts it
with the corresponding key that the JRC indicated for node B. Is my
understanding correct? If no, discard the text below :-)

If so, we would just need to use "key_source" in this case as well, renamed
perhaps, to carry the address of the destination peer.

All the other modes that you proposed seem still to work.

The proposed change for KeyIdMode 0 is : "key_index" is set to 0,  "key_source"
is present. Can you confirm this works?

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 Jul 2018 17:54:57 +0300

Mališa Vučinić writes:
> I see what you mean. Essentially, key usage will in this case signal
> to the node that it should use this pairwise key to send DATA and
> ACKs.

Yes.

> I don't understand the part where "addresses need to be taken from
> the MAC header". Node A has neighbors B, C, D, and it receives a
> pairwise Link_Layer_Key from the JRC.

It might not want to receive it from JRC. Pairwise keys are just that,
they are meant to be between pair of nodes, and not shared with
anybody else. I.e., they would NOT be sent by JRC, but instead the
node A and B runs some unspecified protocol between them and the end
result of that would be the pairwise key. If this unspecified protocol
is sharing code with initial joining processing, it could use same
Link_Layer_Key structure to send that key. In that case the outer MAC
header of the packets doing this exchange already have the needed
addresses.

Another option is that JRC is used as trusted 3rd party to create the
key, as it does share crypto context with both peers. Then again you
need another unspecified protocol where node A would send message to
JRC asking it to create pairwise key between A and B, and JRC would
then reply with packet which has for example two parts, one meant for
node A, which contains the Link_Layer_Key structure encrypted with key
node A knows, and another one that is opaque blob for A, that is
encrypted with key known by B, and node A, would simply forward that
blob to B, and B can then decrypt it and get the Link_Layer_Key
structure out from there. In this case the addresses of A and B would
need to be somewhere outside, i.e., in message going to JRC.

Third option is that node A sends request to JRC to create keys
between A and B and then JRC creates two key update messages one
encrypted with key known by A and send that to A, and another
encrypted with key known by B, and sends that to B. Both of those
messages needs to contain the pairwise keys addresses (i.e., the fact
that this key is for between A and B).

> It needs to know to what node it will use that key to transmit to:
> B, C, or D. The JRC should in this case, I suppose, send 3 different
> keys, each with a different "destination". I am missing this
> destination part.

Yes, 3 keys for A, and of course also the one keys transmitted to B,
C, and D (where the destination address would be A).

> 
> Similar when node A receives a frame, if it comes from B, it
> decrypts it with the corresponding key that the JRC indicated for
> node B. Is my understanding correct? If no, discard the text below
> :-)

Yes.

> If so, we would just need to use "key_source" in this case as well,
> renamed perhaps, to carry the address of the destination peer.

We could.

Anyways this information needs to be already in request where the node
A asking JRC creating keys between A and B. If this information is
there in the wrapper, we could reuse that for other direction too.

I.e., now we are talking about the COnfiguration object, but in this
key negotation protocol we could have PairWise_Keys object:

PairWise_Keys = {
  [ +Link_Layer_Key ],
  address bstr		; length will tell whether this is pan + short
  	  		; or extendedaddress
}

In message from A to JRC the Link_Layer_Key can be empty, or it could
include the key A created, and wants JRC to re-encrypt and transmit to
B, and the address contains the of B. The JRC will then create same
structure, replace address part A and send to B (if A sent key), or
create two similar structures, one for A and one for B, each having
same key, but different addresses.

> The proposed change for KeyIdMode 0 is : "key_index" is set to
> 0,  "key_source" is present. Can you confirm this works?

Hmm... true, the key_index cannot be zero for KeyIdMode 2 and 3, so
only case where key_index can be zero is with KeyIdMode 0...

So in that case we do NOT need to address outside, so you can ignore
what I wrote above :-)
-- 
[email-masked]