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

[Randy Turner <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> 6tisch-security mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch-security