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

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jun 2016 21:16:48 -0400

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

---

From: Randy Turner <[email-masked]>
Date: Wed, 8 Jun 2016 02:59:58 -0400

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 <[email-masked]> wrote:
> 
> 
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jun 2016 08:47:51 -0400

Randy Turner <[email-masked]> wrote:
    > The only ANIMA document I can find with “bootstrap” in the title specifically
    > precludes its’ application in constrained environments…

Well, you might have noticed that I'm one of the authors.
And while the *protocol* we intend to use in ANIMA bootstrap is inappropriate
for *6tisch* for a number of subtle reasons, we think:
    a) it will work for "class 3" devices with no UI in non-constrained networks.
    b) the certificate, MIC, TPM, 802.1AR, MASA and registar are designed to
       be useable in both environments.

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

Entire non-edge subsystems, just not the code at the edge.

Back to the question though.  Do you have one-touch process, and if so, would
you want to describe it's capabilities?

    > 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

---

From: Randy Turner <[email-masked]>
Date: Wed, 8 Jun 2016 10:43:11 -0400

We do not have zero or one-touch process, but we do have equivalent 802.1AR device certs - that’s about the only thing we have in common with your item (b) below…

R.

> On Jun 8, 2016, at 8:47 AM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Jun 2016 09:22:11 -0400

Randy Turner <[email-masked]> wrote:
    > We do not have zero or one-touch process, but we do have equivalent
    > 802.1AR device certs - that’s about the only thing we have in common
    > with your item (b) below…

Does a technician have to touch the device before it can join the MESH?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [