--- 1/draft-ietf-6tisch-minimal-security-03.txt 2017-10-30 10:13:11.202200166 -0700 +++ 2/draft-ietf-6tisch-minimal-security-04.txt 2017-10-30 10:13:11.250201308 -0700 @@ -1,1028 +1,951 @@ 6TiSCH Working Group M. Vucinic, Ed. -Internet-Draft Inria +Internet-Draft University of Montenegro Intended status: Standards Track J. Simon -Expires: December 17, 2017 Linear Technology +Expires: May 3, 2018 Analog Devices K. Pister University of California Berkeley M. Richardson Sandelman Software Works - June 15, 2017 + October 30, 2017 Minimal Security Framework for 6TiSCH - draft-ietf-6tisch-minimal-security-03 + draft-ietf-6tisch-minimal-security-04 Abstract - This document describes the minimal mechanisms required to support - secure enrollment of a pledge, a device being added to an IPv6 over - the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that - the pledge has been provisioned with a credential that is relevant to - the deployment - the "one-touch" scenario. The goal of this - configuration is to set link-layer keys, and to establish a secure - end-to-end session between each pledge and the join registrar who may - use that to further configure the pledge. Additional security - behaviors and mechanisms may be added on top of this minimal - framework. + This document describes the minimal configuration required for a new + device, called "pledge", to securely join a 6TiSCH (IPv6 over the + TSCH mode of IEEE 802.15.4e) network. The entities involved use CoAP + (Constrained Application Protocol) and OSCORE (Object Security for + Constrained RESTful Environments). The configuration requires that + the pledge and the JRC (join registrar/coordinator, a central + entity), share a symmetric key. How this key is provisioned is out + of scope of this document. The result of the joining process is that + the JRC configures the pledge with link-layer keying material and a + short link-layer address. This specification also defines a new + Stateless-Proxy CoAP option. Additional security mechanisms may be + added on top of this minimal framework. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 17, 2017. + This Internet-Draft will expire on May 3, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. One-Touch Assumptions . . . . . . . . . . . . . . . . . . . . 4 - 4. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5 - 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 6 - 4.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 6 - 4.4. Step 4 - Simple Join Protocol - Join Request . . . . . . 8 - 4.5. Step 5 - Simple Join Protocol - Join Response . . . . . . 8 - 5. Architectural Overview and Communication through Join Proxy . 9 + 3. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Pre-Shared Key . . . . . . . . . . . . . . . . . . . . . 4 + 4. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 6 + 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 7 + 4.3. Step 3 - Join Request . . . . . . . . . . . . . . . . . . 7 + 4.4. Step 4 - Join Response . . . . . . . . . . . . . . . . . 8 + 5. Architectural Overview and Communication through Join Proxy . 8 5.1. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . 9 - 6. Security Handshake . . . . . . . . . . . . . . . . . . . . . 10 - 7. Simple Join Protocol Specification . . . . . . . . . . . . . 11 - 7.1. OSCOAP Security Context Instantiation . . . . . . . . . . 12 - 7.2. Specification of Join Request . . . . . . . . . . . . . . 13 - 7.3. Specification of Join Response . . . . . . . . . . . . . 13 - 8. Mandatory to Implement Algorithms and Certificate Format . . 15 - 9. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 15 - 10. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 16 - 11. Key Derivations . . . . . . . . . . . . . . . . . . . . . . . 16 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 - 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 14.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 18 - 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 16.2. Informative References . . . . . . . . . . . . . . . . . 19 - Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 + 6. OSCORE Security Context . . . . . . . . . . . . . . . . . . . 10 + 6.1. Persistency . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. Specification of Join Request . . . . . . . . . . . . . . . . 11 + 8. Specification of Join Response . . . . . . . . . . . . . . . 11 + 8.1. Link-layer Keys Transported in COSE Key Set . . . . . . . 12 + 8.2. Short Address . . . . . . . . . . . . . . . . . . . . . . 12 + 9. Error Handling and Retransmission . . . . . . . . . . . . . . 13 + 10. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11. Mandatory to Implement Algorithms . . . . . . . . . . . . . . 14 + 12. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 14 + 13. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 15 + 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 16.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 16 + 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 18.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 18.2. Informative References . . . . . . . . . . . . . . . . . 18 + Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction - This document describes the minimal feature set for a new device, - termed pledge, to securely join a 6TiSCH network. As a successful - outcome of this process, the pledge is able to securely communicate - with its neighbors, participate in the routing structure of the - network or establish a secure session with an Internet host. - - When a pledge seeks admission to a 6TiSCH [RFC7554] network, it first - needs to synchronize to the network. The pledge then configures its - link-local IPv6 address and authenticates itself, and also validates - that it is joining the right network. At this point it can expect to - interact with the network to configure its link-layer keying - material. Only then may the node establish an end-to-end secure - session with an Internet host using OSCOAP - [I-D.ietf-core-object-security] or DTLS [RFC6347]. Once the - application requirements are known, the node interacts with its peers - to request additional resources as needed, or to be reconfigured as - the network changes [I-D.ietf-6tisch-6top-protocol]. - - This document presumes a network as described by [RFC7554], - [I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology]. - It assumes the pledge pre-configured with either a: - - o pre-shared key (PSK), + This document presumes a 6TiSCH network as described by [RFC7554], + [RFC8180], [I-D.ietf-6tisch-6top-protocol], and + [I-D.ietf-6tisch-terminology]. By design, nodes in a 6TiSCH network + [RFC7554] have their radio turned off most of the time, to conserve + energy. As a consequence, the link used by a new device for joining + the network has limited bandwidth [RFC8180]. The secure join + solution defined in this document therefore keeps the number of over- + the-air exchanges for join purposes to a minimum. - o raw public key (RPK), + The micro-controllers at the heart of 6TiSCH nodes have a small + amount of code memory. It is therefore paramount to reuse existing + protocols available as part of the 6TiSCH stack. At the application + layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web + transfer, and on OSCORE [I-D.ietf-core-object-security] for its end- + to-end security. The secure join solution defined in this document + therefore reuses those two protocols as its building blocks. - o or a locally-valid certificate and a trust anchor. + This document defines a secure join solution for a new device, called + "pledge", to securely join a 6TiSCH network. The specification + configures different layers of the 6TiSCH protocol stack and also + defines a new CoAP option. It assumes the presence of a JRC (join + registrar/coordinator), a central entity. It further assumes that + the pledge and the JRC share a symmetric key, called PSK (pre-shared + key). How the PSK is installed is out of scope of this document. - As the outcome of the join process, the pledge expects one or more - link-layer key(s) and optionally a temporary link-layer identifier. + When the pledge seeks admission to a 6TiSCH network, it first + synchronizes to it, by initiating the passive scan defined in + [IEEE802.15.4-2015]. The pledge then exchanges messages with the + JRC; these messages can be forwarded by nodes already part of the + 6TiSCH network. The messages exchanged allow the JRC and the pledge + to mutually authenticate, based on the PSK. They also allow the JRC + to configure the pledge with link-layer keying material and a short + link-layer address. After this secure joining process successfully + completes, the joined node can establish an end-to-end secure session + with an Internet host. The joined node can also interact with its + neighbors to request additional bandwidth using the 6top Protocol + [I-D.ietf-6tisch-6top-protocol]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words may also appear in this document in lowercase, absent their normative meanings. The reader is expected to be familiar with the terms and concepts defined in [I-D.ietf-6tisch-terminology], [RFC7252], - [I-D.ietf-core-object-security], and - [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are - imported: pledge, join proxy, join registrar/coordinator, drop ship, - imprint, enrollment, ownership voucher. + [I-D.ietf-core-object-security], and [RFC8152]. - Pledge: the prospective device, which has the identity provided to - at the factory. + The specification also includes a set of informative examples using + the CBOR diagnostic notation [I-D.ietf-cbor-cddl]. - Joined Node: the prospective device, after having completed the join - process, often just called a Node. + The following terms are used throughout this document: - Join Proxy (JP): a stateless relay that provides connectivity - between the pledge and the Join Registrar/Coordinator. + pledge: The new device that wishes to join a 6TiSCH network. - Join Registrar/Coordinator (JRC): central entity responsible for - authentication and authorization of joining nodes. + joined node: The new device, after having completed the join + process, often just called a node. -3. One-Touch Assumptions + join proxy (JP): A node already part of the 6TiSCH network that + serves as a relay to provide connectivity between the pledge and + the JRC. - This document assumes the one-touch scenario, where devices are - 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. + join registrar/coordinator (JRC): A central entity responsible for + the authentication, authorization and configuration of the pledge. - Some examples of how to do this could include: +3. One-Touch Assumption - o JTAG interface + This document assumes a one-touch scenario. The pledge is + provisioned with a PSK before attempting to join the network, and the + same PSK (as well as the uniquer identifier of the pledge) is + provisioned on the JRC. - o serial (craft) console interface + There are many ways by which this provisioning can be done. + Physically, the PSK can be written into the pledge using a number of + mechanisms, such as a JTAG interface, a serial (craft) console + interface, pushing buttons simultaneously on different devices, over- + the-air configuration in a Faraday cage, etc. The provisioning can + be done by the vendor, the manufacturer, the integrator, etc. - o pushes of physical buttons simultaneous to network attachment + Details of how this provisioning is done is out of scope of this + document. What is assumed is that there can be a secure, private + conversation between the JRC and the pledge, and that the two devices + can exchange the PSK. - o unsecured devices operated in a Faraday cage +3.1. Pre-Shared Key - There are likely many other ways as well. What is assumed is that - there can be a secure, private conversation between the Join - Registrar/Coordinator, and the pledge, and that the two devices can - exchange some trusted bytes of information. + The PSK SHOULD be at least 128 bits in length, generated uniformly at + random. It is RECOMMENDED to generate the PSK with a + cryptographically secure pseudorandom number generator. Each pledge + SHOULD be provisioned with a unique PSK. 4. Join Overview This section describes the steps taken by a pledge in a 6TiSCH - network. When a previously unknown device seeks admission to a - 6TiSCH [RFC7554] network, the following exchange occurs: + network. When a pledge seeks admission to a 6TiSCH network, the + following exchange occurs: 1. The pledge listens for an Enhanced Beacon (EB) frame - [IEEE8021542015]. This frame provides network synchronization + [IEEE802.15.4-2015]. This frame provides network synchronization information, and tells the device when it can send a frame to the - node sending the beacons, which plays the role of Join Proxy (JP) + node sending the beacons, which plays the role of join proxy (JP) for the pledge, and when it can expect to receive a frame. - 2. The pledge configures its link-local IPv6 address and advertizes - it to Join Proxy (JP). + 2. The pledge configures its link-local IPv6 address and advertises + it to the join proxy (JP). - 3. The pledge sends packets to JP in order to securely identify - itself to the network. These packets are directed to the Join - Registrar/Coordinator (JRC), which may be co-located on the JP or - another device. + 3. The pledge sends a Join Request to JP in order to securely + identify itself to the network. The Join Request is directed to + the JRC, which may be co-located on the JP or another device. - 4. The pledge receives one or more packets from JRC (via the JP) - that sets up one or more link-layer keys used to authenticate - subsequent transmissions to peers. + 4. In case of successful processing of the request, the pledge + receives a join response from JRC (via the JP) that sets up one + or more link-layer keys used to authenticate and encrypt + subsequent transmissions to peers, and a short link-layer address + for the pledge. From the pledge's perspective, minimal joining is a local phenomenon - the pledge only interacts with the JP, and it need not know how far it is from the 6LBR, or how to route to the JRC. Only after establishing one or more link-layer keys does it need to know about the particulars of a 6TiSCH network. - The handshake is shown as a transaction diagram in Figure 1: + The process is shown as a transaction diagram in Figure 1: +--------+ +-------+ +--------+ | pledge | | JP | | JRC | | | | | | | +--------+ +-------+ +--------+ | | | - |<----ENH BEACON (1)-------| | + |<---Enhanced Beacon (1)---| | | | | |<-Neighbor Discovery (2)->| | | | | - |<---Sec. Handshake (3)----|---Sec. Handshake (3a)--->| + |-----Join Request (3)-----|------Join Request (3a)-->| + | | | + |<---Join Response (4)-----|-----Join Response (4a)---| | | | - ....................................................................... - . |-----Join Request (4)-----|------Join Request (4a)-->| . - . | | | Simple Join . - . |<---Join Response (5)-----|-----Join Response (5a)---| Protocol . - . | | | . - ....................................................................... - Figure 1: Overview of the join process. + Figure 1: Overview of a successful join process. The details of each step are described in the following sections. 4.1. Step 1 - Enhanced Beacon - Due to the channel hopping nature of 6TiSCH, transmissions take place - on physical channels in a circular fashion. For that reason, - Enhanced Beacons (EBs) are expected to be found by listening on a - single channel. However, because some channels may be blacklisted, a - new pledge must listen for Enhanced Beacons for a certain period on - each of the 16 possible channels. This search process entails having - the pledge keep the receiver portion of its radio active for the - entire period of time. - - Once the pledge hears an EB from a JP, it synchronizes itself to the - joining schedule using the cells contained in the EB. The selection - of which beacon to start with is outside the scope of this document. - Implementers SHOULD make use of information such as: whether the L2 - address of the EB has been tried before, any Network Identifier - [I-D.richardson-6tisch-join-enhanced-beacon] seen, and the strength - of the signal. The pledge can be configured with the Network - Identifier to seek when it is configured with the PSK. + The pledge synchronizes to the network by listening for, and + receiving, an Enhanced Beacon (EB) sent by a node already in the + network. This process is entirely defined by [IEEE802.15.4-2015], + and described in [RFC7554]. - Once a candidate network has been selected, the pledge can transition - into a low-power duty cycle, waking up only when the provided - schedule indicates shared slots which the pledge may use for the join - process. + Once the pledge hears an EB, it synchronizes to the joining schedule + using the cells contained in the EB. The pledge can hear multiple + EBs; the selection of which EB to use is out of the scope for this + document, and is discussed in [RFC7554]. Implementers SHOULD make + use of information such as: what Personal Area Network Identifier + (PAN ID) [IEEE802.15.4-2015] the EB contains, whether the source + link-layer address of the EB has been tried before, what signal + strength the different EBs were received at, etc. In addition, the + pledge may be pre-configured to search for EBs with a specific PAN + ID. - At this point the pledge may proceed to step 2, or continue to listen - for additional EBs. + Once the pledge selects the EB, it synchronizes to it and transitions + into a low-power mode. It deeply duty cycles its radio, switching + the radio on when the provided schedule indicates slots which the + pledge may use for the join process. During the remainder of the + join process, the node that has sent the EB to the pledge plays the + role of JP. - A pledge which receives only Enhanced Beacons containing Network ID - extensions [I-D.richardson-6tisch-join-enhanced-beacon] with the - initiate bit cleared, SHOULD NOT proceed with this protocol on that - network. The pledge SHOULD consider that it is in a network which - manages join traffic, it SHOULD switch to - [I-D.ietf-6tisch-dtsecurity-secure-join]. + At this point, the pledge may proceed to step 2, or continue to + listen for additional EBs. 4.2. Step 2 - Neighbor Discovery - At this point, the pledge forms its link-local IPv6 address based on - EUI64 and may register it at JP, in order to bootstrap the IPv6 - neighbor tables. The Neighbor Discovery exchange shown in Figure 1 - refers to a single round trip Neighbor Solicitation / Neighbor - Advertisement exchange between the pledge and the JP. The pledge may - further follow the Neighbor Discovery (ND) process described in - Section 5 of [RFC6775]. - -4.3. Step 3 - Security Handshake - - The security handshake between pledge and JRC uses Ephemeral Diffie- - Hellman over COSE (EDHOC) [I-D.selander-ace-cose-ecdhe] to establish - the shared session secret used to encrypt the Simple Join Protocol. - - The security handshake step is OPTIONAL in case PSKs are used, while - it is REQUIRED for RPKs and certificates. - - When using certificates, the process continues as described in - [I-D.selander-ace-cose-ecdhe], but MAY result in no network key being - returned. In that case, the pledge enters a provisional situation - where it provides access to an enrollment mechanism described in - [I-D.ietf-6tisch-dtsecurity-secure-join]. - - If using a locally relevant certificate, the pledge will be able to - validate the certificate of the JRC via a local trust anchor. In - that case, the JRC will return networks keys as in the PSK case. - This would typically be the case for a device which has slept so long - that it no longer has valid network keys and must go through a - partial join process again. - - In case the handshake step is omitted, the shared secret used for - protection of the Simple Join Protocol in the next step is the PSK. - - A consequence is that if the long-term PSK is compromised, keying - material transferred as part of the join response is compromised as - well. Physical compromise of the pledge, however, would also imply - the compromise of the same keying material, as it is likely to be - found in node's memory. - -4.3.1. Pre-Shared Symmetric Key - - The Diffie-Hellman key exchange and the use of EDHOC is optional, - when using a pre-shared symmetric key. This cuts down on traffic - between JRC and pledge, but requires pre-configuration of the shared - key on both devices. - - It is REQUIRED to use unique PSKs for each pledge. If there are - multiple JRCs in the network (such as for redundancy), they would - have to share a database of PSKs. - -4.3.2. Asymmetric Keys + The pledge forms its link-local IPv6 address based on EUI-64, as per + [RFC4944]. The Neighbor Discovery exchange shown in Figure 1 refers + to a single round trip Neighbor Solicitation / Neighbor Advertisement + exchange between the pledge and the JP (Section 5.5.1 of [RFC6775]). + The pledge uses the link-local IPv6 address for all subsequent + communication with the JP during the join process. - The Security Handshake step is required, when using asymmetric keys. - Before conducting the Diffie-Hellman key exchange using EDHOC - [I-D.selander-ace-cose-ecdhe] the pledge and JRC need to receive and - validate each other's public key certificate. As detailed above, - this can only be done for locally relevant (LDevID) certificates. - IDevID certificates require entering a provisional state as described - in [I-D.ietf-6tisch-dtsecurity-secure-join]. + Note that ND exchanges at this point are not protected with link- + layer security as the pledge is not in possession of the keys. How + JP accepts these unprotected frames is discussed in Section 12. - When RPKs are pre-configured at pledge and JRC, they can directly - proceed to the handshake. + The pledge and the JP SHOULD keep a separate neighbor cache for + untrusted entries and use it to store each other's information during + the join process. Mixing neighbor entries belonging to pledges and + nodes that are part of the network opens up the JP to a DoS attack. + How the pledge and JP decide to transition each other from untrusted + to trusted cache, once the join process completes, is out of scope. + One implementation technique is to use the information whether the + incoming frames are secured at the link layer. -4.4. Step 4 - Simple Join Protocol - Join Request +4.3. Step 3 - Join Request - The Join Request that makes part of the Simple Join Protocol is sent - from the pledge to the JP using the shared slot as described in the - EB, and forwarded to the JRC. Which slot the JP uses to transmit to - the JRC is out of scope: some networks may wish to dedicate specific - slots for this join traffic. + The Join Request is a message sent from the pledge to the JP using + the shared slot as described in the EB, and which the JP forwards to + the JRC. The JP forwards the Join Request to the JRC on the existing + 6TiSCH network. How exactly this happens is out of scope of this + document; some networks may wish to dedicate specific slots for this + join traffic. - The join request is authenticated/encrypted end-to-end using an - algorithm from [I-D.ietf-cose-msg] and a key derived from the shared - secret from step 3. Algorithm negotiation is described in detail in - [I-D.selander-ace-cose-ecdhe], and mandatory to implement algorithms - are specified in Section 8. + The Join Request is authenticated/encrypted end-to-end using an AEAD + algorithm from [RFC8152] and a key derived from the PSK, the pledge's + EUI-64 and a request-specific constant value. Algorithms which MUST + be implemented are specified in Section 11. - The nonce is derived from the shared secret, the pledge's EUI64 and a - monotonically increasing counter initialized to 0 when first - starting. + The nonce used when securing the Join Request is derived from the + PSK, the pledge's EUI-64 and a monotonically increasing counter + initialized to 0 when first starting. -4.5. Step 5 - Simple Join Protocol - Join Response + Join Request construction is specified in Section 7, while the + details on processing can be found in Section 7 of + [I-D.ietf-core-object-security]. - The Join Response that makes part of the Simple Join Protocol is sent - from the JRC to the pledge through JP that serves as a stateless - relay. Packet containing the Join Response travels on the path from - JRC to JP using pre-established routes in the network. The JP - delivers it to the pledge using the slot information from the EB. JP - operates as the application-layer proxy and does not keep any state - to relay the message. It uses information sent in the clear within - the join response to decide where to forward to. +4.4. Step 4 - Join Response - The join response is authenticated/encrypted end-to-end using an - algorithm from [I-D.ietf-cose-msg] and a key derived from the shared - secret from step 3. + The Join Response is sent by the JRC to the pledge, and is forwarded + through the JP as it serves as a stateless relay. The packet + containing the Join Response travels from the JRC to JP using the + operating routes in the 6TiSCH network. The JP delivers it to the + pledge using the slot information it has indicated in the EB it sent. + The JP operates as the application-layer proxy, and does not keep any + state to relay the message. It uses information sent in the clear + within the Join Response to decide where to forward to. - The nonce is derived from the shared secret, pledge's EUI64 and a - monotonically increasing counter matching that of the join request. + The Join Response is authenticated/encrypted end-to-end using an AEAD + algorithm from [RFC8152]. The key used to protect the response is + different from the one used to protect the request (both are derived + from the PSK, as explained in Section 6). The response is protected + using the same nonce as in the request. - The join response contains one or more link-layer key(s) that the + The Join Response contains one or more link-layer key(s) that the pledge will use for subsequent communication. Each key that is provided by the JRC is associated with an 802.15.4 key identifier. In other link-layer technologies, a different identifier may be - substituted. Join Response optionally also contains an IEEE 802.15.4 - short address [IEEE8021542015] assigned to pledge by JRC, and the - IPv6 address of the JRC. + substituted. The Join Response also contains an IEEE 802.15.4 short + address [IEEE802.15.4-2015] assigned by the JRC to the pledge, and + optionally the IPv6 address of the JRC. + + Join Response construction is specified in Section 8, while the + details on processing can be found in Section 7 of + [I-D.ietf-core-object-security]. 5. Architectural Overview and Communication through Join Proxy - The protocol in Figure 1 is implemented over Constrained Application - Protocol (CoAP) [RFC7252]. The Pledge plays the role of a CoAP - client, JRC the role of a CoAP server, while JP implements CoAP - forward proxy functionality [RFC7252]. Since JP is also likely a - constrained device, it does not need to implement a cache but rather - process forwarding-related CoAP options and make requests on behalf - of pledge that is not yet part of the network. + The Join Request/Join Response exchange in Figure 1 is carried over + CoAP [RFC7252] and secured using OSCORE + [I-D.ietf-core-object-security]. The pledge plays the role of a CoAP + client; the JRC plays the role of a CoAP server. The JP implements + CoAP forward proxy functionality [RFC7252]. Because the JP can also + be a constrained device, it cannot implement a cache. Rather, the JP + processes forwarding-related CoAP options and makes requests on + behalf of the pledge, in a stateless manner. - The pledge communicates with a Join Proxy (JP) over link-local IPv6 - addresses. The pledge designates a JP as a proxy by including in the - CoAP requests to the JP the Proxy-Scheme option with value "coap" - (CoAP-to-CoAP proxy). The pledge MUST include the Uri-Host option - with its value set to the well-known JRC's alias - "6tisch.arpa". - The pledge learns the actual IPv6 address of JRC from the join - response and it uses it once joined in order to operate as JP. The - initial bootstrap of the 6LBR would require explicit provisioning of - the JRC address. + The pledge communicates with a JP over link-local IPv6 addresses. + The pledge designates a JP as a proxy by including the Proxy-Scheme + option with value "coap" (CoAP-to-CoAP proxy) in CoAP requests it + sends to the JP. The pledge MUST include the Uri-Host option with + its value set to the well-known JRC's alias "6tisch.arpa". This + allows the pledge to join without knowing the IPv6 address of the + JRC. The pledge learns the actual IPv6 address of the JRC from the + Join Response; it uses it once joined in order to operate as a JP. + + The JRC can be co-located on the 6LBR. Before the 6TiSCH network is + started, the 6LBR MUST be provisioned with the IPv6 address of the + JRC. 5.1. Stateless-Proxy CoAP Option - The CoAP proxy by default keeps per-client state information in order - to forward the response towards the originator of the request - (client). This state information comprises CoAP token, but the - implementations also need to keep track of the IPv6 address of the - host, as well as the corresponding UDP source port number. In the - setting where the proxy is a constrained device and there are - potentially many clients, as in the case of JP, this makes it prone - to Denial of Service (DoS) attacks, due to the limited memory. + The CoAP proxy defined in [RFC7252] keeps per-client state + information in order to forward the response towards the originator + of the request. This state information includes at least the CoAP + token, the IPv6 address of the host, and the UDP source port number. + If the JP used the stateful CoAP proxy defined in [RFC7252], it would + be prone to Denial-of-Service (DoS) attacks, due to its limited + memory. - The Stateless-Proxy CoAP option (c.f. Figure 2) allows the proxy to - insert within the request the state information necessary for - relaying the response back to the client. Note that the proxy still - needs to keep some state, such as for performing congestion control - or request retransmission, but what is aimed with Stateless-Proxy - option is to free the proxy from keeping per-client state. + The Stateless-Proxy CoAP option Figure 2 allows the JP to be entirely + stateless. This option inserts, in the request, the state + information needed for relaying the response back to the client. The + proxy still keeps some general state (e.g. for congestion control or + request retransmission), but no per-client state. - Stateless-Proxy option is critical, Safe-to-Forward, not part of the - cache key, not repeatable and opaque. When processed by OSCOAP, - Stateless-Proxy option is neither encrypted nor integrity protected. + The Stateless-Proxy CoAP option is critical, Safe-to-Forward, not + part of the cache key, not repeatable and opaque. When processed by + OSCORE, the Stateless-Proxy option is neither encrypted nor integrity + protected. +-----+---+---+---+---+-----------------+--------+--------+ | No. | C | U | N | R | Name | Format | Length | +-----+---+---+---+---+-----------------+--------+--------| | TBD | x | | x | | Stateless-Proxy | opaque | 1-255 | +-----+---+---+---+---+-----------------+--------+--------+ C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable Figure 2: Stateless-Proxy CoAP Option Upon reception of a Stateless-Proxy option, the CoAP server MUST echo it in the response. The value of the Stateless-Proxy option is internal proxy state that is opaque to the server. Example state - information includes IPv6 address of the client, its UDP source port, - and the CoAP token. For security reasons, the state information MUST - be authenticated, MUST include a freshness indicator (e.g. a sequence - number or timestamp) and MAY be encrypted. The proxy may use an - appropriate COSE structure [I-D.ietf-cose-msg] to wrap the state - information as the value of the Stateless-Proxy option. The key used - for encryption/authentication of the state information may be known - only to the proxy. + information includes the IPv6 address of the client, its UDP source + port, and the CoAP token. For security reasons, the state + information MUST be authenticated, MUST include a freshness indicator + (e.g. a sequence number or timestamp) and MAY be encrypted. The + proxy may use an appropriate COSE structure [RFC8152] to wrap the + state information as the value of the Stateless-Proxy option. The + key used for encryption/authentication of the state information may + be known only to the proxy. Once the proxy has received the CoAP response with Stateless-Proxy option present, it decrypts/authenticates it, checks the freshness indicator and constructs the response for the client, based on the information present in the option value. Note that a CoAP proxy using the Stateless-Proxy option is not able - to return 5.04 Gateway Timeout error in case the request to the - server times out. Likewise, if the response to the proxy's request - does not contain the Stateless-Proxy option, for example when the - option is not supported by the server, the proxy is not able to + to return a 5.04 Gateway Timeout Response Code in case the request to + the server times out. Likewise, if the response to the proxy's + request does not contain the Stateless-Proxy option, for example when + the option is not supported by the server, the proxy is not able to return the response to the client. -6. Security Handshake - - In order to derive a shared session key, pledge and JRC run the EDHOC - protocol [I-D.selander-ace-cose-ecdhe]. During this process, pledge - and JRC mutually authenticate each other and verify authorization - information before proceeding with the Simple Join Protocol. In case - certificates are used for authentication, this document assumes that - a special certificate with role attribute set has been provisioned to - the JRC. This certificate is verified by pledge in order to - authorize JRC to continue with the join process. How such a - certificate is issued to the JRC is out of scope of this document. - - Figure 3 details the exchanges between the pledge and JRC that take - place during the execution of the security handshake. Format of - EDHOC messages is specified in [I-D.selander-ace-cose-ecdhe]. The - handshake is initiated by the pledge. JRC may either respond with an - empty CoAP acknowledgment, signaling to the pledge that it needs to - wait, or directly with the second message of EDHOC handshake. How - JRC decides whether it will immediately proceed with the handshake is - out of scope of this document. - - +--------+ +--------+ - | pledge | | JRC | - | | | | - +--------+ +--------+ - | | - | EDHOC message_1 | - +-------------------------------->| - | | - | Optional ACK | - |< - - - - - - - - - - - - - - - -+ - ~ ~ - | | - | EDHOC message_2 | - |<--------------------------------+ - | | - | EDHOC message_3 | - +-------------------------------->| - | | - - Figure 3: Transaction diagram of the security handshake. +6. OSCORE Security Context -7. Simple Join Protocol Specification + The OSCORE security context MUST be derived at the pledge and the JRC + as per Section 3 of [I-D.ietf-core-object-security]. - Simple Join Protocol is a single round trip protocol (c.f. Figure 4) - that facilitates secure enrollment of a pledge, based on a shared - symmetric secret. In case the pledge was provisioned by an - asymmetric key (certificate or RPK), Simple Join Protocol is preceded - by a security handshake, described in Section 6. When the pledge is - provisioned with a PSK, Simple Join Protocol may be run directly. + o the Master Secret MUST be the PSK. - Pledge and JRC MUST protect their exchange end-to-end (i.e. through - the proxy) using Object Security of CoAP (OSCOAP) - [I-D.ietf-core-object-security]. + o the Master Salt MUST be pledge's EUI-64. - +--------+ +--------+ - | pledge | | JRC | - | | | | - +--------+ +--------+ - | | - | Join Request | - +-------------------------------->| - | | - | Join Response | - |<--------------------------------+ - | | + o the Sender ID of the pledge MUST be set to byte string 0x00. - Figure 4: Transaction diagram of the Simple Join Protocol. + o the Recipient ID (ID of the JRC) MUST be set to byte string 0x01. -7.1. OSCOAP Security Context Instantiation + o the Algorithm MUST be set to the value from [RFC8152], agreed out- + of-band by the same mechanism used to provision the PSK. The + default is AES-CCM-16-64-128. - The OSCOAP security context MUST be derived at pledge and JRC as per - Section 3.2 of [I-D.ietf-core-object-security] using HKDF SHA-256 - [RFC5869] as the key derivation function. + o the Key derivation function MUST be agreed out-of-band. Default + is HKDF SHA-256. - o Master Secret MUST be the secret generated by the run of EDHOC as - per Appendix B of [I-D.selander-ace-cose-ecdhe], or the PSK in - case EDHOC step was omitted. + The derivation in [I-D.ietf-core-object-security] results in traffic + keys and a common IV for each side of the conversation. Nonces are + constructed by XOR'ing the common IV with the current sequence number + and sender identifier. For details on nonce construction, refer to + [I-D.ietf-core-object-security]. - o Sender ID of the pledge MUST be set to the concatenation of its - EUI-64 and byte string 0x00. + It is RECOMMENDED that a PAN ID be provisioned to the pledge out-of- + band by the same mechanism used to provision the PSK. This prevents + the pledge from attempting to join a wrong network. If the pledge is + not provisioned with the PAN ID, it SHOULD attempt to join one + network at a time. In that case, implementations MUST ensure that + multiple CoAP requests to different JRCs result in the use of the + same OSCORE context so that sequence numbers are properly incremented + for each request. - o Recipient ID (ID of JRC) MUST be set to the concatenation of - pledge's EUI-64 and byte string 0x01. The construct uses pledge's - EUI-64 to avoid nonce reuse in the response in the case same PSK - is shared by a group of pledges. +6.1. Persistency - o Algorithm MUST be set to the value from [I-D.ietf-cose-msg] agreed - by the run of EDHOC, or out-of-band in case of PSKs. + Implementations MUST ensure that mutable OSCORE context parameters + (Sender Sequence Number, Replay Window) are stored in persistent + memory. A technique that prevents reuse of sequence numbers, + detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be + implemented. Each update of the OSCORE Replay Window MUST be written + to persistent memory. - The derivation in [I-D.ietf-core-object-security] results in traffic - keys and static IVs for each side of the conversation. Nonces are - constructed by XOR'ing the static IV with current sequence number. - The context derivation process occurs exactly once. + This is an important security requirement in order to guarantee nonce + uniqueness and resistance to replay attacks across reboots and + rejoins. Traffic between the pledge and the JRC is rare, making + security outweigh the cost of writing to persistent memory. - Implementations MUST ensure that multiple CoAP requests to different - JRCs result in the use of the same OSCOAP context so that sequence - numbers are properly incremented for each request. This may happen - in a scenario where there are multiple 6TiSCH networks present and - the pledge tries to join one network at a time. +7. Specification of Join Request -7.2. Specification of Join Request + The Join Request the pledge sends SHALL be mapped to a CoAP request: - Message Join Request SHALL be mapped to a CoAP request: + o The request method is POST. - o The request method is GET. + o The type is Non-confirmable (NON). o The Proxy-Scheme option is set to "coap". o The Uri-Host option is set to "6tisch.arpa". o The Uri-Path option is set to "j". - o The object security option SHALL be set according to - [I-D.ietf-core-object-security] and OSCOAP parameters set as - described above. + o The Object-Security option SHALL be set according to + [I-D.ietf-core-object-security]. The OSCORE Context Hint SHALL be + set to pledge's EUI-64. The OSCORE Context Hint allows the JRC to + retrieve the security context for a given pledge. -7.3. Specification of Join Response + o The payload is empty. - If OSCOAP processing is a success and the pledge is authorized to - join the network, message Join Response SHALL be mapped to a CoAP - response: +8. Specification of Join Response - o The response Code is 2.05 (Content). + If the JRC successfully processes the Join Request using OSCORE, and + if the pledge is authorized to join the network, the Join Response + the JRC sends back to the pledge SHALL be mapped to a CoAP response: - o Content-Format option is set to application/cbor. + o The response Code is 2.04 (Changed). o The payload is a CBOR [RFC7049] array containing, in order: - * COSE Key Set, specified in [I-D.ietf-cose-msg], containing one - or more link-layer keys. The mapping of individual keys to - 802.15.4-specific parameters is described in Section 7.3.1. + * the COSE Key Set, specified in [RFC8152], containing one or + more link-layer keys. The mapping of individual keys to + 802.15.4-specific parameters is described in Section 8.1. - * Optional. Link layer short address that is assigned to the - pledge. The format of the short address follows Section 7.3.2. + * the link-layer short address to be used by the pledge. The + format of the short address follows Section 8.2. - * Optional. IPv6 address of the JRC transported as a byte - string. If the address of the JRC is not present in the - response, JRC is co-located with 6LBR. + * optionally, the IPv6 address of the JRC transported as a byte + string. If the IPv6 address of the JRC is not present in the + Join Response, this indicates the JRC is co-located with 6LBR, + and has the same IPv6 address as the 6LBR. The address of the + 6LBR can then be learned from DODAGID field in RPL DIOs + [RFC6550]. - payload = [ + response_payload = [ COSE_KeySet, - ? short_address, + short_address, ? JRC_address : bstr, ] -7.3.1. Link-layer Keys Transported in COSE Key Set +8.1. Link-layer Keys Transported in COSE Key Set - Each key in the COSE Key Set [I-D.ietf-cose-msg] SHALL be a symmetric - key. If "kid" parameter of the COSE Key structure is present, the + Each key in the COSE Key Set [RFC8152] SHALL be a symmetric key. If + the "kid" parameter of the COSE Key structure is present, the corresponding keys SHALL belong to an IEEE 802.15.4 KeyIdMode 0x01 - class. In that case, parameter "kid" of COSE Key structure SHALL be - used to carry IEEE 802.15.4 KeyIndex value. If the "kid" parameter - is not present in the transported key, the application SHALL consider - the key to be an IEEE 802.15.4 KeyIdMode 0x00 (implicit) key. This - document does not support IEEE 802.15.4 KeyIdMode 0x02 and 0x03 class - keys. + class. In that case, parameter "kid" of the COSE Key structure SHALL + be used to carry the IEEE 802.15.4 KeyIndex value. If the "kid" + parameter is not present in the transported key, the application + SHALL consider the key to be an IEEE 802.15.4 KeyIdMode 0x00 + (implicit) key. This document does not support IEEE 802.15.4 + KeyIdMode 0x02 and 0x03 class keys. -7.3.2. Short Address +8.2. Short Address - Optional "short_address" structure transported as part of the join - response payload represents IEEE 802.15.4 short address assigned to - the pledge. It is encoded as CBOR array object, containing in order: + The "short_address" structure transported as part of the join + response payload represents the IEEE 802.15.4 short address assigned + to the pledge. It is encoded as a CBOR array object, containing, in + order: o Byte string, containing the 16-bit address. - o Optional lease time parameter, "lease_asn". The value of the - "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN) + o Optionally, the lease time parameter, "lease_asn". The value of + the "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN) corresponding to its expiration, carried as a byte string in network byte order. short_address = [ address : bstr, ? lease_asn : bstr, ] - It is up to the joined node to request a new short address before the expiry of its previous address. The mechanism by which the node requests renewal is the same as during join procedure, as described - in Section 10. The assigned short address is used for configuring - both Layer 2 short address and Layer 3 addresses. + in Section 13. The assigned short address is used for configuring + both link-layer short address and IPv6 addresses. -7.3.3. Error Handling +9. Error Handling and Retransmission - In the case JRC determines that pledge is not supposed to join the - network (e.g. by failing to find an appropriate security context), it - should respond with a 4.01 Unauthorized error. Upon reception of a - 4.01 Unauthorized, the pledge SHALL attempt to join the next - advertised 6TiSCH network. If all join attempts have failed at - pledge, the pledge SHOULD signal to the user by an out-of-band - mechanism the presence of an error condition. + Since the Join Request is mapped to a Non-confirmable CoAP message, + OSCORE processing at JRC will silently drop the request in case of a + failure. This may happen for a number of reasons, including failed + lookup of an appropriate security context, failed decryption, + positive replay window lookup, formatting errors possibly due to + malicious alterations in transit. Silent drop at JRC prevents a DoS + attack where an attacker could force the pledge to attempt joining + one network at a time, until all networks have been tried. - In the case that the JRC determines that the pledge is not (yet) - authorized to join the network, but a further zero-touch process - might permit it, the JRC responds with a 2.05 (Content) code, but the - payload contains the single CBOR string "prov" (for "provisional"). - No link-layer keys or short address is returned. + Using Non-confirmable CoAP message to transport Join Request also + helps minimize the required CoAP state at the pledge and the Join + Proxy, keeping it to a minimum typically needed to perform CoAP + congestion control. It does, however, introduce complexity at the + application layer, as the pledge needs to implement a retransmission + mechanism. - This response is typically only expected when in asymmetric - certificate mode using 802.1AR IDevID certificates. But for reasons - of provisioning or device reuse, this could occur even when a one- - touch PSK authentication process was expected. + The following binary exponential back-off algorithm is inspired by + the one described in [RFC7252]. For each Join Request the pledge + sends while waiting for a Join Response, the pledge MUST keep track + of a timeout and a retransmission counter. For a new Join Request, + the timeout is set to a random value between TIMEOUT and (TIMEOUT * + TIMEOUT_RANDOM_FACTOR), and the retransmission counter is set to 0. + When the timeout is triggered and the retransmission counter is less + than MAX_RETRANSMIT, the Join Request is retransmitted, the + retransmission counter is incremented, and the timeout is doubled. + Note that the retransmitted Join Request passes new OSCORE + processing, such that the sequence number in the OSCORE context is + properly incremented. If the retransmission counter reaches + MAX_RETRANSMIT on a timeout, the pledge SHOULD attempt to join the + next advertised 6TiSCH network. If the pledge receives a Join + Response that successfully passed OSCORE processing, it cancels the + pending timeout and processes the response. The pledge MUST silently + discard any response not protected with OSCORE, including error + codes. For default values of retransmission parameters, see + Section 10. -8. Mandatory to Implement Algorithms and Certificate Format + If all join attempts to advertised networks have failed, the pledge + SHOULD signal to the user the presence of an error condition, through + some out-of-band mechanism. - The mandatory to implement symmetric-key algorithm for use with - OSCOAP is AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. This is the - algorithm used in 802.15.4, and is present in hardware on many - platforms. With this choice, CoAP messages are therefore protected - with an 8-byte CCM authentication tag and the algorithm uses 13-byte - long nonces. +10. Parameters - The mandatory to implement hash algorithm is SHA-256 [RFC4231]. + This specification uses the following parameters: - Certificates or pre-configured RPKs may be used to exchange public - keys between the pledge and JRC. The mandatory to implement Elliptic - Curve is P-256, also known as secp256r1. The mandatory to implement - signature algorithm is ECDSA with SHA-256. + +-----------------------+----------------+ + | Name | Default Value | + +-----------------------+----------------+ + | TIMEOUT | 10 s | + +-----------------------+----------------+ + | TIMEOUT_RANDOM_FACTOR | 1.5 | + +-----------------------+----------------+ + | MAX_RETRANSMIT | 4 | + +----------------------------------------+ - The certificate itself may be a compact representation of an X.509 - certificate, or a full X.509 certificate. Compact representation of - X.509 certificates is out of scope of this specification. The - certificate is signed by a root CA whose certificate is installed on - all nodes participating in a particular 6TiSCH network, allowing each - node to validate the certificate of the JRC or pledge as appropriate. + The values of TIMEOUT, TIMEOUT_RANDOM_FACTOR, MAX_RETRANSMIT may be + configured to values specific to the deployment. The default values + have been chosen to accommodate a wide range of deployments, taking + into account dense networks. -9. Link-layer Requirements +11. Mandatory to Implement Algorithms - In an operational 6TiSCH network, all frames MUST use link-layer - frame security. The frame security options MUST include frame - authentication, and MAY include frame encryption. + The mandatory to implement AEAD algorithm for use with OSCORE is AES- + CCM-16-64-128 from [RFC8152]. This is the algorithm used for + securing 802.15.4 frames, and hardware acceleration for it is present + in virtually all compliant radio chips. With this choice, CoAP + messages are protected with an 8-byte CCM authentication tag, and the + algorithm uses 13-byte long nonces. - Link-layer frames are protected with a 16-byte key, and a 13-byte - nonce constructed from current Absolute Slot Number (ASN) and the - source (the JP for EBs) address, as shown in Figure 5: + The mandatory to implement hash algorithm is SHA-256 [RFC4231]. - +-------------------------------------------+ - | Address (8B or 00-padded 2B) | ASN (5B) | - +-------------------------------------------+ +12. Link-layer Requirements - Figure 5: Link-layer CCM* nonce construction + In an operational 6TiSCH network, all frames MUST use link-layer + frame security [RFC8180]. The frame security options MUST include + frame authentication, and MAY include frame encryption. The pledge does not initially do any authentication of the EB frames, - as it does not know the K1 key. When sending frames, the pledge - sends unencrypted and unauthenticated frames. JP accepts these - frames (exempt mode in 802.15.4) for the duration of the join - process. How JP learns whether the join process is ongoing is out of - scope of this specification. + as it does not know the K1 key [RFC8180]. When sending frames, the + pledge sends unencrypted and unauthenticated frames. The JP accepts + these frames (using the "exempt mode" in 802.15.4) for the duration + of the join process. How the JP learns whether the join process is + ongoing is out of scope of this specification. - As the EB itself cannot be authenticated by pledge, an attacker may - craft a frame that appears to be a valid EB, since the pledge can + As the EB itself cannot be authenticated by the pledge, an attacker + may craft a frame that appears to be a valid EB, since the pledge can neither know the ASN a priori nor verify the address of the JP. This - permits a Denial of Service (DoS) attack at the pledge. Beacon - authentication keys are discussed in [I-D.ietf-6tisch-minimal]. - -10. Rekeying and Rejoin - - This protocol handles initial keying of the pledge. For reasons such - as rejoining after a long sleep, or expiry of the short address, the - joined node MAY send a new Join Request over the previously - established secure end-to-end session with JRC. JRC responds with - up-to-date keys and a short address. The node may also use the - Simple Join Protocol exchange for node-initiated rekeying. How node - learns that it should be rekeyed is out of scope. Additional work, - such as in [I-D.richardson-6tisch-minimal-rekey] can be used. - -11. Key Derivations + opens up a possibility of DoS attack, as discussed in Section 14. + Beacon authentication keys are discussed in [RFC8180]. - When EDHOC is used to derive keys, the cost of the asymmetric - operation can be amortized over any additional connections that may - be required between the node (during or after joining) and the JRC. +13. Rekeying and Rejoin - Each application SHOULD use a unique session key. EDHOC was designed - with this in mind. In order to accomplish this, the EDHOC key - derivation algorithm can be run with a different label. Other users - of this key MUST define the label. + This specification handles initial keying of the pledge. For reasons + such as rejoining after a long sleep, expiry of the short address, or + node-initiated rekeying, the joined node MAY send a new Join Request + using the already-established OSCORE security context. The JRC then + responds with up-to-date keys and a (possibly new) short address. + How the joined node decides when to rekey is out of scope of this + document. Mechanisms for rekeying the network are defined in + companion specifications, such as + [I-D.richardson-6tisch-minimal-rekey]. -12. Security Considerations +14. Security Considerations - In case PSKs are used, this document mandates that the pledge and JRC - are pre-configured with unique keys. The uniqueness of generated - nonces is guaranteed under the assumption of unique EUI64 identifiers - for each pledge. Note that the address of the JRC does not take part - in nonce construction. Therefore, even should an error occur, and a - PSK shared by a group of nodes, the nonces constructed as part of the - different responses are unique. The PSK is still important for - authentication of the pledge and authentication of the JRC to the - pledge. Should an attacker come to know the PSK, then a man-in-the- - middle attack is possible. The well known problem with Bluetooth - headsets with a "0000" pin applies here. The design differentiates - between nonces constructed for requests and nonces constructed for - responses by different sender identifiers (0x00 for pledge and 0x01 - for JRC). + This document recommends that the pledge and JRC are provisioned with + unique PSKs. The request nonce and the response nonce are the same, + but used under a different key. The design differentiates between + keys derived for requests and keys derived for responses by different + sender identifiers (0x00 for pledge and 0x01 for JRC). Note that the + address of the JRC does not take part in nonce or key construction. + Even in case of a misconfiguration in which the same PSK is used for + several nodes, the keys used to protect the requests/responses from/ + towards different pledges are different, as they are derived using + the pledge's EUI-64 as Master Salt. The PSK is still important for + mutual authentication of the pledge and JRC. Should an attacker come + to know the PSK, then a man-in-the-middle attack is possible. The + well-known problem with Bluetooth headsets with a "0000" pin applies + here. - Being a stateless relay, JP blindly forwards the join traffic into - the network. While the exchange between pledge and JP takes place - over a shared cell, join traffic is forwarded using dedicated cells - on the JP to JRC path. In case of distributed scheduling, the join - traffic may therefore cause intermediate nodes to request additional - bandwidth. (EDNOTE: this is a problem that needs to be solved) - Because the relay operation of JP is implemented at the application - layer, JP is the only hop on the JP-6LBR path that can distinguish - join traffic from regular IP traffic in the network. It is therefore - recommended to implement stateless rate limiting at JP: a simple - bandwidth (in bytes or packets/second) cap would be appropriate. + Being a stateless relay, the JP blindly forwards the join traffic + into the network. While the exchange between pledge and JP takes + place over a shared 6TiSCH cell, join traffic is forwarded using + dedicated cells on the JP to JRC multi-hop path. In case of + distributed scheduling, the join traffic may therefore cause + intermediate nodes to request additional bandwidth. Because the + relay operation of the JP is implemented at the application layer, + the JP is the only hop on the JP-6LBR path that can distinguish join + traffic from regular IP traffic in the network. It is therefore + recommended to implement stateless rate limiting at JP; a simple + bandwidth cap would be appropriate. - The shared nature of the "minimal" cell used for join traffic makes - the network prone to DoS attacks by congesting the JP with bogus - radio traffic. As such an attacker is limited by emitted radio - power, redundancy in the number of deployed JPs alleviates the issue - and also gives the pledge a possibility to use the best available - link for join. How a network node decides to become a JP is out of - scope of this specification. + The shared nature of the "minimal" cell used for the join traffic + makes the network prone to DoS attacks by congesting the JP with + bogus radio traffic. As such an attacker is limited by its emitted + radio power, the redundancy in the number of deployed JPs alleviates + the issue and also gives the pledge a possibility to use the best + available link for joining. How a network node decides to become a + JP is out of scope of this specification. - At the time of the join, the pledge has no means of verifying the - content in the EB and has to accept it at "face value". In case the - pledge tries to join an attacker's network, the join response message - in such cases will either fail the security check or time out. The - pledge may implement a blacklist in order to filter out undesired - beacons and try to join the next seemingly valid network. The - blacklist alleviates the issue but is effectively limited by the - node's available memory. Such bogus beacons will prolong the join - time of the pledge and so the time spent in "minimal" - [I-D.ietf-6tisch-minimal] duty cycle mode. + At the beginning of the join process, the pledge has no means of + verifying the content in the EB, and has to accept it at "face + value". In case the pledge tries to join an attacker's network, the + Join Response message will either fail the security check or time + out. The pledge may implement a blacklist in order to filter out + undesired EBs and try to join using the next seemingly valid EB. + This blacklist alleviates the issue, but is effectively limited by + the node's available memory. Bogus beacons prolong the join time of + the pledge, and so the time spent in "minimal" [RFC8180] duty cycle + mode. -13. Privacy Considerations +15. Privacy Considerations - This specification relies on the uniqueness of EUI64 that is - transferred in clear as part of the security context identifier. - (EDNOTE: should we say IID here?) Privacy implications of using such - long-term identifier are discussed in [RFC7721] and comprise - correlation of activities over time, location tracking, address - scanning and device-specific vulnerability exploitation. Since the - join protocol is executed rarely compared to the network lifetime, - long-term threats that arise from using EUI64 are minimal. In - addition, the join response message contains an optional short - address which can be assigned by JRC to the pledge. The short - address is independent of the long-term identifier EUI64 and is - encrypted in the response. For that reason, it is not possible to - correlate the short address with the EUI64 used during the join. Use - of short addresses once the join protocol completes mitigates the - aforementioned privacy risks. In addition, EDHOC may be used for - identity protection during the join protocol by generating a random - context identifier in place of the EUI64 - [I-D.selander-ace-cose-ecdhe]. + This specification relies on the uniqueness of the node's EUI-64 that + is transferred in clear as an OSCORE Context Hint. Privacy + implications of using such long-term identifier are discussed in + [RFC7721] and comprise correlation of activities over time, location + tracking, address scanning and device-specific vulnerability + exploitation. Since the join protocol is executed rarely compared to + the network lifetime, long-term threats that arise from using EUI-64 + are minimal. In addition, the Join Response message contains a short + address which is assigned by JRC to the pledge. The assigned short + address SHOULD be uncorrelated with the long-term EUI-64 identifier. + The short address is encrypted in the response. Use of short + addresses once the join protocol completes mitigates the + aforementioned privacy risks. -14. IANA Considerations +16. IANA Considerations Note to RFC Editor: Please replace all occurrences of "[[this document]]" with the RFC number of this specification. This document allocates a well-known name under the .arpa name space according to the rules given in: [RFC3172]. The name "6tisch.arpa" is requested. No subdomains are expected. No A, AAAA or PTR record is requested. -14.1. CoAP Option Numbers Registry +16.1. CoAP Option Numbers Registry The Stateless-Proxy option is added to the CoAP Option Numbers registry: +--------+-----------------+-------------------+ | Number | Name | Reference | +--------+-----------------+-------------------+ | TBD | Stateless-Proxy | [[this document]] | +--------+-----------------+-------------------+ -15. Acknowledgments +17. Acknowledgments The work on this document has been partially supported by the European Union's H2020 Programme for research, technological development and demonstration under grant agreement No 644852, project ARMOUR. The authors are grateful to Thomas Watteyne and Goeran Selander for - reviewing the draft and to Klaus Hartke for providing input on the - Stateless-Proxy CoAP option. The authors would also like to thank - Francesca Palombini and Ludwig Seitz for participating in the + reviewing, and to Klaus Hartke for providing input on the Stateless- + Proxy CoAP option. The authors would also like to thank Francesca + Palombini, Ludwig Seitz and John Mattsson for participating in the discussions that have helped shape the document. -16. References -16.1. Normative References +18. References + +18.1. Normative References [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, - "Object Security of CoAP (OSCOAP)", draft-ietf-core- - object-security-03 (work in progress), May 2017. - - [I-D.ietf-cose-msg] - Schaad, J., "CBOR Object Signing and Encryption (COSE)", - draft-ietf-cose-msg-24 (work in progress), November 2016. + "Object Security for Constrained RESTful Environments + (OSCORE)", draft-ietf-core-object-security-06 (work in + progress), October 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, - September 2001, . + September 2001, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, - October 2013, . + October 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, - . + . -16.2. Informative References + [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", + RFC 8152, DOI 10.17487/RFC8152, July 2017, + . + +18.2. Informative References [I-D.ietf-6tisch-6top-protocol] Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol - (6P)", draft-ietf-6tisch-6top-protocol-05 (work in - progress), May 2017. - - [I-D.ietf-6tisch-dtsecurity-secure-join] - Richardson, M., "6tisch Secure Join protocol", draft-ietf- - 6tisch-dtsecurity-secure-join-01 (work in progress), - February 2017. - - [I-D.ietf-6tisch-minimal] - Vilajosana, X., Pister, K., and T. Watteyne, "Minimal - 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work - in progress), February 2017. + (6P)", draft-ietf-6tisch-6top-protocol-09 (work in + progress), October 2017. [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE - 802.15.4e", draft-ietf-6tisch-terminology-08 (work in - progress), December 2016. - - [I-D.ietf-anima-bootstrapping-keyinfra] - Pritikin, M., Richardson, M., Behringer, M., Bjarnason, - S., and K. Watsen, "Bootstrapping Remote Secure Key - Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- - keyinfra-06 (work in progress), May 2017. + 802.15.4e", draft-ietf-6tisch-terminology-09 (work in + progress), June 2017. - [I-D.richardson-6tisch-join-enhanced-beacon] - Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational - Element encapsulation of 6tisch Join Information", draft- - richardson-6tisch-join-enhanced-beacon-01 (work in - progress), March 2017. + [I-D.ietf-cbor-cddl] + Birkholz, H., Vigano, C., and C. Bormann, "Concise data + definition language (CDDL): a notational convention to + express CBOR data structures", draft-ietf-cbor-cddl-00 + (work in progress), July 2017. [I-D.richardson-6tisch-minimal-rekey] Richardson, M., "Minimal Security rekeying mechanism for - 6TiSCH", draft-richardson-6tisch-minimal-rekey-01 (work in - progress), February 2017. - - [I-D.selander-ace-cose-ecdhe] - Selander, G., Mattsson, J., and F. Palombini, "Ephemeral - Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- - cose-ecdhe-06 (work in progress), April 2017. + 6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in + progress), August 2017. - [IEEE8021542015] + [IEEE802.15.4-2015] IEEE standard for Information Technology, ., "IEEE Std 802.15.4-2015 Standard for Low-Rate Wireless Personal Area Networks (WPANs)", 2015. [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, - . + . - [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand - Key Derivation Function (HKDF)", RFC 5869, - DOI 10.17487/RFC5869, May 2010, - . + [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, + "Transmission of IPv6 Packets over IEEE 802.15.4 + Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, + . - [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer - Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, - January 2012, . + [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., + Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, + JP., and R. Alexander, "RPL: IPv6 Routing Protocol for + Low-Power and Lossy Networks", RFC 6550, + DOI 10.17487/RFC6550, March 2012, + . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, - . + . [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, - . + . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, - . + . + + [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal + IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) + Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, + May 2017, . Appendix A. Example - Figure 6 illustrates a join protocol exchange in case PSKs are used. - Pledge instantiates the OSCOAP context and derives the traffic keys - and nonces from the PSK. It uses the instantiated context to protect - the CoAP request addressed with Proxy-Scheme option and well-known - host name of JRC in the Uri-Host option. Triggered by the presence - of Proxy-Scheme option, JP forwards the request to the JRC and adds + Figure 3 illustrates a successful join protocol exchange. The pledge + instantiates the OSCORE context and derives the traffic keys and + nonces from the PSK. It uses the instantiated context to protect the + Join Request addressed with a Proxy-Scheme option, the well-known + host name of the JRC in the Uri-Host option, and its EUI-64 + identifier as OSCORE Context Hint. Triggered by the presence of + Proxy-Scheme option, the JP forwards the request to the JRC and adds the Stateless-Proxy option with value set to the internally needed - state, authentication tag, and a freshness indicator. JP learned the - IPv6 address of JRC when it acted as a pledge and joined the network. - Once JRC receives the request, it looks up the correct context based - on the Sender ID (sid) parameter. It reconstructs OSCOAP's external - Additional Authenticated Data (AAD) needed for verification based on: + state, authentication tag, and a freshness indicator. The JP learned + the IPv6 address of JRC when it acted as a pledge and joined the + network. Once the JRC receives the request, it looks up the correct + context based on the Context Hint parameter. It reconstructs + OSCORE's external Additional Authenticated Data (AAD) needed for + verification based on: - o Version field of the received CoAP header. + o the Version of the received CoAP header. - o Code field of the received CoAP header. + o the Algorithm value agreed out-of-band, default being AES-CCM- + 16-64-128 from [RFC8152]. - o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. + o the Request ID being set to the value of the "kid" field of the + received COSE object. - o Request ID being set to pledge's EUI-64 concatenated with 0x00. + o the Join Request sequence number set to the value of "Partial IV" + field of the received COSE object. - o Request Sequence number set to the value of "Partial IV" of the - received COSE object. + o Integrity-protected options received as part of the request. - Replay protection is ensured by OSCOAP and the tracking of sequence - numbers at each side. In the example below, the response contains - sequence number 7 meaning that there have already been some attempts - to join under a given context, not coming from the pledge. Once JP - receives the response, it authenticates the Stateless-Proxy option - before deciding where to forward. JP sets its internal state to that - found in the Stateless-Proxy option. Note that JP does not posses - the key to decrypt the COSE object present in the payload so the - join_response object is opaque to it. The response is matched to the - request and verified for replay protection at pledge using OSCOAP - processing rules. The response does not contain JRC's address as in - this particular example, we assume that JRC is co-located with 6LBR. + Replay protection is ensured by OSCORE and the tracking of sequence + numbers at each side. Once the JP receives the Join Response, it + authenticates the Stateless-Proxy option before deciding where to + forward. The JP sets its internal state to that found in the + Stateless-Proxy option, and forwards the Join Response to the correct + pledge. Note that the JP does not possess the key to decrypt the + COSE object (join_response) present in the payload. The Join + Response is matched to the Join Request and verified for replay + protection at the pledge using OSCORE processing rules. In this + example, the Join Response does not contain the IPv6 address of the + JRC, the pledge hence understands the JRC is co-located with the + 6LBR. - <--E2E OSCOAP--> + <---E2E OSCORE--> Client Proxy Server Pledge JP JRC | | | - +----->| | Code: [0.01] (GET) + +------>| | Code: { 0.02 } (POST) | GET | | Token: 0x8c | | | Proxy-Scheme: [coap] | | | Uri-Host: [6tisch.arpa] - | | | Object-Security: [sid:EUI-64 | 0, seq:1, + | | | Object-Security: [ kid: 0 ] + | | | Payload: Context-Hint: EUI-64 + | | | [ Partial IV: 1, | | | {Uri-Path:"j"}, | | | ] - | | | Payload: - | | | - | +----->| Code: [0.01] (GET) + | +------>| Code: { 0.01 } (GET) | | GET | Token: 0x7b | | | Uri-Host: [6tisch.arpa] - | | | Object-Security: [sid:EUI-64 | 0, seq:1, + | | | Object-Security: [ kid: 0 ] + | | | Stateless-Proxy: opaque state + | | | Payload: Context-Hint: EUI-64 + | | | [ Partial IV: 1, | | | {Uri-Path:"j"}, | | | ] - | | | Stateless-Proxy: opaque state - | | | Payload: - | | | - | |<-----+ Code: [2.05] (Content) + | |<------+ Code: { 2.05 } (Content) | | 2.05 | Token: 0x7b | | | Object-Security: - | | | Stateless-Proxy: opaque state - | | | Payload: [ seq:7, - | | | {join_response}, ] + | | | Payload: [ { join_response }, ] | | | - |<-----+ | Code: [2.05] (Content) + |<------+ | Code: { 2.05 } (Content) | 2.05 | | Token: 0x8c | | | Object-Security: - - | | | Payload: [ seq:7, - | | | {join_response}, ] + | | | Payload: [ { join_response }, ] | | | - Figure 6: Example of a join protocol exchange with a PSK. {} denotes - encryption and authentication, [] denotes authentication. + Figure 3: Example of a successful join protocol exchange. { ... } + denotes encryption and authentication, [ ... ] denotes + authentication. Where join_response is as follows. join_response: [ [ / COSE Key Set array with a single key / { 1 : 4, / key type symmetric / 2 : h'01', / key id / -1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value / @@ -1033,34 +956,34 @@ ] ] Encodes to h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with a size of 30 bytes. Authors' Addresses Malisa Vucinic (editor) - Inria - 2 Rue Simone Iff - Paris 75012 - France + University of Montenegro + Dzordza Vasingtona bb + Podgorica 81000 + Montenegro - Email: malisa.vucinic@inria.fr + Email: malisav@ac.me Jonathan Simon - Linear Technology + Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 USA - Email: jsimon@linear.com + Email: jonathan.simon@analog.com Kris Pister University of California Berkeley 512 Cory Hall Berkeley, CA 94720 USA Email: pister@eecs.berkeley.edu Michael Richardson Sandelman Software Works