Re: [6tisch-security] [Ace] EST over CoAP in ACE wg

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 07 December 2016 19:37 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 E6A03129AA2; Wed, 7 Dec 2016 11:37:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 PqmbnRRalV-h; Wed, 7 Dec 2016 11:37:46 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCBB129584; Wed, 7 Dec 2016 11:37:35 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 08B19203AE; Wed, 7 Dec 2016 14:55:02 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 71E6A63768; Wed, 7 Dec 2016 14:37:34 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "ace\@ietf.org" <ace@ietf.org>, 6tisch@ietf.org, 6tisch-security@ietf.org, anima-bootstrap@ietf.org
In-Reply-To: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com>
References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 07 Dec 2016 14:37:34 -0500
Message-ID: <14831.1481139454@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch-security/O7GYC_-9UAjQ6y2mgKFie_KWb54>
Subject: Re: [6tisch-security] [Ace] EST over CoAP in ACE wg
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: ace@ietf.org
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: Wed, 07 Dec 2016 19:37:49 -0000

I have read:
    draft-pritikin-coap-bootstrap
and draft-vanderstock-core-coap-est

and over in the 6tisch security design team we have been trying to adapt
the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tisch
environment as a zero-touch enrollment process.
(Yes, I am an author involved in both WGs)

Peter (one of the authors of draft-vanderstock-core-coap-est) and
Max (author of draft-pritikin-coap-bootstrap) are involved.

Both documents have good content, and we could combine them easily and wind
up with a relatively straight forward description of how to run EST over
COAPS.
But I don't think that this really solves the problems that we have.

However, the movement in
         draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch)
and   draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, zero-touch)
[both of which are being considered for adoption]

is to move away from DTLS and towards OSCOAP and EDHOC.

As such, what we would really like is an EST-like mechanism which runs
over OSCOAP with EDHOC keying.  Ideally, it would also permit the process
to be managed/initiated from the new device (the pledge), or from the JCE
(Registrar, which might also be the AS in ACE terminology).

We want to initiate from the JCE so that we can:
  a) simplify the constrained device.
  b) manage the order and priority of join activities to avoid
     network congestion in constrained (mesh) networks.

On the other hand, some want a really simple system that can be used with
PSKs as authentication, with the new nodes initiating.

I wrote this email last week to explain some of what I have in mind.
  https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html

I don't know if the EST work fits into ACE's charter, but given that ACE is
where OSCOAP and EDHOC seem to be, I'm happy to work on a document here.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-