Re: [Anima-bootstrap] [6tisch-security] goals for this 6tisch design team -- zero-touch vs one-touch

Randy Turner <> Wed, 08 June 2016 07:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 727FD12D812 for <>; Wed, 8 Jun 2016 00:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2oDmWRAmagya for <>; Wed, 8 Jun 2016 00:00:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D75F12D11E for <>; Wed, 8 Jun 2016 00:00:10 -0700 (PDT)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id u5870840059240 for <>; Wed, 8 Jun 2016 03:00:08 -0400
Received: (qmail 17564 invoked by uid 0); 8 Jun 2016 07:00:08 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 8 Jun 2016 07:00:07 -0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_7D22AC77-2AA9-4AB8-ADF6-670C1768A99A"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Randy Turner <>
In-Reply-To: <>
Date: Wed, 8 Jun 2016 02:59:58 -0400
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [Anima-bootstrap] [6tisch-security] goals for this 6tisch design team -- zero-touch vs one-touch
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jun 2016 07:00:12 -0000

The only ANIMA document I can find with “bootstrap” in the title specifically precludes its’ application in constrained environments…

The entire solution described in this document is aimed in general at
   non-constrained (i.e. class 2+) devices operating on a non-Challenged
   network.  The entire solution described here is not intended to be
   useable as-is by constrained devices operating on challenged networks
   (such as 802.15.4 LLNs).

So I’m assuming we can “borrow” ideas from ANIMA but reuse it …


> On Jun 7, 2016, at 9:16 PM, Michael Richardson <> wrote:
> There has been a fair bit of discussion, much if it 1:1 offlist about what
> the goals of this design team is.
> Our charter says:
>    ...
>    The WG will continue working on securing the join process and making
>    that fit within the constraints of high latency, low throughput and
>    small frame sizes that characterize IEEE802.15.4 TSCH.
>    ...
>    - Produce a specification for a secure 6TiSCH network bootstrap, adapted
>    to the constraints of 6TiSCH nodes and leveraging existing art when
>    possible.
> Zero-touch vs one-touch is not mentioned.
> In
> Based upon conversation that lead to the 2014 era work, I had written:
>   A challenging part with constructing an LLN with nodes from multiple
>   vendors is providing enough security context to each node such that
>   the network communication can form and remain secure.  Most LLNs are
>   small and have no operator interfaces at all, and even if they have
>   debug interfaces (such as JTAG) with personnel trained to use that,
>   doing any kind of interaction involving electrical connections in a
>   dirty environment such as a factory or refinery is hopeless.
>   It is necessary to have a way to introduce new nodes into a 6tisch
>   network that does not involve any direct manipulation of the nodes
>   themselves.  This act has been called "zero-touch" provisioning, and
>   it does not occur by chance, but requires coordination between the
>   manufacturer of the node, the service operator running the LLN, and
>   the installers actually taking the devices out of the shipping boxes.
> This is in alignment with the ANIMA bootstrap work.
> Recently the desire for a "one-touch" provisioning system has been expressed.
> Rationals include: simpler, less code, less complex, lower energy, etc.
> (My goal is not to dispute any of these points here)
> This is to be constrasted with a zero-touch system where unique PreSharedKeys
> (PSKs) are provisioned during manufacturing and are provided to the end-customer in
> some fashion.
> A one-touch system would involve some kind of special provisioning room:
>    * customer plugs in cable to device and installs a PSK (whether unique
>      per node, or per-network)
>    * customer turns on device in faraday cage, uses well-known PSK to
>      take ownership and install a per-node unique PSK
>    * some other model
> The customer then puts the device back into a box and puts it into inventory
> to be deployed as appropriate.  I'm told that this is exactly the model that
> the electric metering (AMI) people use.  I don't know if the special
> provisioning room/cable is done centrally or on-site, but I do know that the
> meters have standard-ish fiber optic connections for doing this. (Fiber to
> avoid electrical shock: cf: ANSI C12.18)
> It seems that there are an innumerable number of ways that the "touch" for a
> one-touch system could be done, and if there is real desire to accomodate
> such a process, we need to state some assumptions about the touch process.
> As such, a document is surely needed.  Some questions I have:
>   1) is it physical? (vs radio. vs a BNC/etc cable plugged instead of antenna)
>   2) is it encrypted?
>   3) does it run IP?
>   4) how many bits can be transmitted/received?
>   5) is the target CPU alive, or is this JTAG or JTAG-like?
> If we are using (D)TLS, then to me, then a way to do one-touch without any
> asymmetric crypto would be to create a TLS session resumption ticket
> <>. Not via the NewSessionTicket exchange,
> but directly.  The controller (JCE) would actually have knowledge of the
> ticket format (section 4).  The format would not be "Recommended" but rather
> standardized, moving all of the heavy work from the device to the JCE.  The
> device would simply be told the "master key".  Would this work, I don't know
> yet, because I don't know what one-touch setup can do.
> If this is the direction we need to go, great, but someone has to step up to
> write this document.
> The advantage of what I would propose is that a zero-touch and one-touch
> solution would be identical, except for how the TLS session is initiated.
> --
> Michael Richardson <>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> _______________________________________________
> 6tisch-security mailing list