Re: [6tisch] xxx-bootstrap

peter van der Stok <stokcons@xs4all.nl> Fri, 16 December 2016 08:17 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145C3129AC5 for <6tisch@ietfa.amsl.com>; Fri, 16 Dec 2016 00:17:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFlcYLHMm008 for <6tisch@ietfa.amsl.com>; Fri, 16 Dec 2016 00:17:15 -0800 (PST)
Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9310E129ACD for <6tisch@ietf.org>; Fri, 16 Dec 2016 00:17:06 -0800 (PST)
Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud3.xs4all.net with ESMTP id LYH41u00H4K0fSy01YH4EK; Fri, 16 Dec 2016 09:17:04 +0100
Received: from 2001:983:a264:1:7800:e1c4:c8d2:128a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 16 Dec 2016 09:17:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Fri, 16 Dec 2016 09:17:04 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Mališa Vučinić <malisa.vucinic@inria.fr>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <39F675F6-0E5B-43C3-82CB-3E2133323771@inria.fr>
References: <efb18853e63642bc4a996dc419cd1efb@xs4all.nl> <AF430AD1-FBB1-494A-ABD4-F0D18599153F@inria.fr> <bfd6b70cb59064eed785f18d26542b57@xs4all.nl> <5EAA50B8-CD29-4BBA-BFA7-0DD9A3D69E49@inria.fr> <8df4e893bf21e28a150653712ff1f749@xs4all.nl> <39F675F6-0E5B-43C3-82CB-3E2133323771@inria.fr>
Message-ID: <6ec721423fcb9eedec9546db6f43ddb5@xs4all.nl>
X-Sender: stokcons@xs4all.nl (ozj11XcezhUmkaaWEbBerVFteSj3YXvn)
User-Agent: XS4ALL Webmail
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/QS-0nPWIQTZvoHWnxw97HLEzz84>
Cc: 6tisch <6tisch@ietf.org>, sandeep kumar <sandeep.kumar@philips.com>, consultancy@vanderstok.org
Subject: Re: [6tisch] xxx-bootstrap
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2016 08:17:17 -0000

Hi Malisa,

Just one point to understand the temporary secure link between JN and 
JA.

>> Consequently, that means during the whole bootstrap process the link 
>> between JA and JN is not secured by layer2 keys.
> 
> This is still under discussion within the design team, but the
> conclusion is the same — we can’t provide any L2 security at that
> point because L2 keys are simply not known. One option is to use
> well-known K1 to provisionally protect the join packets at L2 but this
> of course does not provide any security other than helping to
> bootstrap L2. Another option is for JA to simply accept unsecured
> packets at L2, and make it an exception for join traffic, potentially
> only during the duration of the join process.
> 
I like to state the objectives of the "temporary secure link" (TSL) 
between JA and JN as I see them.
Sorry for stating the obvious.

The security objectives for the TSL are:
(1) When the JN is correct, malicious nodes cannot decode the key 
exchange between JN and JCA or replay them.
(2) When the JN is malicious,
(2.1) the TSL keys cannot be used to decode the key exchange over other 
TSL's or replay them.
(2.2) the TSL MUST be restricted to a set of messages to prevent the 
malicious node from misusing the network.

Protocol choices are:
The selection and generation of TSL keys.
The selection and enforcement of message sets.

Do you agree? Is there more?
I repeat these objectives because especially objective 2.2 seems to be 
silently understood or ignored; although you seem to mention them in the 
text above.

Selecting messages on destination address in JA, may allow setting up a 
path between JN and JCA where JN uses a global address, provided by JA.
That will simplify the replacement of EST over CoAPs by your EDHOC, 
OSCOAP protocol and vice versa.

As expressed earlier, I like to define separate protocol parts which can 
be changed during technology evolution.
Is that a design consideration you want to take into account?

Peter