Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

From: [email-masked]
Date: Thu, 15 Jun 2017 01:55:45 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e of the IETF.

        Title           : Minimal Security Framework for 6TiSCH
        Authors         : Malisa Vucinic
                          Jonathan Simon
                          Kris Pister
                          Michael Richardson
	Filename        : draft-ietf-6tisch-minimal-security-03.txt
	Pages           : 24
	Date            : 2017-06-15

Abstract:
   This document describes the minimal mechanisms required to support
   secure enrollment of a pledge, a device being added to an IPv6 over
   the TSCH mode of IEEE 802.15.4e (6TiSCH) network.  It assumes that
   the pledge has been provisioned with a credential that is relevant to
   the deployment - the "one-touch" scenario.  The goal of this
   configuration is to set link-layer keys, and to establish a secure
   end-to-end session between each pledge and the join registrar who may
   use that to further configure the pledge.  Additional security
   behaviors and mechanisms may be added on top of this minimal
   framework.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-03
https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 15 Jun 2017 11:05:40 +0200

All,

We have just submitted a new version of the minimal-security draft in preparation for the plugtest that will be held in Prague. This version (-03) will be referenced by the official test description of the plugtest.

The most notable changes are:
- pledge-initiated EDHOC handshake with optional separate response
- JRC’s IPv6 address is now included in the Join Response structure
- Separate section specifying MTI algorithms

Regards,
Mališa

> On 15 Jun 2017, at 10:55, [email-masked] wrote:
> 
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: peter van der Stok <[email-masked]>
Date: Mon, 19 Jun 2017 14:52:17 +0200

Hi Malisa,

I have a question about the join protocol described in sections 5-6.
The pledge sends a EDHOC message_1 to JRC via a stateless proxy.
It is not clear to me what happens when more than 1 proxy forwards the 
message to the JRC.

Peter

Mališa Vučinić schreef op 2017-06-15 11:05:
> All,
> 
> We have just submitted a new version of the minimal-security draft in
> preparation for the plugtest that will be held in Prague. This version
> (-03) will be referenced by the official test description of the
> plugtest.
>

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 19 Jun 2017 15:12:35 +0200

Hi Peter,

I’m missing context on how would that happen. The pledge selects *one* JP based on the Join Metric in the received EBs. It fills the destination IPv6 address in the packet with JP’s link-local address and sends it. How would multiple proxies forward the message in that case?

Mališa

> On 19 Jun 2017, at 14:52, peter van der Stok <[email-masked]> wrote:
> 
> Hi Malisa,
> 
> It is not clear to me what happens when more than 1 proxy forwards the message to the JRC.
> 
> Peter
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 19 Jun 2017 15:46:43 +0200

The discovery section had disappeared.
I see now that discovery and selection is done during ND.

That removes my worry,

peter

Mališa Vučinić schreef op 2017-06-19 15:12:
> Hi Peter,
> 
> I’m missing context on how would that happen. The pledge selects *one*
> JP based on the Join Metric in the received EBs. It fills the
> destination IPv6 address in the packet with JP’s link-local address
> and sends it. How would multiple proxies forward the message in that
> case?
> 
> Mališa
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Jun 2017 10:16:11 -0400

> It is not clear to me what happens when more than 1 proxy forwards the

Are these messages from the same pledge?
Or messages from different pledges?

The pledge needs to pick a single proxy for a single exchange.

The pledge *MAY* initiate exchanges via multiple proxies, but they should
be different messages.

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

---

From: peter van der Stok <[email-masked]>
Date: Tue, 20 Jun 2017 14:51:17 +0200

Hi Malisa,

A suggestion to make the text clearer.
section 4 exchange number 3.
The pledge sends packets to the layer 2 address of the JP with the layer 
3 address of the JRC.

That makes clearer what goes on. In a first pass of the text, I wondered 
how the routing was done.

Greetings,

Peter

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 20 Jun 2017 15:05:12 +0200

Hi Peter,

The pledge sends packets with layer 2 address of the JP and layer 3 address set to link-local of *JP*. The packet mounts up to the CoAP layer on JP where it is forwarded to JRC.

This way, the pledge does not need to know the layer 3 address of the JRC. Hope that makes sense. I will make this clearer in the text.

Mališa

> On 20 Jun 2017, at 14:51, peter van der Stok <[email-masked]> wrote:
> 
> Hi Malisa,
> 
> The pledge sends packets to the layer 2 address of the JP with the layer 3 address of the JRC.
> 
> That makes clearer what goes on. In a first pass of the text, I wondered how the routing was done.
> 
> Greetings,
> 
> Peter
>