Re: [Ace] [Anima-bootstrap] EST over CoAP in ACE wg

"Panos Kampanakis (pkampana)" <> Fri, 09 December 2016 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 204631293EE; Thu, 8 Dec 2016 22:04:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.418
X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eYOuGX8pPXes; Thu, 8 Dec 2016 22:04:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6932128B38; Thu, 8 Dec 2016 22:04:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4048; q=dns/txt; s=iport; t=1481263463; x=1482473063; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Tk/ObWcHBerR5Y0U6HMtC5vA9NyrCvWbZRnEXovn0dU=; b=ZY7ganrAcPhPWjoyFHMNAEUZAaFXyXLgB0cJHPR9TCxVvroRtnMfgcvc RefdqFsFZB0/ZKklZPXgSTOUHWMcZSn1HRN1vTi71AXP604PlZViBUKv8 hOIMELa8CZFMxFxe+J7AVqxJxmpicSC47gjwTK6MLtypxHUWQAG+HqzAj c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208";a="184901328"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2016 06:04:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uB964MGk012495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Dec 2016 06:04:22 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 00:04:21 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 00:04:22 -0600
From: "Panos Kampanakis (pkampana)" <>
To: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg
Thread-Index: AdJD/4dN3nkys8JpRuSDXvz8bQBVcAM9B64AADuYMdA=
Date: Fri, 09 Dec 2016 06:04:21 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Ace] [Anima-bootstrap] EST over CoAP in ACE wg
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Dec 2016 06:04:26 -0000

Hi Michael,

This are interesting good points.

IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not necessarily need to define one transport mechanism. COAPS (over DTLS) is one obvious option but running over OSCOAP with EDHOC is another. One of the goals of these drafts (would need to be merged) is the binding between COAP messages and BRSKI / EST APIs for all the bootstrapping and cert enrollment transactions defined in the anima-bootstrapping-keyinfra doc and RFC7030. draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est address DTLS as transport mechanism right now, but could be expanded to define more than one transports. If the WG finds that as a better idea, normative language would need to be carefully of course and maybe an MTI option would need to be chosen.

I am curious about your workflow in You are envisioning for the JCE to initiate the bootstrapping to the pledge, but wouldn't that better be defined in the anima-bootstrapping-keyinfra doc?

About 'simple system that can be used with PSKs as authentication', I was curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth with PSK/RPK/Cert? Anything more detail about these usecases?

A nit in " <--- CoAP POST /cert-----     [PKCS7 Certificate] ". That message would require the private key to be included with the cert since the pledge did not generate it by himself. EST defines CMS for this message. PKCS12 could suffice here as well with the challenge if the passphrase provisioning being the problem.


-----Original Message-----
From: Anima-bootstrap [] On Behalf Of Michael Richardson
Sent: Wednesday, December 07, 2016 2:38 PM
Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg

I have read:
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.

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 <>, Sandelman Software Works  -= IPv6 IoT consulting =-