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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 08 June 2016 01:16 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 451AB12D93C; Tue, 7 Jun 2016 18:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ycthcSqfL4pu; Tue, 7 Jun 2016 18:16:51 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4344012D93A; Tue, 7 Jun 2016 18:16:51 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A04BF2009E; Tue, 7 Jun 2016 21:23:55 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 30E75638BF; Tue, 7 Jun 2016 21:16:48 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6tisch-security@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.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-sha1; protocol="application/pgp-signature"
Date: Tue, 07 Jun 2016 21:16:48 -0400
Message-ID: <14614.1465348608@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/zHRORFST_VoNaEjjm6qn83sB8Cg>
Cc: anima-bootstrap@ietf.org
Subject: [Anima-bootstrap] 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
Reply-To: 6tisch-security@ietf.org
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 01:16:53 -0000

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

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 =-