6tisch Secure Join protocol

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. In other installations (such as some factory/industrial settings, and for some utilities), it is possible to pass devices through a "provisioning" room of some kind where the device in factory default state may be touched once (via a cable, or a push button, or by being placed in a faraday cage, etc.) such that the devices can be initialized in a way specific to that installation. The devices are then returned to inventory, and may be deployed at some future time. The node is not provisioned with the current keying material, as the network will need to be regularly rekeyed (even the algorithms may change!), so in the one-touch provisioning case, the goal is simply to introduce some elements into the new node (the "pledge") such that the enrollment process will take less energy and fewer network resources.

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 following terminology is repeated from so as to have a common way to speak: The physical distribution of equipment containing the "factory default" configuration to a final destination. In zero-touch scenarios there is no staging or pre-configuration during drop-ship. the process where a device obtains the cryptographic key material to identity and trust future interactions with a network. This term is taken from Konrad Lorenz's work in biology with new ducklings: during a critical period, the duckling would assume that anything that looks like a mother duck is in fact their mother. An equivalent for a device is to obtain the fingerprint of the network's root certification authority certificate. A device that imprints on an attacker suffers a similar fate to a duckling that imprints on a hungry wolf. Securely imprinting is a primary focus of this document. anticipates this use. the process where a device presents key material to a network and acquires a network specific identity. For example when a certificate signing request is presented to a certification authority and a certificate is obtained in response. 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. This is definition 6, according to . 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 .

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

In a one-touch scenario, devices would be provided with some mechanism by which a secure association may be made in a controlled environment. There are many ways in which this might be done, and detailing any of them is out of scope for this document. But, some notion of how this might be done is important so that the underlying assumptions can be reasoned about. Some examples of how to do this could include: * JTAG interface * serial (craft) console interface * pushes of physical buttons simulatenous to network attachment * insecured devices operated in a Faraday cage There are likely many other ways as well. What is assumed is that there can be a secure, private conversation between the Join Coordination Entity, and the Pledge, and that the two devices can exchange some trusted bytes of information.

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.

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. 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 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 Extended Beacon, but a pledge MUST listen for an unencrypted Extended Beacon to so that it can synchronize. a known K1 key, as described in section 10, and used for reasons similar to .