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

Randy Turner <rturner@amalfisystems.com> Wed, 08 June 2016 07:00 UTC

Return-Path: <rturner@amalfisystems.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727FD12D812 for <anima-bootstrap@ietfa.amsl.com>; Wed, 8 Jun 2016 00:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oDmWRAmagya for <anima-bootstrap@ietfa.amsl.com>; Wed, 8 Jun 2016 00:00:10 -0700 (PDT)
Received: from atl4mhob23.registeredsite.com (atl4mhob23.registeredsite.com [209.17.115.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8D75F12D11E for <anima-bootstrap@ietf.org>; Wed, 8 Jun 2016 00:00:10 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob23.registeredsite.com (8.14.4/8.14.4) with ESMTP id u5870840059240 for <anima-bootstrap@ietf.org>; Wed, 8 Jun 2016 03:00:08 -0400
Received: (qmail 17564 invoked by uid 0); 8 Jun 2016 07:00:08 -0000
X-TCPREMOTEIP: 213.208.239.114
X-Authenticated-UID: rturner@amalfisystems.com
Received: from unknown (HELO ?172.20.1.19?) (rturner@amalfisystems.com@213.208.239.114) 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 <rturner@amalfisystems.com>
In-Reply-To: <14614.1465348608@obiwan.sandelman.ca>
Date: Wed, 8 Jun 2016 02:59:58 -0400
Message-Id: <CA9CA44C-2EFF-4E01-8A06-B020DB518787@amalfisystems.com>
References: <14614.1465348608@obiwan.sandelman.ca>
To: 6tisch-security@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/SOG2B37MuexekcfniB7zdRHNlmQ>
Cc: anima-bootstrap@ietf.org
Subject: Re: [Anima-bootstrap] [6tisch-security] goals for this 6tisch design team -- zero-touch vs one-touch
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=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 …

Randy


> On Jun 7, 2016, at 9:16 PM, Michael Richardson <mcr+ietf@sandelman.ca> 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:
>    https://datatracker.ietf.org/wg/6tisch/charter/
> 
>    ...
>    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 https://tools.ietf.org/html/draft-richardson-6tisch--security-6top-05
> 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
> <https://tools.ietf.org/html/rfc5077>. 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> 6tisch-security mailing list
> 6tisch-security@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch-security