6tisch Zero-Touch Secure Join protocol
draft-ietf-6tisch-dtsecurity-zerotouch-join-00

Internet-Draft   6tisch Zero-Touch Secure Join protocol      August 2017

   The pledge may not know if it is in a zero-touch or one-touch
   situation: the pledge may be able to verify the JRC based upon trust
   anchors that were installed at manufacturing time.  In that case, the
   pledge runs the simplified one-touch process.

   The pledge signals in the EDHOC message_2 if it has accepted the JRC
   certificate.  The JRC will in general, not trust the pledge with the
   network keys until it has provided the pledge with a voucher.  The
   pledge will notice the absence of the provisioning keys.

   XXX - there could be some disconnect here.  May need additional
   signals here.

B.2.  Provisional Enrollment process

   When the pledge determines that it can not verify the certificate of
   the JRC using built-in trust anchors, then it enters a provisional
   state.  In this state, it keeps the channel created by EDHOC open.

   A new EDHOC key derivation is done by the JRC and pledge using a new
   label, "6tisch-provisional".

   The pledge runs as a passive CoMI server, leaving the JRC to drive
   the enrollment process.  The JRC can interrogate the pledge in a
   variety of fashions as shown below: the process terminates when the
   JRC provides the pledge with an ownership voucher and the pledge
   leaves the provisional state.

   A typical interaction involves the following requests:

Richardson & Damm         Expires March 1, 2018                [Page 24]
Internet-Draft   6tisch Zero-Touch Secure Join protocol      August 2017

       +-----------+ +----------+ +-----------+ +----------+
       |           | |          | | Circuit   | | New      |
       |  Vendor   | | Registrar| |  Proxy    | | Entity   |
       |  (MASA)   | |          | |           | |          |
       ++----------+ +--+-------+ +-----------+ +----------+
        |               |     GET  request voucher       |
        |               |-------------------------------->
        |               <----------voucher-token---------|
        |/requestvoucher|                                |
        <---------------+                                |
        +--------------->                                |
        |/requestlog    |                                |
        <---------------+                                |
        +--------------->                                |
        |               |        POST voucher            |
        |               |-------------------------------->
        |               <------------2.05 OK ------------+
        |               |                                |
        |               |        POST csr attributes     |
        |               |-------------------------------->
        |               <------------2.05 OK ------------+
        |               |                                |
        |               |        GET  cert request       |
        |               |-------------------------------->
        |     ????      <------------2.05 OK ------------+
        |<--------------|              CSR               |
        |-------------->|                                |
        |               |        POST certificate        |
        |               |-------------------------------->
        |               <------------2.05 OK ------------+
        |               |                                |

B.3.  Key Distribution Process

   The key distribution process utilizes the protocol described
   [I-D.richardson-6tisch-minimal-rekey].  The process starts with the
   initial key, rather than an actual rekey.

   This protocol remains active for subsequent rekey operations.

Appendix C.  YANG model for BRSKI objects

   module ietf-6tisch-brski { yang-version 1.1;

   namespace "urn:ietf:params:xml:ns:yang:6tisch-brski"; prefix
   "ietf6brski";

Richardson & Damm         Expires March 1, 2018                [Page 25]
Internet-Draft   6tisch Zero-Touch Secure Join protocol      August 2017

   //import ietf-yang-types { prefix yang; } //import ietf-inet-types {
   prefix inet; }

   organization "IETF 6tisch Working Group";

   contact "WG Web: http://tools.ietf.org/wg/6tisch/ WG List:
   6tisch@ietf.org [2] Author: Michael Richardson mcr+ietf@sandelman.ca
   [3]";

   description "This module defines an interface to set and retrieve
   BRSKI objects using CoMI.  This interface is used as part of an
   enrollment process for constrained nodes and networks.";

   revision "2017-03-01" { description "Initial version"; reference "RFC
   XXXX: 6tisch zero-touch bootstrap"; }

   // top-level container container ietf6brski { leaf requestnonce {
   type binary; length XX; // how big can/should it be? mandatory true;
   description "Request Nonce."; } leaf voucher { type binary;
   description "The voucher as a serialized COSE object"; }

   leaf csrattributes {
     type binary;
     description "A list of attributes that MUST be in the CSR";
   }

   leaf certificaterequest {
     type binary;
     description "A PKIX format Certificate Request";
   }

   leaf certificate {
     type binary;
     description "The LDevID certificate";
   }   } }

C.1.  Description of Pledge States in Join Process

   TBD

Appendix D.  Definition of managed objects for zero-touch bootstrap

   The following is relevant YANG for use in the bootstrap protocol.
   The objects identified are identical in format to the named objects
   from [I-D.ietf-anima-bootstrapping-keyinfra].

Richardson & Damm         Expires March 1, 2018                [Page 26]
Internet-Draft   6tisch Zero-Touch Secure Join protocol      August 2017

Appendix E.  Privacy Considerations

   [I-D.ietf-6lo-privacy-considerations] details a number of privacy
   considerations important in Resource Constrained nodes.  There are
   two networks and three sets of constrained nodes to consider.  They
   are: 1. the production nodes on the production network.  2. the new
   pledges, which have yet to enroll, and which are on a join network.
   3. the production nodes which are also acting as proxy nodes.

E.1.  Privacy Considerations for Production network

   The details of this are out of scope for this document.

E.2.  Privacy Considerations for New Pledges

   New Pledges do not yet receive Router Advertisements with PIO
   options, and so configure link-local addresses only based upon
   layer-2 addresses using the normal SLAAC mechanisms described in
   [RFC4191].

   These link-local addresses are visible to any on-link eavesdropper
   (who is synchronized to the same Join Assistant), so regardless of
   what is chosen they can be seen.  This link-layer traffic is
   encapsulated by the Join Assistant into IPIP packets and carried to
   the JCE.  The traffic SHOULD never leave the operator's network, and
   no outside traffic should enter, so it should not be possible to do
   any ICMP scanning as described in
   [I-D.ietf-6lo-privacy-considerations].

   The join process described herein requires that some identifier
   meaningful to the network operator be communicated to the JCE via the
   Neighbor Advertisement's ARO option.  This need not be a manufacturer
   created EUI-64 as assigned by IEEE; it could be another value with
   higher entropy and less interesting vendor/device information.
   Regardless of what is chosen, it can be used to track where the
   device attaches.

   For most constrained device, network attachment occurs very
   infrequently, often only once in their lifetime, so tracking
   opportunities may be rare.

   Further, during the enrollment process, a DTLS connection connection
   will be created.  Unless TLS1.3 is used, the device identity will be
   visible to passive observers in the 802.11AR IDevID certificate that
   is sent.  Even when TLS1.3 is used, an active attacker could collect
   the information by simply connecting to the device; it would not have
   to successful complete the negotiation either, or even attempt to
   Man-In-The-Middle the device.

Richardson & Damm         Expires March 1, 2018                [Page 27]
Internet-Draft   6tisch Zero-Touch Secure Join protocol      August 2017

   There is, at the same time, significant value in avoiding a link-
   local DAD process by using an IEEE assigned EUI-64, and there is also
   significant advantage to the operator being able to see what the
   vendor of the new device is.

E.2.1.  EUI-64 derived address for join time IID

   It is therefore suggested that the IID used in the link-local address
   used during the join process be a vendor assigned EUI-64.  After the
   join process has concluded, the device SHOULD be assigned a unique
   randomly generated long address, and a unique short address (not
   based upon the vendor EUI-64) for use at link-layer.  At that point,
   all layer-3 content is encrypted by the layer-2 key.

E.3.  Privacy Considerations for Join Assistant

Appendix F.  Security Considerations

Appendix G.  IANA Considerations

   This document allocates one value from the subregistry "Address
   Registration Option Status Values": ND_NS_JOIN_DECLINED Join
   Assistant, JOIN DECLINED (TBD-AA)

Appendix H.  Protocol Definition

Appendix I.  Acknowledgements

   Kristofer Pister helped with many non-IETF references.

Authors' Addresses

   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca

   Benjamin Damm
   Silver Spring Networks

   Email: bdamm@ssni.com

Richardson & Damm         Expires March 1, 2018                [Page 28]