Subject: [6tisch] comment on draft-ietf-6tisch-minimal-06

From: Rene Struik <[email-masked]>
Date: Thu, 26 Mar 2015 12:26:27 -0400

Dear colleagues:

Based on the discussion during this morning's 6TiSCH session, I suggest
replacing the second para of Section 8 as follows:

OLD:
The present document assumes the existence of two keys, which can be
well-known by the network devices and/or pre-configured. One of the keys
(K1) is used to authenticate EBs (all frame). As defined in Section 4
EBs MUST be authenticated but payload not encrypted. This prevents two
independent networks to interfere or enable non-allowed nodes to join a
particular network. A second key (K2) is used to authenticate and
encrypt the payload of DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types
and respective header IEs.

NEW:
The present document assumes the existence of two cryptographic keys,
which can be pre-configured. One of the keys (K1) is used to
authenticate EBs. As defined in Section 4, EBs MUST be authenticated,
with no payload encryption. This facilitates logical segregation of
distinct networks. A second key (K2) is used to authenticate
the payload of DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and
respective header IEs, with potential payload encryption.
Depending on security policy, these keys could be the same (i.e., K1=K2).

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Rene Struik <[email-masked]>
Date: Thu, 26 Mar 2015 14:11:45 -0400

Dear colleagues:

I discovered a small editorial glitch - my apologies. Corrected version 
included below.

Rene
> distinct networks. A second key (K2) is used to authenticate DATA, 
> ACKNOWLEDGEMENT, MAC COMMAND frame types and
> respective header IEs, with payload encryption.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2015 14:39:41 -0400

> Depending on security policy, these keys could be the same (i.e., K1=K2).

I also believe it is important that the minimal document specify the use of
two keys.  This will put a clear requirement on protocol stacks that they
support more than one key, and that they figure out how to do this kind of
thing in their datapath processing.

I agree that we might later on write a document later on that defines K1==K2,
but I don't think that it is useful to include the last sentence.  I don't
know what the "depending" is, and it may confuse implementers into thinking
they can define the situation.

Leaving out the last sentence, I am happy with the text.

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

---

From: Kris Pister <[email-masked]>
Date: Thu, 26 Mar 2015 11:42:59 -0700

I agree.  Once you have the mechanism to have two keys, higher level 
policy can
specify what K1 and K2 are.  Rene - is there a reason to have that last 
line in there?

ksjp

On 3/26/2015 11:39 AM, Michael Richardson wrote:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Rene Struik <[email-masked]>
Date: Thu, 26 Mar 2015 14:53:33 -0400

Hi Kris:

The last sentence "Depending on security policy, these keys could be the same (i.e., K1=K2)" does exactly what you suggest in your email.

This sentence is included to cover potential deployments that use a network-wide key for all frame types (which is a security policy instantiation [which may be allowed or not]).

Rene

On 3/26/2015 2:42 PM, Kris Pister wrote:
> specify what K1 and K2 are.  Rene - is there a reason to have that 
> last line in there?
>
> ksjp
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 26 Mar 2015 19:24:25 +0000

I don't see any harm in the last sentence to clarify there is no
restriction that the keys be different (which could be inferred from
calling them K1 and K2).

Robert

On 26 March 2015 at 18:53, Rene Struik <[email-masked]> wrote:

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

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 26 Mar 2015 19:32:13 +0000

Replacing the word "restriction" with "requirement", I think I agree with Robert...

R.

On Mar 26, 2015, at 2:25 PM, Robert Cragie <[email-masked]<mailto:[email-masked]>> wrote:

I don't see any harm in the last sentence to clarify there is no restriction that the keys be different (which could be inferred from calling them K1 and K2).

Robert

On 26 March 2015 at 18:53, Rene Struik <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kris:

Rene

On 3/26/2015 2:42 PM, Kris Pister wrote:
I agree.  Once you have the mechanism to have two keys, higher level policy can
specify what K1 and K2 are.  Rene - is there a reason to have that last line in there?

ksjp

NEW:

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

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

--
email: [email-masked]<mailto:[email-masked]> | Skype: rstruik
cell: +1 (647) 867-5658<tel:%2B1%20%28647%29%20867-5658> | US: +1 (415) 690-7363<tel:%2B1%20%28415%29%20690-7363>

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

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

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Subir <[email-masked]>
Date: Thu, 26 Mar 2015 14:36:28 -0500

Agreed

Sent from my iPhone

> On Mar 26, 2015, at 2:24 PM, Robert Cragie <[email-masked]> wrote:
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 26 Mar 2015 20:47:43 +0100

Rene, all,

I will wait for consensus on it and then I will update the draft. Thanks
you very much for your comments and advice.

regards,
Xavi

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 26 Mar 2015 20:00:00 +0000

The NEW text looks reasonable to meŠ

It looks like K1 is input to a MAC over the EB

K2 is used for both encrypting data payloads as well as authentication of
DATA, ACKS, and MAC command frames ?

R.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2015 16:34:57 -0400

> restriction that the keys be different (which could be inferred from

As you say, it's a best a meaningless clarification, and at worst it's
harmful to interoperability. It opens the door to someone arguing that they
should be allowed to always set K1=K2.  This might be done by a vendor who
can't handle multiple keys.

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 29 Mar 2015 17:52:07 +0200

Rene,

You suggested edit seems reasonable to me. As Randy's question reveals,
maybe we could state more clearly that:
- both keys are use for link-layer encryption/authentication, per the
IEEE802.15.4 standard
- K1 and K2 do NOT need to be different, i.e. the K1==K2 case is possible
- K1 is used on EB (frame type BEACON), in authentication mode oonly
- K2 is used on the other frames (frame types DATA and ACK), in
authentication+encryption mode.

We are not, at this point, using any COMMAND frame in 6TiSCH, so I don't
have a strong opinion, but adding them to the K2 point below intuitively
makes the most sense.

Thomas

On Thu, Mar 26, 2015 at 9:00 PM, Turner, Randy <[email-masked]>
wrote:

> This e-mail (including any attachments) is confidential and may be legally
> privileged. If you are not an intended recipient or an authorized
> representative of an intended recipient, you are prohibited from using,
> copying or distributing the information in this e-mail or its attachments.
> If you have received this e-mail in error, please notify the sender
> immediately by return e-mail and delete all copies of this message and any
> attachments. Thank you.
>