Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment

Mališa Vučinić <malisa.vucinic@inria.fr> Fri, 10 March 2017 10:36 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FAE129431 for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 02:36:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 SQISsJYCQvUD for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 02:36:38 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D7B129871 for <6tisch-security@ietf.org>; Fri, 10 Mar 2017 02:29:01 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.36,140,1486422000"; d="scan'208,217";a="216278885"
Received: from unknown (HELO [128.93.85.17]) ([128.93.85.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2017 11:28:59 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_D92F146C-C71D-4158-95AB-BD7FA7969DFF"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mališa Vučinić <malisa.vucinic@inria.fr>
In-Reply-To: <14442.1489106136@obiwan.sandelman.ca>
Date: Fri, 10 Mar 2017 11:28:59 +0100
Message-Id: <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr>
References: <D4E34D31.783F2%goran.selander@ericsson.com> <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca>
To: 6tisch-security@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch-security/x5sytNv6DycW5xpR_6sOzwTpJCQ>
Cc: Göran Selander <goran.selander@ericsson.com>, Shahid Raza <shahid@sics.se>
Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2017 10:36:39 -0000

Hi Michael,

Note that the bitbucket version of minimal-security now implements your idea of JRC-initiated security handshake in case asymmetric keys are used. The discovery of the pledge is triggered by a “Discovery Message” that maps to CoAP and is sent from the pledge to the JRC. Upon reception of the Discovery Message, JRC can respond with an optional ack and some time later with a prolonged response that initiates the EDHOC handshake. It can also immediately respond with the initiated EDHOC handshake. I think this is a fine compromise between all the subtle versions that have been discussed so far. Let me know what do you think.

In case of PSKs, everything stays the same and we have a single join request/join response exchange.

Mališa

> On 10 Mar 2017, at 01:35, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> In draft-ietf-6tisch-dtsecurity-secure-join-00, I had suggested that the
> security protocol be initiated from the JRC. The JRC would become aware of
> the pledge through a combination of the pledge doing a DAD process, and
> the Join Proxy running a query to the JRC.  In -00 that query was
> implemented in GRASP, but that could be replaced with some other
> query/response protocol, built upon CoAP if desired.  This was described
> in
>    https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join-00#section-2.2.4 <https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join-00#section-2.2.4>
> 
> This was removed in -01: in -01 the "notification" of the JRC of the new
> pledge is when the pledge performs the EDHOC process which is common to
> zero-touch and one-touch.
> 
> But, EALS suggests something slightly different again.
> 
> Figure 5, reproduced below from:
>       https://ericssonresearch.github.io/EALS/#rfc.section.3.2 <https://ericssonresearch.github.io/EALS/#rfc.section.3.2>
> 
> EALS                                     EALS
> client                                   server
> 
>  |                                        |
>  |      MESSAGE TO BE DETERMINED          |
>  +--------------------------------------->|
>  |                                        |
>  |             EDHOC message_1            |
>  |<---------------------------------------+
>  |                                        |
>  |            EDHOC message_2             |
>  +--------------------------------------->|    Third party
>  |                                        | < - - - - - - - - >
>  |  EDHOC message_3 (EXT_3 = Authz info)  |    authorization
>  |<---------------------------------------+
>  |                                        |
>