6TiSCH Working Group M. Vucinic, Ed. Internet-Draft University of Montenegro Intended status: Standards Track J. Simon Expires:September 6,November 26, 2018 Analog Devices K. Pister University of California Berkeley M. Richardson Sandelman Software WorksMarch 05,May 25, 2018 Minimal Security Framework for 6TiSCHdraft-ietf-6tisch-minimal-security-05draft-ietf-6tisch-minimal-security-06 Abstract This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The framework 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. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material anda short link-layer address.other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines themessage format,Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, a new Stateless-Proxy CoAP option, and configures the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. 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 athttps://datatracker.ietf.org/drafts/current/.http://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 onSeptember 6,November 26, 2018. Copyright Notice Copyright (c) 2018 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(https://trustee.ietf.org/license-info)(http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . .45 4. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 5 5. Join Process Overview . . . . . . . . . . . . . . . . . . . .. . . . 57 5.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . .78 5.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . .79 5.3. Step 3 - Constrained JoinRequest . . . . . . . . . . . . . . .Protocol (CoJP) Execution . . .89 5.4.Step 4 - Join Response . . . . . . . . . .The Special Case of the 6LBR Pledge Joining . . . . . . .810 6. Link-layer Configuration . . . . . . . . . . . . . . . . . .910 7. Network-layer Configuration . . . . . . . . . . . . . . . . .910 7.1. Identification of Join Request Traffic . . . . . . . . .1011 7.2. Identification of Join Response Traffic . . . . . . . . .1112 8. Application-level Configuration . . . . . . . . . . . . . . .1112 8.1. OSCORE Security Context . . . . . . . . . . . . . . . . .1213 9.6TiSCHConstrained Join Protocol (CoJP) . . . . . . . . . . . . . . 15 9.1. Join Exchange . . . . . .13 9.1. Specification of the Join Request. . . . . . . . . . . .14 9.2. Specification of the Join Response. . . . 16 9.2. Parameter Update Exchange . . . . . . .15 9.3. Error Handling and Retransmission. . . . . . . . . 18 9.3. CoJP Objects . . .17 9.4. Rekeying and Rejoining. . . . . . . . . . . . . . . . .18 9.5.. . 19 9.4. Parameters . . . . . . . . . . . . . . . . . . . . . . .18 9.6.27 9.5. Mandatory to Implement Algorithms . . . . . . . . . . . .1828 10. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . . .1928 11. Security Considerations . . . . . . . . . . . . . . . . . . .2029 12. Privacy Considerations . . . . . . . . . . . . . . . . . . .2130 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .2130 13.1. CoAP Option Numbers Registry . . . . . . . . . . . . . .2131 13.2. CoJP Parameters Registry . . . . . . . . . . . . . . . . 31 13.3. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 31 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .2232 15. References . . . . . . . . . . . . . . . . . . . . . . . . .2233 15.1. Normative References . . . . . . . . . . . . . . . . . .2233 15.2. Informative References . . . . . . . . . . . . . . . . .2333 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . .2435 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .2737 1. Introduction This document presumes a 6TiSCH network as described by [RFC7554] and [RFC8180]. 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. 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. This document defines a secure join solution for a new device, called "pledge", to securely join a 6TiSCH network. The specification definesa 6TiSCHthe Constrained Join Protocol(6JP)(CoJP) used by the pledge to request admission into a network managed by the JRC, and for the JRC to configure the pledge with the necessaryparameters,parameters and update them at a later time, a new CoAP option, and configures different layers of the 6TiSCH protocol stack for the join process to occur in a secure manner.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).ThePSKConstrained Join Protocol defined in this document is generic and can be usedto configure OSCORE to provide a secure channel to 6JP. How the PSK is installed is outas-is in modes of IEEE Std 802.15.4 other than TSCH, that 6TiSCH is based on. The Constrained Join Protocol may as well be used in other (low-power) networking technologies where efficiency in terms of communication overhead and code footprint is important. In such a case, it may be necessary to register configuration parameters specific to the technology in question, through the IANA process. The overall join process described in Section 5 and the configuration of the stack is, however, specific to 6TiSCH. The Constrained Join Protocol 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). The PSK is used to configure OSCORE to provide a secure channel to CoJP. How the PSK is installed is out of scope of thisdocument.document: this may happen through the one-touch provisioning process or by a key exchange protocol that may precede the execution of the 6TiSCH Join protocol. 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].[IEEE802.15.4]. 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 keyingmaterial and a shortmaterial, link-layeraddress.short address and other parameters. After this secure join process successfully completes, the joined node can interact with its neighbors to request additional bandwidth using the 6top Protocol [I-D.ietf-6tisch-6top-protocol] and start sending the application traffic. 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 [RFC8152]. The specification also includes a set of informativeexamplesspecifications using theCBOR diagnostic notationConcise data definition language (CDDL) [I-D.ietf-cbor-cddl]. The following terms defined in [I-D.ietf-6tisch-terminology] are used extensively throughout this document: o pledge o joined node o join proxy (JP) o join registrar/coordinator (JRC) o enhanced beacon (EB) o join protocol o join process The following terms defined in [RFC6775] are also used throughout this document: o 6LoWPAN Border Router (6LBR) The term "6LBR" is used interchangeably with the term "DODAG root" defined in [RFC6550], assuming the two entities are co-located, as recommended by [I-D.ietf-6tisch-architecture]. The term "pledge", as used throughout the document, explicitly denotes non-6LBR devices attempting to join over an IEEE Std 802.15.4 network interface. The device that attempts to join as the 6LBR of the network and does so over another network interface is explicitly denoted as the "6LBR pledge". When the text equally applies to the pledge and the 6LBR pledge, the "(6LBR) pledge" form is used. In addition, we use the generic terms "network identifier" and "pledge identifier". See Section 3. 3. Identifiers The "network identifier" uniquely identifies the 6TiSCH network in the namespace managed by a JRC. Typically, this is the 16-bit Personal Area Network Identifier (PAN ID) defined in[IEEE802.15.4-2015].[IEEE802.15.4]. Companion documents can specify the use of a different network identifier for join purposes, but this is out of scope of this specification. Such identifier needs to be carried within Enhanced Beacon (EB) frames. The "pledge identifier" uniquely identifies the (6LBR) pledge in the namespace managed by a JRC. The pledge identifier is typically the globally unique 64-bit Extended Unique Identifier (EUI-64) of the IEEE Std 802.15.4 device. This identifier is used to generate the IPv6 addresses of the (6LBR) pledge and to identify it during the execution of the join protocol. For privacy reasons, it is possible to use an identifier different from the EUI-64 (e.g. a random string). See Section 12. 4. One-Touch Assumption This document assumes a one-touch scenario. The (6LBR) pledge is provisioned with certain parameters before attempting to join the network, and the same parameters are provisioned to the JRC. There are many ways by which this provisioning can be done. Physically, the parameters can be written into the (6LBR) 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. 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 (6LBR) pledge, and that the two devices can exchange the parameters. Parameters that are provisioned to the (6LBR) pledge include: o Pre-Shared Key (PSK). The JRC additionally needs to store theidentifier of thepledge identifier bound to the given PSK. 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 (6LBR) pledge SHOULD be provisioned with a unique PSK. o Optionally, a network identifier. Provisioning the network identifierto the pledgeisRECOMMENDED, as it significantly speeds upRECOMMENDED. However, due to thejoin process. In case this parameter is not provisioned,operational constraints the network identifier may not be known at the time when the provisioning is done. In case this parameter is not provisioned to the pledge, the pledge attempts to join one network at atime.time, which significantly prolongs the join process. In case this parameter is not provisioned to the 6LBR pledge, the 6LBR pledge can receive it from the JRC as part of the join protocol. o Optionally, any non-default algorithms.Mandatory to implement andThe default algorithms are specified in Section9.6.9.5. When algorithm identifiers are not exchanged, the use of these default algorithms is implied. Additionally, the 6LBR pledge that is not co-located with the JRC needs to be provisioned with: o Global IPv6 address of the JRC. This address is used by the 6LBR pledge to address the JRC during the join process. The 6LBR pledge may also obtain the IPv6 address of the JRC through other available mechanisms, such as DHCPv6, GRASP, mDNS, the use of which is out of scope of this document. Pledges do not need to be provisioned with this address as they discover it dynamically during the join process. 5. Join Process Overview This section describes the steps taken by a pledge in a 6TiSCH network. When a pledge seeks admission to a 6TiSCH network, the following exchange occurs: 1. The pledge listens for an Enhanced Beacon (EB) frame[IEEE802.15.4-2015].[IEEE802.15.4]. 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 ofjoin proxyJoin Proxy (JP) for the pledge, and when it can expect to receive a frame. The Enhanced Beacon provides the L2 address of the JP and it may also provide its link-local IPv6 address. 2. The pledge configures its link-local IPv6 address and advertises it to thejoin proxy (JP).JP using Neighbor Discovery. This step may be omitted if the link-local address has been derived from a known unique interface identifier, such as an EUI-64 address. 3. The pledge sends a Join Request to the JP in order to securely identify itself to the network. The Join Request isdirectedforwarded to theJRC, which may be co-located on the JP or another device.JRC. 4. In case of successful processing of the request, the pledge receives ajoin responseJoin Response from the JRC (via theJP) that sets up one or more link-layer keys used to authenticate and encrypt subsequent transmissions to peers, and a short link-layer addressJP). The Join Response contains configuration parameters necessary for thepledge.pledge to join the network. From the pledge's perspective, joining is a local phenomenon - the pledge only interacts with the JP, and it needs 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 join process is shown as a transaction diagram in Figure 1: +--------+ +-------+ +--------+ | pledge | | JP | | JRC | | | | | | | +--------+ +-------+ +--------+ | | | |<---Enhanced Beacon (1)---| | | | | |<-Neighbor Discovery (2)->| | | | | |-----Join Request(3)-----|------Join(3a)----|----Join Request(3a)-->|(3a)---->| \ | | | |6JP |<---JoinCoJP |<----Join Response(4)-----|-----Join(3b)---|----Join Response(4a)---|(3b)----| / | | | Figure 1: Overview of a successful join process.6JPCoJP stands for6TiSCHConstrained Join Protocol. As other nodes in the network, the 6LBR node plays the role of the JP. The 6LBR may in addition be co-located with the JRC. The details of each step are described in the following sections. 5.1. Step 1 - Enhanced Beacon 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],[IEEE802.15.4], and described in [RFC7554]. 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 network identifier 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 network identifier. If the pledge is not provisioned with the network identifier, it attempts to join one network at a time, as described in Section9.3.9.1.3. Once the pledge selects the EB, it synchronizes to it and transitions into a low-power mode. Itdeeply duty cycles its radio, switching the radio on whenfollows the provided schedule which indicates the slotswhichthat 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. At this point, the pledge may proceed to step 2, or continue to listen for additional EBs. 5.2. Step 2 - Neighbor Discovery The pledge forms its link-local IPv6 address based on the interface identifier, as per [RFC4944]. The pledge MAY perform the Neighbor Solicitation / Neighbor Advertisement exchange with the JP, as per Section 5.5.1 of [RFC6775]. The pledge and the JP use their link- local IPv6 addresses for all subsequent communication during the join process. Note that Neighbor Discovery 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 6. 5.3. Step 3 - Constrained Join Protocol (CoJP) Execution The pledge triggers the join exchange of the Constrained Join Protocol (CoJP). The join exchange consists of two messages: the Join Request message (Step 3a), and the Join Response message conditioned on the successful security processing of the request (Step 3b). All CoJP messages are exchanged over a secure channel that provides confidentiality, data authenticity and replay protection. 5.3.1. Step 3a - Join Request The Join Request is a message sent from the pledge to the JP, and which the JP forwards to the JRC. The pledge indicates in the Join Request the role it requests to play in the network as well as the identifier of the network it requests to join. 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 AEAD (Authenticated Encryption with Associated Data) algorithm from [RFC8152] and a key derived from the PSK, the pledge identifier and a request-specific constant value. Algorithms which MUST be implemented are specified in Section 9.6. The nonce used when securing the Join Request is derived from the PSK, the pledge identifier and a monotonically increasing counter initialized to 0 when first starting. Join Request message is specified in Section 9.1, while the details on security processing can be found in Section 7 of [I-D.ietf-core-object-security]. 5.4.5.3.2. Step43b - Join Response The Join Response is sent by the JRC to the pledge, and is forwarded through theJP as it serves as a stateless relay.JP. 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. The JP operates as theapplication-layerapplication- layer proxy, and does not keep any state torelayforward the message.It uses information sent in the clear within the Join Response to decide where to forward to.The Join Responseis authenticated/encrypted end-to-end using an AEAD algorithm from [RFC8152]. The key used to protect the response iscontains differentfromparameters needed by theone usedpledge toprotect the request (both are derived from the PSK, as explained in Section 8.1). The response is protected using the same nonce as inbecome a fully operational network node. For example, these parameters are therequest. The Join Response contains one or morelink-layer key(s)that the pledge willcurrently in usefor subsequent communication. Each key that is provided byin the network, theJRC is associated with an 802.15.4 key identifier. In other link-layer technologies, a different identifier may be substituted. The Join Response also contains an IEEE 802.15.4short link-layer address[IEEE802.15.4-2015]assignedby the JRCto the pledge,and optionallythe IPv6 address of theJRC. Join Response message is specified inJRC needed by the pledge to operate as the JP, and others. 5.4. The Special Case of the 6LBR Pledge Joining The 6LBR pledge performs Section9.2, while5.3 of thedetails on security processing can be foundjoin process described above, just as any other pledge, albeit over another network interface. There is no JP intermediating the communication between the 6LBR pledge and the JRC, as described in Section77. The other steps of[I-D.ietf-core-object-security].the described join process do not apply to the 6LBR pledge. How the 6LBR pledge obtains an IPv6 address and triggers the execution of the CoJP protocol is out of scope of this document. 6. Link-layer Configuration In an operational 6TiSCH network, all frames MUST use link-layer frame security [RFC8180]. The IEEE Std 802.15.4 security attributes MUST include frame authenticity, and MAY include frame confidentiality (i.e. encryption).As specified in [RFC8180], the network uses a key termed as K1 to authenticate EBs and a key termed as K2 to authenticate and optionally encrypt DATA and ACKNOWLEDGMENT frames. The keys K1 and K2 MAY be the same key (same value and IEEE 802.15.4 index). How the JRC communicates these keys to 6LBR is out of scope of this specification.The pledge does not initially do any authenticity check of the EB frames, as it does notknowpossess theK1 key.link-layer key(s) in use. The pledge is still able to parse the contents of the received EBs and synchronize to the network, as EBs are not encrypted [RFC8180]. When sending frames during the join process, the pledge sends unencrypted and unauthenticated frames. The JP accepts these unsecured frames(using the "exempt mode" in 802.15.4)for the duration of the join process. This behavior may be implemented by setting the "secExempt" attribute in the IEEE Std 802.15.4 security configuration tables. 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 the pledge, an attacker may craft a frame that appears to be a valid EB, since the pledge can neitherknowverify theASN a priorifreshness nor verify the address of the JP. This opens up a possibility of DoS attack, as discussed in Section 11.Beacon authentication keys are discussed in [RFC8180].7. Network-layer Configuration 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 DoSattack. How theattack, as the attacker may fill JP's neighbor table and prevent the discovery of legitimate neighbors. How the pledge and the 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. The pledge does not communicate with the JRC at the network layer. This allows the pledge to join without knowing the IPv6 address of the JRC. Instead, the pledge communicates with the JP at the networklayer,layer using link-local addressing, and with the JRC at the application layer, as specified in Section 8. The JP communicates with the JRC over global IPv6 addresses. The JP discovers the network IPv6 prefix and configures its global IPv6 address upon successful completion of the join process and the obtention of link-layer keys. The pledge learns the actual IPv6 address of the JRC from the Join Response, as specified in Section9.2;9.1.2; it uses it once joined in order to operate as a JP. As a special case, the 6LBR pledge is expected to have an additional network interface that it uses in order to obtain the configuration parameters from the JRC and start advertising the 6TiSCH network. This additional interface needs to be configured with a global IPv6 address, by a mechanism that is out of scope of this document. The 6LBR pledge uses this interface to directly communicate with the JRC using global IPv6 addressing. The JRC can be co-located on the 6LBR. In this special case, the IPv6 address of the JRC can be omitted from the Join Response message for space optimization. The 6LBR then MUST set the DODAGID field in the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the address of the JRC once joined and upon the reception ofathe first RPL DIO message, and uses it to operate as a JP.Before the 6TiSCH network is started, the 6LBR MUST be provisioned with the IPv6 address of the JRC.7.1. Identification of Join Request Traffic The join request traffic that is proxied by the Join Proxy (JP) comes from unauthenticated nodes, and there may be an arbitrary amount of it. In particular, an attacker may send fraudulent traffic in attempt to overwhelm the network. When operating as part of a [RFC8180] 6TiSCH minimal network usingreasonabledistributed scheduling algorithms, the join request traffic present may cause intermediate nodes to request additional bandwidth. An attacker could use this property to cause the network to overcommit bandwidth (and energy) to the join process. The Join Proxy is aware of what traffic is join request traffic, and so can avoid allocating additional bandwidth itself. The Join Proxy SHOULD implement a bandwidth cap on outgoing join request traffic. This cap will not protect intermediate nodes as they can not tell join request traffic from regular traffic. Despite the bandwidth cap implemented separately on each Join Proxy, the aggregate join request traffic from many Join Proxies may cause intermediate nodes to decide to allocate additional cells. It is undesirable totodo so in response to the join request traffic. In order to permit the intermediate nodes to avoid this, the traffic needs to betagged in some way.tagged. [RFC2597] defines a set of per-hop behaviors that may be encoded into the Diffserv Code Points (DSCPs). The Join Proxy SHOULD set the DSCP of join request packets that it produces as part of the relay process to AF43 code point (See Section 6 of [RFC2597]). A Join Proxy that does not set the DSCP on traffic forwarded should set it to zero so that it is compressed out. A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT allocate additional cells as a result of traffic with code point AF43. Companion SF documents SHOULD specify how this recommended behavior is achieved. 7.2. Identification of Join Response Traffic The JRC SHOULD set the DSCP of join response packets addressed to the Join Proxy to AF42 code point. Join response traffic can not be induced by an attacker as it is generated only in response to legitimate pledges (see Section9.3).9.1.3). AF42 has lower drop probability than AF43, giving join response traffic priority in buffers over join request traffic.When the JRC is not co-located with the 6LBR, then the code point provides a clear indication to the 6LBR that this is join response traffic.Due to the convergecast nature of the DODAG, the 6LBR links are often the most congested, and from that point down there is progressively less (or equal) congestion. If the 6LBR paces itself when sending join response traffic then it ought to never exceed the bandwidth allocated to the best effort traffic cells. If the 6LBR has the capacity (if it is not constrained) then it should provide some buffers in order to satisfy the Assured Forwarding behavior. Companion SF documents SHOULD specify how traffic with code point AF42 is handled with respect to cell allocation. 8. Application-level Configuration TheJoin Request/Join ResponseCoJP join exchange in Figure 1 is carried over CoAP [RFC7252] andsecured usingthe secure channel provided by OSCORE [I-D.ietf-core-object-security]. The (6LBR) 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. 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. Rather, the JP processes forwarding-related CoAP options and makes requests on behalf of the pledge, in a stateless manner by using theStateless- ProxyStateless-Proxy option defined in this document. The pledge designates a JP as a proxy by including the Proxy-Scheme option in CoAP requests it sends to the JP. The pledge also includes in the requests the Uri-Host option with its value set to the well- known JRC's alias, as specified in Section9.1.9.1.1. The JP resolves the alias to the IPv6 address of the JRC that it learned when it acted as a pledge, and joined the network. This allows the JP to reach the JRC at the network layer and forward the requests on behalf of the pledge. The JP MUST add a Stateless-Proxy option to all the requests that it forwards on behalf of the pledge as part of the join process. The value of the Stateless-Proxy option is set to the internal JP state, needed to forward the Join Response message to the pledge. The Stateless-Proxy option handling is defined in Section 10. The JP also tags all packets carrying the Join Request message at the network layer, as specified in Section 7.1. 8.1. OSCORE Security Context Before the (6LBR) pledge and the JRC may start exchanging CoAP messages protected with OSCORE, they need to derive the OSCORE security context from the parameters provisioned out-of-band, as discussed in Section 4. The OSCORE security context MUST be derivedat the pledge and the JRCas per Section 3 of [I-D.ietf-core-object-security]. o the Master Secret MUST be the PSK. o the Master Salt MUST bethe pledge identifier.empty. o theSenderID of the pledge MUST be set to the byte string 0x00. This identifier is used as the OSCORE Sender ID in the security context derivation, as the pledge initially plays the role of a CoAP client. o theRecipientID(IDof theJRC)JRC MUST be set to the byte string0x01.0x4a5243 ("JRC" in ASCII). This identifier is used as the OSCORE Recipient ID in the security context derivation, as the JRC initially plays the role of a CoAP server. o the ID Context MUST be set to the pledge identifier. 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. o the Key Derivation Function MUST be agreed out-of-band. Default is HKDF SHA-256 [RFC5869]. 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]. Implementations MUST ensure that multiple CoAP requests to different JRCs result in the use of the same OSCORE context, so that the sequence numbers are properly incremented for each request. The pledge typically sends requests to different JRCs if it is not provisioned with the network identifier and attempts to join one network at a time. A simple implementation technique is to instantiate the OSCORE security context with a given PSK only once and use it for all subsequent requests. Failure to comply will break the confidentiality property of theAEADAuthenticated Encryption with Associated Data (AEAD) algorithm due to the nonce reuse.8.1.1. PersistencyThis OSCORE security context is used for initial joining of the (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well as for any later parameter updates, where the JRC acts as a CoAP client and the joined node as a CoAP server, as discussed in Section 9.2. A (6LBR) pledge is expected to have exactly one OSCORE security context with the JRC. 8.1.1. Persistency 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. This is an important security requirement in order to guarantee nonce uniqueness and resistance to replay attacks across reboots and rejoins. Traffic between the (6LBR) pledge and the JRC is rare, making security outweigh the cost of writing to persistent memory. 9.6TiSCHConstrained Join Protocol6TiSCH(CoJP) Constrained Join Protocol(6JP)(CoJP) is a lightweight protocol over CoAP [RFC7252] and a secure channel provided by OSCORE [I-D.ietf-core-object-security].6JPCoJP allows the (6LBR) pledge to request admission into a network managed by the JRC, and for the JRC to configure the pledge with the parameters necessary for joining thenetwork. These parameters are: link-layer keysnetwork, or advertising it inuse, IEEE 802.15.4 short address assigned to the pledge, andtheIPv6 addresscase of 6LBR pledge. The JRC may update theJRC.parameters at any time, by reaching out to the joined node that formerly acted as a (6LBR) pledge. For example, network-wide rekeying can be implemented by updating the keying material on each node. This section specifies how the6JP bindingsCoJP messages are mapped to CoAP and OSCORE,6JP message formatsCBOR data structures carrying different parameters, transported within CoAP payload, and the parameter semanticsof different fields. 6JPand processing rules. CoJP relies on the security properties provided by OSCORE. This includes end-to-end confidentiality, data authenticity, replay protection, and a secure binding of responses to requests. +-----------------------------------+ |6TiSCHConstrained Join Protocol(6JP)(CoJP) | +-----------------------------------+ +-----------------------------------+ \ | Requests / Responses | | |-----------------------------------| | | OSCORE | | CoAP |-----------------------------------| | | Messaging Layer / Message Framing | | +-----------------------------------+ / +-----------------------------------+ | UDP | +-----------------------------------+ Figure 2: Abstract layering of6JP. 6JPCoJP. When a (6LBR) pledge requests admission to a given network, it undergoes the CoJP join exchange that consistsof two messages:of: o the Join Request message, sent by the (6LBR) pledge to the JRC, potentially proxied by the JP. The Join Request message and its mapping to CoAP is specified in Section9.1.9.1.1. o the Join Response message, sent by the JRC to the (6LBR) pledge if the JRC successfully processes the Join Request using OSCORE and it determines through a mechanism that is out of scope of this specification that the (6LBR) pledge is authorized to join the network. The Join Response message is potentially proxied by the JP. The Join Response message and its mapping to CoAP is specified in Section9.2. The payload of 6JP messages is encoded with CBOR [RFC7049], with some parameters being optional. The first byte of the CBOR-encoded byte string contains9.1.2. When theCBOR major type and additional information (e.g.JRC needs to update thenumber of elements in an array). In caseparameters ofan array, the CBOR decoder decides based on this additional information ifacertain optionaljoined node that formerly acted as a (6LBR) pledge, it executes the CoJP parameteris present or not. 9.1. Specification ofupdate exchange that consists of: o theJoin Request The Join RequestParameter Update message, sent by thepledge sends SHALL be mappedJRC to the joined node that formerly acted as aCoAP request: o(6LBR) pledge. TherequestParameter Update message and its mapping to CoAP is specified in Section 9.2.1. o the Parameter Update Response message, sent by the joined node to the JRC in response to the Parameter Update message to signal successful reception of the updated parameters. The Parameter Update Response message and its mapping to CoAP is specified in Section 9.2.2. The payload of CoJP messages is encoded with CBOR [RFC7049]. The CBOR data structures that may appear as the payload of different CoJP messages are specified in Section 9.3. 9.1. Join Exchange This section specifies the messages exchanged when the (6LBR) pledge requests admission and configuration parameters from the JRC. 9.1.1. Join Request Message The Join Request message SHALL be mapped to a CoAP request: o The request method is POST. 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". This is an anycast type of identifier of the JRC that is resolved to its IPv6 address by the JP or the 6LBR pledge. 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]. The OSCORE security context used is the one derived in Section 8.1. The OSCOREContext Hint SHALL bekid context is set to the ID context, which in turn is set to the pledge identifier. The OSCOREContext Hintkid context allows the JRC to retrieve the security context for a given pledge. o The payload is a Join_Request CBORarray [RFC7049] containing,object, as defined inorder: * Byte string, containing the identifier of the network that the pledge is attempting to join. This enables the JRC to manage multiple 6TiSCH networks. request_payload = [ network_identifier : bstr, ] 9.2. Specification of theSection 9.3.1. 9.1.2. Join Response Message The Join Response message that the JRC sends SHALL be mapped to a CoAP response: o The response Code is 2.04 (Changed). o The payload is a Configuration CBORarray [RFC7049] containing, in order: * 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 describedobject, as defined in Section9.2.1. *9.3.2. 9.1.3. Error Handling and Retransmission Since thelink-layer short addressJoin Request is mapped tobe used bya Non-confirmable CoAP message, OSCORE processing at thepledge. The format ofJRC will silently drop theshort address follows Section 9.2.2. * optionally, the IPv6 addressrequest in case ofthe JRC, encoded asabyte string, with the lengthfailure. This may happen for a number of16 bytes. If the IPv6 addressreasons, including failed lookup of an appropriate security context (e.g. theJRC is not presentpledge attempting to join a wrong network), failed decryption, positive replay window lookup, formatting errors (possibly due to malicious alterations in transit). Silently dropping the JoinResponse, this indicatesRequest at the JRCis co-located withprevents a DoS attack where an attacker could force the6LBR, and haspledge to attempt joining one network at a time, until all networks have been tried. Using a Non-confirmable CoAP message to transport thesame IPv6 address asJoin Request also helps minimize the6LBR. See Section 7. response_payload = [ COSE_KeySet, short_address, ? JRC_address : bstr, ] 9.2.1. Link-layer Keys Transported inrequired CoAP state at theCOSE Key Set Each key inpledge and theCOSE Key Set [RFC8152] SHALL beJoin Proxy, keeping it to asymmetric key. The first key in the COSE Key Set SHALL be usedminimum typically needed to perform CoAP congestion control. It does, however, introduce some complexity as theK1 key from [RFC8180].pledge needs to implement a retransmission mechanism. Thesecond key in the COSE Key Set SHALL be used as the K2 key from [RFC8180]. In the case wherefollowing binary exponential back-off algorithm is inspired by thenetwork usesone described in [RFC7252]. For each Join Request thesame keypledge sends while waiting forK1 and K2, the COSE Key Set SHALL carryasingle key. If the COSE Key Set carries more than 2 keys, the implementation SHOULD considerJoin Response, theresponse as malformed. If the "kid" parameterpledge MUST keep track of a timeout and a retransmission counter. For a new Join Request, theCOSE Key structuretimeout ispresent, the corresponding key SHALL be used as IEEE 802.15.4 KeyIdMode 0x01 (index). In that case, parameter "kid" of the COSE Key structure SHALL be usedset tocarry the IEEE 802.15.4 KeyIndex value. Ifa random value between TIMEOUT_BASE and (TIMEOUT_BASE * TIMEOUT_RANDOM_FACTOR). The retransmission counter is set to 0. When thelength oftimeout is triggered and the"kid" parameterretransmission counter ismoreless than1 byte (length defined by [IEEE802.15.4-2015]),MAX_RETRANSMIT, theimplementation SHOULD considerJoin Request is retransmitted, theresponse as malformed. Ifretransmission counter is incremented, and the"kid" parametertimeout isnot presentdoubled. Note that the retransmitted Join Request passes new OSCORE processing, such that the sequence number in thetransported key,OSCORE context is properly incremented. If theimplementation SHALL considerretransmission counter reaches MAX_RETRANSMIT on a timeout, thekeypledge SHOULD attempt tobe an IEEE 802.15.4 KeyIdMode 0x00 (implicit) key. This document does not support IEEE 802.15.4 KeyIdMode 0x02 and 0x03 class keys. Injoin thecasenext advertised 6TiSCH network. If the pledge receives a Join Response that successfully passes OSCORE processing, it cancels the pending timeout and processes the response. The pledge MUST silently discard any responseis considered malformed,not protected with OSCORE, including error codes. For default values of retransmission parameters, see Section 9.4. If all join attempts to advertised networks have failed, theimplementationpledge SHOULDindicatesignal to the userthrough an out-of-band mechanismthe presence of an errorcondition. 9.2.2. Short Address The "short_address" structure transportedcondition, through some out-of-band mechanism. 9.2. Parameter Update Exchange During the network lifetime, parameters returned as part of thejoin response payload represents the IEEE 802.15.4 short address assignedJoin Response may need tothe pledge. Itbe updated. One typical example isencoded as a CBOR array object, containing, in order: o Byte string, containing the 16-bit address. o Optionally,thelease time parameter, "lease_asn". The valueupdate of link-layer keying material for the"lease_asn" parameter is the 5-byte Absolute Slot Number (ASN) corresponding to its expiration, carriednetwork, a process known as rekeying. This section specifies abyte string in network byte order. short_address = [ address : bstr, ? lease_asn : bstr, ] Itgeneric mechanism when this parameter update isup toinitiated by thejoined node to request a new short address beforeJRC. At theexpirytime ofits previous address. The mechanism by whichthenode requests renewal isjoin, thesame as during join procedure,(6LBR) pledge acts asdescribed in Section 9.4. 9.3. Error Handlinga CoAP client andRetransmission Sincerequests theJoin Request is mapped tonetwork parameters through aNon-confirmable CoAP message, OSCORE processing atrepresentation of theJRC will silently drop"/j" resource, exposed by therequest in case of a failure. This may happenJRC. In order fora number of reasons, including failed lookupthe update ofan appropriate security context (e.g.these parameters to happen, thepledge attemptingJRC needs tojoin a wrong network), failed decryption, positive replay window lookup, formatting errors (possiblyasynchronously contact the joined node. The use of the CoAP Observe option for this purpose is not feasible due tomalicious alterations in transit). Silently droppingtheJoin Request atchange in theJRC prevents a DoS attack where an attacker could forceIPv6 address when the pledgeto attempt joining one network at a time, until all networks have been tried. Using a Non-confirmable CoAP message to transport the Join Request also helps minimizebecomes therequired CoAP state atjoined node and obtains a global address. Instead, once the (6LBR) pledge receives and successfully validates the JoinProxy, keeping it toResponse and so becomes aminimum typically needed to performjoined node, it switches its CoAPcongestion control. It does, however, introduce some complexity as the pledge needs to implementrole and becomes aretransmission mechanism.server. Thefollowing binary exponential back-off algorithmjoined node exposes the "/j" resource that isinspiredused by theone described in [RFC7252]. For each Join RequestJRC to update thepledge sends while waiting for a Join Response,parameters. Consequently, thepledge MUST keep track of a timeout and a retransmission counter. ForJRC operates as anew Join Request,CoAP client when updating thetimeout is set to a random valueparameters. The request/response exchange betweenTIMEOUT_BASE and (TIMEOUT_BASE * 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,theretransmission counter is incremented,JRC and thetimeout is doubled. Note that(6LBR) pledge happens over theretransmitted Join Request passes newalready-established OSCOREprocessing, suchsecure channel. 9.2.1. Parameter Update Message The Parameter Update message that thesequence number inJRC sends to the joined node SHALL be mapped to a CoAP request: o The request method is POST. o The type is Confirmable (CON). 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]. The OSCORE security context used isproperly incremented. Iftheretransmission counter reaches MAX_RETRANSMIT onone derived in Section 8.1. When atimeout,joined node receives a request with thepledge SHOULD attemptSender ID set tojoin the next advertised 6TiSCH network. If0x4a5243 (ID of thepledge receives a Join Response that successfully passes OSCORE processing,JRC), itcancelsis able to correctly retrieve thepending timeout and processessecurity context with theresponse.JRC. o Thepledge MUST silently discard any response not protected with OSCORE, including error codes. For default values of retransmission parameters, seepayload is a Configuration CBOR object, as defined in Section9.5. If all join attempts to advertised networks have failed, the pledge SHOULD signal to the user9.3.2. The JRC has implicit knowledge on thepresence of an error condition, through some out-of-band mechanism. 9.4. Rekeying and Rejoining This specification handles initial keyingglobal IPv6 address of thepledge. For reasons suchjoined node, asrejoining after a long sleep, expiry ofit knows theshort address, or node-initiated rekeying,pledge identifier that the joined nodeMAY sendused when it acted as anew Join Request usingpledge, and thealready-established OSCORE security context.IPv6 network prefix. The JRCthen responds with up-to-date keys and a (possibly new) short address. Howuses this implicitly derived IPv6 address of the joined nodedecides whentorekey is out of scope of this document. Mechanisms for rekeying the network are defined in companion specifications. 9.5. Parameters 6JP uses the following parameters: +-----------------------+----------------+ | Name | Default Value | +-----------------------+----------------+ | TIMEOUT_BASE | 10 s | +-----------------------+----------------+ | TIMEOUT_RANDOM_FACTOR | 1.5 | +-----------------------+----------------+ | MAX_RETRANSMIT | 4 | +----------------------------------------+ The values of TIMEOUT_BASE, TIMEOUT_RANDOM_FACTOR, MAX_RETRANSMIT may be configureddirectly address CoAP messages tovalues specificit. 9.2.2. Parameter Update Response Message The Parameter Update Response message that the joined node sends to thedeployment. The default values have been chosenJRC SHALL be mapped toaccommodateawide range of deployments, taking into account dense networks. 9.6. Mandatory to Implement AlgorithmsCoAP response: o Themandatory to implement AEAD algorithm for use with OSCOREresponse Code isAES- CCM-16-64-128 from [RFC8152]. This2.04 (Changed). o The payload is empty. 9.3. CoJP Objects This section specifies thealgorithm 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, andstructure of CoJP CBOR objects that may be carried as thealgorithm uses 13-byte long nonces.payload of CoJP messages. Some of these objects may be received both as part of the CoJP join exchange when the device operates as a (CoJP) pledge, or the parameter update exchange, when the device operates as a joined (6LBR) node. 9.3.1. Join Request Object Themandatory to implement hash algorithmJoin_Request structure isSHA-256 [RFC4231].built on a CBOR map object. Themandatory to implement key derivation function is HKDF [RFC5869], instantiated withset of parameters that can appear in aSHA-256 hash. 10. Stateless-Proxy CoAP OptionJoin_Request object is summarized below. TheCoAP proxydefined labels can be found below, the details of this registry are in[RFC7252] keeps per-client state information in order to forwardsection "CoJP Parameters" registry Section 13.2. o role: The identifier of theresponse towardsrole that theoriginator ofpledge requests to play in therequest.network once it joins, encoded as an unsigned integer. Possible values are specified in Table 1. Thisstate information includes at leastparameter MAY be included. In case theCoAP token,parameter is omitted, theIPv6 addressdefault value of 0, i.e. thehost, and the UDP source port number. If the JP used the stateful CoAP proxy defined in [RFC7252], it wouldrole "6TiSCH Node", MUST beprone to Denial-of-Service (DoS) attacks, due to its limited memory.assumed. o network identifier: TheStateless-Proxy CoAP option Figure 3 allowsidentifier of theJP to be entirely stateless.network, as discussed in Section 3, encoded as a CBOR byte string. Thisoption inserts,parameter may appear both in therequest,Join Request and in thestate information needed for relayingJoin Response. When present in theresponse backJoin Request, it hints to theclient. The proxy still keeps some general state (e.g. for congestion control or request retransmission), but no per-client state. The Stateless-Proxy CoAP optionJRC the network that the pledge iscritical, Safe-to-Forward, not partrequesting to join, enabling the JRC to manage multiple networks. The pledge obtains the value of thecache key, not repeatable and opaque. When processed by OSCORE,network identifier from theStateless-Proxy optionreceived EB frames. This parameter MUST be included in a Join_Request object if the role parameter isneither encrypted nor integrity protected. +-----+---+---+---+---+-----------------+--------+--------+set to "6TiSCH Node". This parameter MAY be included if the role parameter is set to "6LBR". The inclusion of this parameter by the 6LBR pledge depends on whether the parameter was exchanged during the one-touch process, which in turn depends on the operational constraints. The CDDL fragment that represents the text above for the Join_Request follows. Join_Request = { ? 1 : uint ; role ? 5 : bstr ; network identifier } +--------+-------+-------------------------------------+------------+ |No.Name |CValue |UDescription |NReference |R+--------+-------+-------------------------------------+------------+ |Name6TiSCH |Format0 |LengthThe pledge requests to play the |+-----+---+---+---+---+-----------------+--------+--------|[[this |TBD|xNode | |xrole of a regular 6TiSCH node, i.e. | document]] |Stateless-Proxy|opaque|1-255|+-----+---+---+---+---+-----------------+--------+--------+ C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable Figure 3: Stateless-Proxy CoAP Option Upon receptionnon-6LBR node. | | | | | | | | 6LBR | 1 | The pledge requests to play the | [[this | | | | role of 6LoWPAN Border Router | document]] | | | | (6LBR). | | +--------+-------+-------------------------------------+------------+ Table 1: Role values. 9.3.2. Configuration Object The Configuration structure is built on aStateless-Proxy option, the CoAP server MUST echo it in the response.CBOR map object. Thevalueset ofthe Stateless-Proxy option is internal proxy stateparameters that can appear in a Configuration object isopaque to the server. Example state information includessummarized below. The defined labels can be found below, theIPv6 addressdetails ofthe 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.this registry are in section "CoJP Key Usage Registry" Section 13.3. o link-layer key set: An array encompassing asequence number or timestamp)set of cryptographic keys andMAY be encrypted. The proxy maytheir identifiers that are currently in usean appropriate COSE structure [RFC8152] to wrapin thestate information asnetwork, or that are scheduled to be used in thevaluefuture. The encoding ofthe Stateless-Proxy option.individual keys is described in Section 9.3.2.1. The link-layer keyused for encryption/authentication of the state information mayset parameter MAY beknown only toincluded in a Configuration object. When present, theproxy. Oncelink-layer key set parameter MUST contain at least one key. How theproxy has receivedkeys are installed and used differs for theCoAP response with a Stateless-Proxy option present,6LBR and other nodes. When 6LBR receives this parameter, itdecrypts/authenticates it, checksMUST remove any old keys it has installed from thefreshness indicatorprevious key set andconstructsimmediately install and start using theresponsenew keys for all outgoing and incoming traffic. When a non-6LBR node receives this parameter, it MUST install theclient, based onkeys, use them for any incoming traffic matching theinformation present inkey identifier, but keep using theoption value. Note thatold keys for all outgoing traffic. A non-6LBR node accepts any frames for which it has keys: both old and new keys. Upon reception and successful security processing of aCoAP proxy usinglink-layer frame secured with a key from theStateless-Proxy option is not able to returnnew key set, a5.04 Gateway Timeout Response Code in casenon-6LBR node MUST remove any old keys it has installed from therequest to the server times out. Likewise, if the response toprevious key set. From that moment on, a non-6LBR node MUST use theproxy's request does not containkeys from theStateless-Proxy option,new key set forexampleall outgoing traffic. In the case when theoptionpledge isnot supported byjoining for theserver,first time, before sending theproxy is not able to returnfirst outgoing frame secured with a received key, theresponsepledge needs to successfully complete theclient. 11. Security Considerations This document recommends thatsecurity processing of an incoming frame. To do so, the pledgeand JRC are provisioned with unique PSKs. The noncecan wait to receive a new frame or it can also store an EB frame that it usedfor the Join Request and the Join Response isto find thesame, 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 pledgeJP and0x01use it forJRC). Note that the addressimmediate security processing upon reception of theJRC does not take part in nonce orkeyconstruction. Even inset. The described mechanism permits thecase of a misconfiguration in whichJRC to provision thesame PSK is used for several pledges,new key set to all thekeys usednodes while the network continues toprotectuse therequests/responses from/towards different pledges are different, as they are derived usingexisting keys. When thepledge identifier as Master Salt. The PSKJRC isstill important for mutual authentication ofcertain that all (or enough) nodes have been provisioned with thepledge andnew keys, then theJRC. Should an attacker come to knowJRC updates thePSK, 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, the JP blindly forwards6LBR. In thejoin traffic intospecial case when thenetwork. A simple bandwidth cap onJRC is co-located with theJP prevents6LBR, itfrom forwarding more traffic than the networkcanhandle. This forces attackers to use more than one Join Proxy if they wish to overwhelm the network. Markingsimply trigger thejoin traffic packetssending of a new broadcast frame (e.g. EB), secured with anon-zero DSCP allowskey from thenetwork to carrynew key set. The frame goes out with thetraffic if it has capacity, but encouragesnew key, and upon reception and successful security processing of thenetworknew frame all receiving nodes will switch todroptheextranew active keys. Outgoing trafficrather than add bandwidth due to that traffic. The shared nature of the "minimal" cell used forfrom those nodes will then use thejoin traffic makesnew key, which causes an update of additional peers, and the networkpronewill switch over in a flood-fill fashion. o link-layer short address: IEEE Std 802.15.4 short address assigned toDoS attacks by congestingtheJP with bogus traffic. Such an attackerpledge. The short address structure islimited by its maximum transmit power.described in Section 9.3.2.2. Theredundancylink-layer short address parameter MAY be included inthe number of deployed JPs alleviates the issue and also gives the pledgeapossibility to use the best available link for joining. HowConfiguration object. When anetworknodedecides to become a JP is out of scope ofreceives thisspecification. At the beginningparameter as part of thejoin process,Parameter Update message, it MUST update its link-layer short address to thepledgeone received. o JRC address: the IPv6 address of the JRC, encoded as a byte string, with the length of 16 bytes. If the length of the byte string is different than 16, the parameter MUST be discarded. If the JRC is not co-located with the 6LBR and has a different IPv6 address than the 6LBR, this parameter MUST be included. In the special case where the JRC is co-located with the 6LBR and has the same IPv6 address as the 6LBR, this parameter MAY be included. If the JRC address parameter is not present in the Join Response, this indicates that the JRC has the same IPv6 address as the 6LBR. The joined node can then discover the IPv6 address of the JRC through network control traffic. See Section 7. o network identifier: the identifier of the network, as discussed in Section 3, encoded as a byte string. When present in the Join Response, this parameter is only valid when received by the 6LBR pledge. The parameter indicates to the 6LBR the value of the network identifier it should advertise at the link layer. This parameter MUST NOT be included in the Join Response if the role parameter from the corresponding Join Request indicated 0, i.e. the role "6TiSCH Node". In the case where the corresponding Join_Request object does not contain the network identifier parameter, this parameter MUST be included. When the corresponding Join_Request object does contain the network identifier parameter, this parameter MAY be included in the Configuration object. This may happen if the JRC decides to overwrite the network identifier provisioned during the one-touch process. The value of the network identifier parameter from the Configuration object SHOULD take precedence over the value provisioned during the one-touch process. o network prefix: the IPv6 network prefix, encoded as a byte string. The length of the byte string determines the prefix length. This parameter is only valid when received by the 6LBR pledge. The parameter indicates to the 6LBR the value of the IPv6 network prefix. This parameter MAY be included in the Join Response if the role parameter from the corresponding Join_Request object indicated 1, i.e. the role "6LBR". This parameter MUST NOT be included in the Join Response if the role parameter from the corresponding Join_Request object indicated 0, i.e. the role "6TiSCH Node". The CDDL fragment that represents the text above for the Configuration follows. Structures Link_Layer_Key and Short_Address are specified in Section 9.3.2.1 and Section 9.3.2.2. Configuration = { ? 2 : [ +Link_Layer_Key ], ; link-layer key set ? 3 : Short_Address, ; link-layer short address ? 4 : bstr ; JRC address ? 5 : bstr ; network identifier ? 6 : bstr ; network prefix } +------------+-------+----------+----------------------+------------+ | Name | Label | CBOR | Description | Reference | | | | type | | | +------------+-------+----------+----------------------+------------+ | role | 1 | unsigned | Identifies the role | [[this | | | | integer | parameter. | document]] | | | | | | | | link-layer | 2 | array | Identifies the array | [[this | | key set | | | carrying one or more | document]] | | | | | link-level | | | | | | cryptographic keys. | | | | | | | | | link-layer | 3 | array | Identifies the | [[this | | short | | | assigned link-layer | document]] | | address | | | short address | | | | | | | | | JRC | 4 | byte | Identifies the IPv6 | [[this | | address | | string | address of the JRC | document]] | | | | | | | | network | 5 | byte | Identifies the | [[this | | identifier | | string | network identifier | document]] | | | | | parameter | | | | | | | | | network | 6 | byte | Identifies the IPv6 | [[this | | prefix | | string | prefix of the | document]] | | | | | network | | +------------+-------+----------+----------------------+------------+ Table 2: Join Response map labels. 9.3.2.1. Link-Layer Key The Link_Layer_Key structure encompasses the parameters needed to configure the link-layer security module: the value of the cryptographic key, the key identifier, the link-layer algorithm identifier, and the security level and the frame types that it should be used with, both for outgoing and incoming security operations. For encoding compactness, Link_Layer_Key object is not enclosed in a top-level CBOR object. Rather, it is transported as a consecutive group of CBOR elements, with some being optional. To be able to decode the keys that are present in the link-layer key set, and to identify individual parameters of a single Link_Layer_Key object, the CBOR decoder needs to differentiate between elements based on the CBOR type. For example, when the decoder determines that the current element in the array is a byte string, it is certain that it is processing the last element of a given Link_Layer_Key object. The set of parameters that can appear in a Link_Layer_Key object is summarized below, in order: o key_index: The identifier of the key, encoded as a CBOR unsigned integer. This parameter MUST be included. The parameter uniquely identifies the key and is used to retrieve the key for incoming traffic. In case of [IEEE802.15.4], the decoded CBOR unsigned integer value sets the "secKeyIndex" parameter that is signaled in all outgoing and incoming frames secured with this key. If the decoded CBOR unsigned integer value is larger than the maximum link-layer key identifier, which is 255 in [IEEE802.15.4]), the key is considered invalid. Additionally, in case of [IEEE802.15.4], the value of 0 is considered invalid. In case the key is considered invalid, the implementation MUST discard the key and attempt to decode the next key in the array. o key_usage: The identifier of the link-layer algorithm, security level and link-layer frame types that can be used with the key, encoded as a CBOR unsigned or negative integer. This parameter MAY be included. Possible values and the corresponding link-layer settings are specified in IANA "CoJP Key Usage" registry (Section 13.3). In case the parameter is omitted, the default value of 0 from Table 3 MUST be assumed. o key_value: The value of the cryptographic key, encoded as a byte string. This parameter MUST be included. If the length of the byte string is different than the corresponding key length for a given algorithm specified by the key_usage parameter, the key MUST be discarded and the decoder should attempt to decode the next key in the array. The CDDL fragment that represents the text above for the Link_Layer_Key follows. Link_Layer_Key = ( key_index : uint, ? key_usage : uint / nint, key_value : bstr, ) +------------------+-----+-----------------+-------------+----------+ | Name | Val | Algorithm | Description | Referenc | | | ue | | | e | +------------------+-----+-----------------+-------------+----------+ | 6TiSCH-K1K2-ENC- | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | | MIC-32 | | CCM-128 | for EBs, | ocument] | | | | | ENC-MIC-32 | ] | | | | | for DATA | | | | | | and ACKNOWL | | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K1K2-ENC- | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | | MIC-64 | | CCM-128 | for EBs, | ocument] | | | | | ENC-MIC-64 | ] | | | | | for DATA | | | | | | and ACKNOWL | | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K1K2-ENC- | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | | MIC-128 | | CCM-128 | for EBs, | ocument] | | | | | ENC-MIC-128 | ] | | | | | for DATA | | | | | | and ACKNOWL | | | | | | EDGMENT. | | | | | | | | | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | | K1K2-MIC-32 | | CCM-128 | for EBs, | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | | K1K2-MIC-64 | | CCM-128 | for EBs, | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | | K1K2-MIC-128 | | CCM-128 | for EBs, | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH-K1-MIC-32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | | | | CCM-128 | for EBs. | ocument] | | | | | | ] | | | | | | | | 6TiSCH-K1-MIC-64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | | | | CCM-128 | for EBs. | ocument] | | | | | | ] | | | | | | | | 6TiSCH-K1-MIC-12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | | 8 | | CCM-128 | for EBs. | ocument] | | | | | | ] | | | | | | | | 6TiSCH-K2-MIC-32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | | | | CCM-128 | for DATA | ocument] | | | | | and ACKNOWL | ] | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K2-MIC-64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | | | | CCM-128 | for DATA | ocument] | | | | | and ACKNOWL | ] | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K2-MIC-12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | | 8 | | CCM-128 | for DATA | ocument] | | | | | and ACKNOWL | ] | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | | MIC-32 | | CCM-128 | MIC-32 for | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | | MIC-64 | | CCM-128 | MIC-64 for | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | | MIC-128 | | CCM-128 | MIC-128 for | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | +------------------+-----+-----------------+-------------+----------+ Table 3: Key Usage values. 9.3.2.2. Short Address The Short_Address object represents an address assigned to the pledge that is unique locally in the network. It is encoded as a CBOR array object, containing, in order: o address: The assigned locally-unique address, encoded as a byte string. This parameter MUST be included. In case of [IEEE802.15.4], if the length of the byte string is different than 2, the address is considered invalid. In case of [IEEE802.15.4], the value of this parameter is used to set the short address of IEEE Std 802.15.4 module. In case the address is considered invalid, the decoder MUST silently ignore the Short_Address object. o lease_time: The validity of the address in seconds after the reception of the CBOR object, encoded as a CBOR unsigned integer. This parameter MAY be included. The node MUST stop using the assigned short address after the expiry of the lease_time interval. It is up to the JRC to renew the lease before the expiry of the previous interval. The JRC updates the lease by executing the Parameter Update exchange with the node and including the Short_Address in the Configuration object, as described in Section 9.2. In case the address lease expires, the node SHOULD initiate a new join exchange, as described in Section 9.1. In case this parameter is omitted, the value of positive infinity MUST be assumed, meaning that the address is valid for as long as the node participates in the network. The CDDL fragment that represents the text above for the Short_Address follows. Short_Address = [ address : bstr, ? lease_time : uint ] 9.4. Parameters CoJP uses the following parameters: +-----------------------+----------------+ | Name | Default Value | +-----------------------+----------------+ | TIMEOUT_BASE | 10 s | +-----------------------+----------------+ | TIMEOUT_RANDOM_FACTOR | 1.5 | +-----------------------+----------------+ | MAX_RETRANSMIT | 4 | +----------------------------------------+ The values of TIMEOUT_BASE, 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.5. Mandatory to Implement Algorithms 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 IEEE Std 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. The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The mandatory to implement key derivation function is HKDF [RFC5869], instantiated with a SHA-256 hash. 10. Stateless-Proxy CoAP Option 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. The Stateless-Proxy CoAP option (see Figure 3) allows the proxy to be entirely stateless. The proxy inserts this option in the request to carry 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. 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 3: 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. For security reasons, the option value MUST be authenticated, MUST include a freshness indicator (e.g. a sequence number or timestamp) and MAY be encrypted. The proxy may use a 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 a 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 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, and the client eventually times out. 11. Security Considerations This document recommends that the (6LBR) pledge and JRC are provisioned with unique PSKs. The nonce used for the Join Request and the Join Response is 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. Note that the address of the JRC does not take part in nonce or key construction. Even in the case of a misconfiguration in which the same PSK is used for several pledges, the keys used to protect the requests/responses from/towards different pledges are different, as they are derived using the pledge identifier as Master Salt. The PSK is still important for mutual authentication of the (6LBR) pledge and the 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, the JP blindly forwards the join traffic into the network. A simple bandwidth cap on the JP prevents it from forwarding more traffic than the network can handle. This forces attackers to use more than one Join Proxy if they wish to overwhelm the network. Marking the join traffic packets with a non-zero DSCP allows the network to carry the traffic if it has capacity, but encourages the network to drop the extra traffic rather than add bandwidth due to that traffic. 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 traffic. Such an attacker is limited by its maximum transmit 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 beginning of the join process, the pledge has no means of verifying the content inthe EB,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 temporary 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. 12. Privacy Considerations The join solution specified in this document relies on the uniqueness of the pledge identifier within the namespace managed by the JRC. This identifier is transferred in clear as an OSCORE kid context. The use of the globally unique EUI-64 as pledge identifier simplifies the management but comes with certain privacy risks. The implications are thoroughly discussed in [RFC7721] andhascomprise correlation of activities over time, location tracking, address scanning and device-specific vulnerability exploitation. Since the join protocol is executed rarely compared toaccept it at "face value". In casethe network lifetime, long-term threats that arise from using EUI-64 as the pledgetries to join an attacker's network,identifier are minimal. In addition, the Join Response messagewill either failcontains a short address which is assigned by thesecurity check or time out.JRC to the (6LBR) pledge. The assigned short address SHOULD be uncorrelated with the long-term pledgemay implement a blacklistidentifier. The short address is encrypted inorder to filter out undesired EBsthe response. Once the join process completes, the new node uses the short addresses for all further layer 2 (and layer-3) operations. This mitigates the aforementioned privacy risks as the short layer-2 address (visible even when the network is encrypted) is not traceable between locations andtrydoes not disclose the manufacturer, as is the case of EUI-64. 13. IANA Considerations Note tojoin usingRFC Editor: Please replace all occurrences of "[[this document]]" with thenext seemingly valid EB.RFC number of this specification. Thisblacklist alleviatesdocument 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. 13.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\]\] | +--------+-----------------+-----------------------+ 13.2. CoJP Parameters Registry This section defines a sub-registries within theissue, but is effectively limited by"IPv6 over thenode's available memory. Bogus beacons prolongTSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry with thejoin timename "Constrained Join Protocol Parameters Registry". The columns of thepledge, and soregistry are: Name: This is a descriptive name that enables an easier reference to thetime spentitem. It is not used in"minimal" [RFC8180] duty cycle mode. 12. Privacy Considerationsthe encoding. Label: Thejoin solution specified invalue to be used to identify thisdocument relies onparameter. The label is an unsigned integer. CBOR type: This field contains theuniqueness ofCBOR type for thepledge identifier withinfield. Description: This field contains a brief description for thenamespace managed byfield. Reference: This field contains a pointer to theJRC.public specification for the field, if one exists. Thisidentifierregistry istransferredto be populated with the values inclear as an OSCORE Context Hint.Table 2. Theuseamending formula for this sub-registry is: Different ranges ofthe globally unique EUI-64 as pledge identifier simplifies the management but comes with certain privacy risks. The implicationsvalues use different registration policies [RFC8126]. Integer values from -256 to 255 arethoroughly 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 compareddesignated as Standards Action. Integer values from -65536 tothe network lifetime, long-term threats that arise-257 and fromusing EUI-64256 to 65535 are designated asthe pledge identifierSpecification Required. Integer values greater than 65535 areminimal. In addition, the Join Response message containsdesignated as Expert Review. Integer values less than -65536 are marked as Private Use. 13.3. CoJP Key Usage Registry This section defines ashort address which is assigned bysub-registries within theJRC to"IPv6 over thepledge. The assigned short address SHOULD be uncorrelatedTSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry with thelong-term pledge identifier.name "Constrained Join Protocol Key Usage Registry". The columns of this registry are: Name: This is a descriptive name that enables easier reference to the item. Theshort addressname MUST be unique. It isencryptednot used in theresponse. Once the join process completes, the new node uses the short addresses for all further layer 2 (and layer-3) operations.encoding. Value: Thismitigates the aforementioned privacy risks asis theshort layer-2 address (visible even whenvalue used to identify thenetworkkey usage setting. These values MUST be unique. The value isencrypted)an integer. Algorithm: This isnot traceable between locationsa descriptive name of the link-layer algorithm in use anddoes not discloseuniquely determines themanufacturer, askey length. The name is not used in thecaseencoding. Description: This field contains a description ofEUI-64. 13. IANA Considerations Notethe key usage setting. The field should describe in enough detail how the key is toRFC Editor: Please replace all occurrences of "[[this document]]"be used with different frame types, specific for theRFC number of this specification.link-layer technology in question. References: Thisdocument allocatescontains awell-known name underpointer to the.arpa name space accordingpublic specification for the field, if one exists. This registry is to be populated with therules givenvalues in[RFC3172].Table 3. Thename "6tisch.arpa" is requested. No subdomainsamending formula for this sub-registry is: Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 areexpected. No A, AAAA or PTR record is requested. 13.1. CoAP Option Numbers Registry The Stateless-Proxy option is addeddesignated as Standards Action. Integer values from -65536 tothe CoAP Option Numbers registry: +--------+-----------------+-------------------+ | Number | Name | Reference | +--------+-----------------+-------------------+ | TBD | Stateless-Proxy | [[this document]] | +--------+-----------------+-------------------+-257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. 14. 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 ThomasWatteyne andWatteyne, GoeranSelanderSelander, Xavier Vilajosana, Pascal Thubert for reviewing, and to Klaus Hartke for providing input on theStateless- ProxyStateless-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. The IANA considerations for the three created registries is copied verbatim from RFC8392 at the suggestion of Mike Jones. 15. References 15.1. Normative References [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)",draft-ietf-core-object-security-08draft-ietf-core-object-security-13 (work in progress),JanuaryMay 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<https://www.rfc-editor.org/info/rfc2119>.<https://www.rfc- editor.org/info/rfc2119>. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999,<https://www.rfc-editor.org/info/rfc2597>.<https://www.rfc- editor.org/info/rfc2597>. [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, <https://www.rfc-editor.org/info/rfc3172>. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014,<https://www.rfc-editor.org/info/rfc7252>.<https://www.rfc- editor.org/info/rfc7252>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>. 15.2. Informative References [I-D.ietf-6tisch-6top-protocol] Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol (6P)",draft-ietf-6tisch-6top-protocol-09draft-ietf-6tisch-6top-protocol-11 (work in progress), March 2018. [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work in progress),October 2017.April 2018. [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,"Terminology"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",draft-ietf-6tisch-terminology-09draft-ietf-6tisch-terminology-10 (work in progress),June 2017.March 2018. [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-02 (work in progress), February 2018.[I-D.richardson-6tisch-minimal-rekey] Richardson, M., "Minimal Security rekeying mechanism for 6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in progress), August 2017. [IEEE802.15.4-2015][IEEE802.15.4] IEEE standard for Information Technology, ., "IEEE Std802.15.4-2015802.15.4 Standard for Low-Rate WirelessPersonal Area Networks (WPANs)", 2015.Networks", n.d.. [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, <https://www.rfc-editor.org/info/rfc4231>. [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, <https://www.rfc-editor.org/info/rfc4944>. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010,<https://www.rfc-editor.org/info/rfc5869>.<https://www.rfc- editor.org/info/rfc5869>. [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,<https://www.rfc-editor.org/info/rfc6550>.<https://www.rfc- editor.org/info/rfc6550>. [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, <https://www.rfc-editor.org/info/rfc6775>. [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,<https://www.rfc-editor.org/info/rfc7554>.<https://www.rfc- editor.org/info/rfc7554>. [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, <https://www.rfc-editor.org/info/rfc7721>. [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, <https://www.rfc-editor.org/info/rfc8180>. Appendix A. Example Figure 4 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 as pledge identifier and OSCOREContext Hint.kid context. Triggered by the presence of a Proxy-Scheme option, the JP forwards the request to the JRC and adds the Stateless-Proxy option with value set to the internally neededstate, authentication tag, and a freshness indicator.state. The JP has learned the IPv6 address of the 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 theContext Hintkid context parameter.It reconstructs OSCORE's external Additional Authenticated Data (AAD) needed forOSCORE data authenticity verificationbased on: o the Version of the received CoAP header. o the Algorithm value agreed out-of-band, default being AES-CCM- 16-64-128 from [RFC8152]. o the Request ID being set to the value of the "kid" field of the received COSE object. o the Join Request sequence number set to the value of "Partial IV" field of the received COSE object. o Integrity-protected options received as part ofensures that therequest. Replayrequest has not been modified in transit. In addition, replay protection is ensuredby OSCORE andthrough persistent handling of mutable context parameters. 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 theCOSECBOR object(join_response)(configuration) 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 OSCORE--> Client Proxy Server Pledge JP JRC | | |+------>|| Join | | Code: { 0.02 } (POST) |GETRequest | | Token: 0x8c| |+--------->| | Proxy-Scheme: [ coap ] | POST | | Uri-Host: [ 6tisch.arpa ] | | | Object-Security: [ kid: 0 ] | | | Payload:Context-Hint:kid_context: EUI-64 | | | [ Partial IV: 1, | | | { Uri-Path:"j", | | | join_request }, | | | <Tag> ] | | | |+------>|| Join | Code: { 0.01 } (GET) | |GETRequest | Token: 0x7b || |+--------->| Uri-Host: [ 6tisch.arpa ] | | POST | Object-Security: [ kid: 0 ] | | | Stateless-Proxy: opaque state | | | Payload:Context-Hint:kid_context: EUI-64 | | | [ Partial IV: 1, | | | { Uri-Path:"j", | | | join_request }, | | | <Tag> ] | | | ||<------+| Join | Code: { 2.05 } (Content) | |2.05Response | Token: 0x7b || ||<---------+ Object-Security: - | | 2.04 | Stateless-Proxy: opaque state | | | Payload: [ {join_responseconfiguration }, <Tag> ] | | ||<------+| Join | | Code: { 2.05 } (Content) |2.05Response | | Token: 0x8c| ||<---------+ | Object-Security: - | 2.04 | | Payload: [ {join_responseconfiguration }, <Tag> ] | | | Figure 4: Example of a successful join protocol exchange. { ... } denotes encryption and authentication, [ ... ] denotes authentication. Where the join_request object is: join_request:[{ 5 : h'cafe' / PAN ID of the network pledge is attempting to join /]} Since the role parameter is not present, the default role of "6TiSCH Node" is implied. The join_request object encodes toh'8142cafe'h'a10542cafe' with a size of45 bytes. Andjoin_responsethe configuration object is:join_response: [ [ / COSE Key Set array with a single key /configuration: {12 :4,[ / link-layer keytype symmetricset /2 : h'01',1, /key idkey_index /-1 :h'e6bf4287c2d7618d6a9687445ffd33e6' /key valuekey_value /}], 3 : [ / link-layer short address / h'af93' / assigned short address / ]]} Since the key_usage parameter is not present in the link-layer key set object, the default value of "6TiSCH-K1K2-ENC-MIC-32" is implied. Similarly, since the lease_time parameter is not present in the link- layer short address object, the default value of positive infinity is implied. Thejoin_responseconfiguration object encodes toh'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93'h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size of3026 bytes. Authors' Addresses Malisa Vucinic (editor) University of Montenegro Dzordza Vasingtona bb Podgorica 81000 Montenegro Email: malisav@ac.me Jonathan Simon Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 USA 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 470 Dawson Avenue Ottawa, ON K1Z5V7 Canada Email: mcr+ietf@sandelman.ca