]> Sandelman Software Works

mcr+ietf@sandelman.ca

Internet 6tisch Working Group Internet-Draft This document describes a zero-touch mechanism to enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch signaling mechanisms. The resulting device will obtain a domain specific credential that can be used with either 802.15.9 per-host pair keying protocols, or to obtain the network-wide key from a coordinator. The mechanism describe her is an augmentation to the one-touch mechanism described in .

Enrollment of new nodes into LLNs present unique challenges. The constrained nodes has no user interfaces, and even if they did, configuring thousands of such nodes manually is undesireable from a human resources issue, as well as the difficulty in getting consistent results. This document is about a standard 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. The act of doing "one-touch" provisioning, where a node undergoes a site-specific indoctrination process is described in . The mechanism described here and in can be discovered by a new node in a running network, so a device which has received a network-specific "one-touch" setup, but which is located in another network, and is capable of "zero-touch" operation could discovery this fact and operate in other mode. Many of the components of the zero-touch mechanisms described here are in common with and . The on-the-wire pledge to join registrar protocols are different in this protocol from those described in ANIMA, but conceptually operate identically. The vouchers are identical. It is expected that the back-end network operator infrastructure would be able to bootstrap ANIMA-type devices over ethernet, while also being able bootstrap 6tisch devices over 802.15.4 with few changes.

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant STuPiD implementations. The reader is expected to be familiar with the terms and concepts defined in , , , and . The following terms are imported: drop ship, imprint, enrollment, pledge, join proxy, ownership voucher, join registrar/coordinator. The following terms are repeated here for readability, but this document is not authoritative for their definition: the prospective device, which has the identity provided to at the factory. Neither the device nor the network knows if the device yet knows if this device belongs with this network. the prospective device, after having completing the join process, often just called a Node. a stateless relay that provides connectivity between the pledge and the join registrar/coordinator. central entity responsible for authentication and authorization of joining nodes. A signed token from the manufacturer authorized signing authority indicating that the bootstrapping event has been successfully logged. This has been referred to as an "authorization token" indicating that it authorizes bootstrapping to proceed. A signed voucher from the vendor vouching that a specific domain "owns" the new entity as defined in . manufacturer installed certificate. An identity.

In the zero-touch scenario, every device expected to be drop shipped would have an manufacturer installed certificate (MIC). The private key part of the certificate would either be generated in the device, or installed securely (and privately) as part of the manufacturing process. provides an example of process which has been active for a good part of a decade. The MIC would be signed by the manufacturer's CA, the public key component of that would be included in the firmware.

This document interacts with the one-touch solution described in .

When a manufacturer installed certificate is provided as the IDevID, it SHOULD contain a number of fields. provides a detailed set of requirements. A manufacturer unique serial number MUST be provided in the serialNumber SubjectAltName extension, and MAY be repeated in the Common Name. There are no sequential or numeric requirements on the serialNumber, it may be any unique value that the manufacturer wants to use. The serialNumber SHOULD be printed on the packaging and/or on the device in a discrete way so that failures can be physically traced to the relevant device.

The goal of the bootstrap process is to introduce one or more new locally relevant credentials: a certificate signed by a local certificate authority/registrar. This is the LDevID of . alternatively, a network-wide key to be used to secure L2 traffic. alternatively, a network-wide key to be used to authenticate per-peer keying of L2 traffic using a mechanism such as provided by .

This document is about enrollment of constrained devices to a constrained network. Constrained networks is such as , and in particular the time-slotted, channel hopping (tsch) mode, feature low bandwidths, and limited opportunities to transmit. A key feature of these networks is that receivers are only listening at certain times.

802.15.4 networks have three kinds of layer-2 security: a network key that is shared with all nodes and is used for unicast and multicast. The key may be used for privacy, and it may be used in some cases for authentication only (in the case of enhanced beacons). a series of network keys that are shared (agreed to) between pairs of nodes (the per-peer key) a network key that is shared with all nodes (through a group key management system), and is used for multicast traffic only, while a per-pair key is used for unicast traffic Setting up the credentials to bootstrap one of these kinds of security, (or directly configuring the key itself for the first case) is required. This is the security below the IP layer. Security is required above the IP layer: there are three aspects which the credentials in the previous section are to be used. to provide for secure connection with a Path Computation Element , or other LLC (see ({RFC7554}} section 3). to initiate a connection between a Resource Server (RS) and an application layer Authorization Server (AS and CAS from ).

Perfert Forward Secrecy (PFS) is the property of a protocol such that complete knowledge of the crypto state (for instance, via a memory dump) at time X does not imply that data from a disjoint time Y can also be recovered. (). PFS is important for two reasons: one is that it offers protection against the compromise of a node. It does this by changing the keys in a non-deterministic way. This second property also makes it much easier to remove a node from the network, as any node which has not participated in the key changing process will find itself no longer connected.

The network which the new pledge will connect to will have to have the following properties: a known PANID. The PANID 0xXXXX where XXXX is the assigned RFC# for this document is suggested. a minimal schedule with some Aloha time. This is usually in the same slotframe as the Enhanced Beacon, but a pledge MUST listen for an unencrypted Enhanced Beacon to so that it can synchronize.

TBD.

At the end of the zero-touch join process there will be a symmetric key protected channel between the Join Registrar/Coordinator and the pledge, now known as a Joined Node. This channel may be rekeyed via new exchange of asymmetric exponents (ECDH for instance), authenticated using the domain specific credentials created during the join process. This channel is in the form of an OSCOAP protected connection with encoded objects. This document includes definition of a compatible objects for encoding of the relevant objects.

The pledge join protocol state machine is described in , in section XYZ. The pledge recognizes that it is in zero-touch configuration by the following situation: no PSK has been configured for the network in which it has joined. the pledge has no locally defined certificate (no LDevID), only an IDevID. the network asserts an identity that the pledge does not recognize. All of these conditions MUST be true. If any of these are not true, then the pledge has either been connected to the wrong network, or it has already been bootstrapped into a different network, and it should wait until it finds that network. The zero-touch process consists of three stages: the key agreement process the provisional enrollment process the key distribution process

The key agreement process is identical to . The process uses EDHOC with certificates. The pledge will have to trust the JRC provisionally, as described in , section 3.1.2, and in section 4.1.1 of . The JRC will be able to validate the IDevID of the pledge using the manufacturer's CA. 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.

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:

| <----------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 ------------+ | | | ]]>

The key distribution process utilizes the protocol described . The process starts with the initial key, rather than an actual rekey. This protocol remains active for subsequent rekey operations.

module ietf-6tisch-brski { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:6tisch-brski"; prefix "ietf6brski"; //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 Author: Michael Richardson mcr+ietf@sandelman.ca"; 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"; }

TBD

The following is relevant YANG for use in the bootstrap protocol. The objects identified are identical in format to the named objects from .

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.

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

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

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.

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

Kristofer Pister helped with many non-IETF references.

&RFC2119; &I-D.ietf-6lo-privacy-considerations; &RFC7228; &RFC7030; &I-D.ietf-anima-bootstrapping-keyinfra; &I-D.ietf-6tisch-minimal; &I-D.ietf-anima-grasp; &I-D.richardson-anima-6join-discovery; &I-D.richardson-6tisch-minimal-rekey; &I-D.ietf-6tisch-minimal-security; &I-D.ietf-core-object-security; &I-D.ietf-6tisch-terminology; &I-D.ietf-netconf-keystore; &I-D.ietf-core-comi; Cisco &RFC7217; &I-D.richardson-6tisch-join-enhanced-beacon; &RFC6775; &RFC7252; &I-D.ietf-netconf-zerotouch; &RFC4655; &RFC7554; &RFC4191; &RFC7731; &I-D.ietf-roll-useofrplinfo; &I-D.ietf-ace-actors;

insert appendix here