[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [209.87.249.19]) (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: 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>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Anima-bootstrap] goals for this 6tisch design te… Michael Richardson
- Re: [Anima-bootstrap] [6tisch-security] goals for… Randy Turner
- Re: [Anima-bootstrap] [6tisch-security] goals for… Michael Richardson
- Re: [Anima-bootstrap] [6tisch-security] goals for… Randy Turner
- Re: [Anima-bootstrap] [6tisch-security] goals for… Michael Richardson