idnits 2.17.1 draft-ietf-6tisch-minimal-security-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 10, 2019) is 1599 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 ** Downref: Normative reference to an Informational draft: draft-ietf-6tisch-architecture (ref. 'I-D.ietf-6tisch-architecture') == Outdated reference: A later version (-08) exists of draft-ietf-core-stateless-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.15.4' ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) ** Downref: Normative reference to an Informational RFC: RFC 7554 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-18) exists of draft-ietf-6tisch-msf-08 -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Working Group M. Vucinic, Ed. 3 Internet-Draft Inria 4 Intended status: Standards Track J. Simon 5 Expires: June 12, 2020 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 December 10, 2019 12 Constrained Join Protocol (CoJP) for 6TiSCH 13 draft-ietf-6tisch-minimal-security-15 15 Abstract 17 This document describes the minimal framework required for a new 18 device, called "pledge", to securely join a 6TiSCH (IPv6 over the 19 TSCH mode of IEEE 802.15.4e) network. The framework requires that 20 the pledge and the JRC (join registrar/coordinator, a central 21 entity), share a symmetric key. How this key is provisioned is out 22 of scope of this document. Through a single CoAP (Constrained 23 Application Protocol) request-response exchange secured by OSCORE 24 (Object Security for Constrained RESTful Environments), the pledge 25 requests admission into the network and the JRC configures it with 26 link-layer keying material and other parameters. The JRC may at any 27 time update the parameters through another request-response exchange 28 secured by OSCORE. This specification defines the Constrained Join 29 Protocol and its CBOR (Concise Binary Object Representation) data 30 structures, and describes how to configure the rest of the 6TiSCH 31 communication stack for this join process to occur in a secure 32 manner. Additional security mechanisms may be added on top of this 33 minimal framework. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on June 12, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Provisioning Phase . . . . . . . . . . . . . . . . . . . . . 5 71 4. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 73 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 74 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 75 4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 76 5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 77 5.1. Distribution of Time . . . . . . . . . . . . . . . . . . 11 78 6. Network-layer Configuration . . . . . . . . . . . . . . . . . 12 79 6.1. Identification of Unauthenticated Traffic . . . . . . . . 13 80 7. Application-level Configuration . . . . . . . . . . . . . . . 14 81 7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 15 82 7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 16 83 7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 19 85 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 20 86 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 21 87 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 88 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 25 89 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 39 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 91 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 93 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 42 94 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 43 95 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 44 96 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 98 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 99 13.2. Informative References . . . . . . . . . . . . . . . . . 46 100 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 48 101 Appendix B. Lightweight Implementation Option . . . . . . . . . 51 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 104 1. Introduction 106 This document defines a "secure join" solution for a new device, 107 called "pledge", to securely join a 6TiSCH network. The term "secure 108 join" refers to network access authentication, authorization and 109 parameter distribution, as defined in [I-D.ietf-6tisch-architecture]. 110 The Constrained Join Protocol (CoJP) defined in this document handles 111 parameter distribution needed for a pledge to become a joined node. 112 Mutual authentication during network access and implicit 113 authorization are achieved through the use of a secure channel, as 114 configured by this document. This document also specifies a 115 configuration of different layers of the 6TiSCH protocol stack that 116 reduces the Denial of Service (DoS) attack surface during the join 117 process. 119 This document presumes a 6TiSCH network as described by [RFC7554] and 120 [RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their 121 radio turned off most of the time, to conserve energy. As a 122 consequence, the link used by a new device for joining the network 123 has limited bandwidth [RFC8180]. The secure join solution defined in 124 this document therefore keeps the number of over-the-air exchanges to 125 a minimum. 127 The micro-controllers at the heart of 6TiSCH nodes have a small 128 amount of code memory. It is therefore paramount to reuse existing 129 protocols available as part of the 6TiSCH stack. At the application 130 layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web 131 transfer, and on OSCORE [RFC8613] for its end-to-end security. The 132 secure join solution defined in this document therefore reuses those 133 two protocols as its building blocks. 135 CoJP is a generic protocol that can be used as-is in all modes of 136 IEEE Std 802.15.4 [IEEE802.15.4], including the Time-Slotted Channel 137 Hopping (TSCH) mode 6TiSCH is based on. CoJP may as well be used in 138 other (low-power) networking technologies where efficiency in terms 139 of communication overhead and code footprint is important. In such a 140 case, it may be necessary to define configuration parameters specific 141 to the technology in question, through companion documents. The 142 overall process described in Section 4 and the configuration of the 143 stack is specific to 6TiSCH. 145 CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a 146 central entity. The configuration defined in this document assumes 147 that the pledge and the JRC share a unique symmetric cryptographic 148 key, called PSK (pre-shared key). The PSK is used to configure 149 OSCORE to provide a secure channel to CoJP. How the PSK is installed 150 is out of scope of this document: this may happen during the 151 provisioning phase or by a key exchange protocol that may precede the 152 execution of CoJP. 154 When the pledge seeks admission to a 6TiSCH network, it first 155 synchronizes to it, by initiating the passive scan defined in 156 [IEEE802.15.4]. The pledge then exchanges CoJP messages with the 157 JRC; for this end-to-end communication to happen, messages are 158 forwarded by nodes already part of the 6TiSCH network, called Join 159 Proxies. The messages exchanged allow the JRC and the pledge to 160 mutually authenticate, based on the properties provided by OSCORE. 161 They also allow the JRC to configure the pledge with link-layer 162 keying material, short identifier and other parameters. After this 163 secure join process successfully completes, the joined node can 164 interact with its neighbors to request additional bandwidth using the 165 6top Protocol [RFC8480] and start sending application traffic. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in 172 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 The reader is expected to be familiar with the terms and concepts 176 defined in [I-D.ietf-6tisch-architecture], [RFC7252], [RFC8613], and 177 [RFC8152]. 179 The specification also includes a set of informative specifications 180 using the Concise data definition language (CDDL) 181 [I-D.ietf-cbor-cddl]. 183 The following terms defined in [I-D.ietf-6tisch-architecture] are 184 used extensively throughout this document: 186 o pledge 188 o joined node 190 o join proxy (JP) 192 o join registrar/coordinator (JRC) 193 o enhanced beacon (EB) 195 o join protocol 197 o join process 199 The following terms defined in [RFC8505] are also used throughout 200 this document: 202 o 6LoWPAN Border Router (6LBR) 204 o 6LoWPAN Node (6LN) 206 The term "6LBR" is used interchangeably with the term "DODAG root" 207 defined in [RFC6550], on the assumption that the two entities are co- 208 located, as recommended by [I-D.ietf-6tisch-architecture]. 210 The term "pledge", as used throughout the document, explicitly 211 denotes non-6LBR devices attempting to join the network using their 212 IEEE Std 802.15.4 network interface. The device that attempts to 213 join as the 6LBR of the network and does so over another network 214 interface is explicitly denoted as the "6LBR pledge". When the text 215 equally applies to the pledge and the 6LBR pledge, the "(6LBR) 216 pledge" form is used. 218 In addition, we use generic terms "pledge identifier" and "network 219 identifier". See Section 3. 221 3. Provisioning Phase 223 The (6LBR) pledge is provisioned with certain parameters before 224 attempting to join the network, and the same parameters are 225 provisioned to the JRC. There are many ways by which this 226 provisioning can be done. Physically, the parameters can be written 227 into the (6LBR) pledge using a number of mechanisms, such as a JTAG 228 interface, a serial (craft) console interface, pushing buttons 229 simultaneously on different devices, over-the-air configuration in a 230 Faraday cage, etc. The provisioning can be done by the vendor, the 231 manufacturer, the integrator, etc. 233 Details of how this provisioning is done is out of scope of this 234 document. What is assumed is that there can be a secure, private 235 conversation between the JRC and the (6LBR) pledge, and that the two 236 devices can exchange the parameters. 238 Parameters that are provisioned to the (6LBR) pledge include: 240 o pledge identifier. The pledge identifier identifies the (6LBR) 241 pledge. The pledge identifier MUST be unique in the set of all 242 pledge identifiers managed by a JRC. The pledge identifier 243 uniqueness is an important security requirement, as discussed in 244 Section 9. The pledge identifier is typically the globally unique 245 64-bit Extended Unique Identifier (EUI-64) of the IEEE Std 246 802.15.4 device, in which case it is provisioned by the hardware 247 manufacturer. The pledge identifier is used to generate the IPv6 248 addresses of the (6LBR) pledge and to identify it during the 249 execution of the join protocol. Depending on the configuration, 250 the pledge identifier may also be used after the join process to 251 identify the joined node. For privacy reasons (see Section 10), 252 it is possible to use a pledge identifier different from the EUI- 253 64. For example, a pledge identifier may be a random byte string, 254 but care needs to be taken that such a string meets the uniqueness 255 requirement. 257 o Pre-Shared Key (PSK). A symmetric cryptographic key shared 258 between the (6LBR) pledge and the JRC. To look up the PSK for a 259 given pledge, the JRC additionally needs to store the 260 corresponding pledge identifier. Each (6LBR) pledge MUST be 261 provisioned with a unique PSK. The PSK MUST be a 262 cryptographically strong key, with at least 128 bits of entropy, 263 indistinguishable by feasible computation from a random uniform 264 string of the same length. How the PSK is generated and/or 265 provisioned is out of scope of this specification. This could be 266 done during a provisioning step or companion documents can specify 267 the use of a key agreement protocol. Common pitfalls when 268 generating PSKs are discussed in Section 9. In case of device re- 269 commissioning to a new owner, the PSK MUST be changed. Note that 270 the PSK is different from the link-layer keys K1 and K2 specified 271 in [RFC8180]. The PSK is a long-term secret used to protect the 272 execution of the secure join protocol specified in this document 273 whose one output are link-layer keys. 275 o Optionally, a network identifier. The network identifier 276 identifies the 6TiSCH network. The network identifier MUST be 277 carried within Enhanced Beacon (EB) frames. Typically, the 16-bit 278 Personal Area Network Identifier (PAN ID) defined in 279 [IEEE802.15.4] is used as the network identifier. However, PAN ID 280 is not considered a stable network identifier as it may change 281 during network lifetime if a collision with another network is 282 detected. Companion documents can specify the use of a different 283 network identifier for join purposes, but this is out of scope of 284 this specification. Provisioning the network identifier to a 285 pledge is RECOMMENDED. However, due to operational constraints, 286 the network identifier may not be known at the time when the 287 provisioning is done. In case this parameter is not provisioned 288 to the pledge, the pledge attempts to join one advertised network 289 at a time, which significantly prolongs the join process. This 290 parameter MUST be provisioned to the 6LBR pledge. 292 o Optionally, any non-default algorithms. The default algorithms 293 are specified in Section 7.3.3. When algorithm identifiers are 294 not provisioned, the use of these default algorithms is implied. 296 Additionally, the 6LBR pledge that is not co-located with the JRC 297 needs to be provisioned with: 299 o Global IPv6 address of the JRC. This address is used by the 6LBR 300 pledge to address the JRC during the join process. The 6LBR 301 pledge may also obtain the IPv6 address of the JRC through other 302 available mechanisms, such as DHCPv6 [RFC8415], GRASP 303 [I-D.ietf-anima-grasp], mDNS [RFC6762], the use of which is out of 304 scope of this document. Pledges do not need to be provisioned 305 with this address as they discover it dynamically through CoJP. 307 4. Join Process Overview 309 This section describes the steps taken by a pledge in a 6TiSCH 310 network. When a pledge seeks admission to a 6TiSCH network, the 311 following exchange occurs: 313 1. The pledge listens for an Enhanced Beacon (EB) frame 314 [IEEE802.15.4]. This frame provides network synchronization 315 information, and tells the device when it can send a frame to the 316 node sending the beacons, which acts as a Join Proxy (JP) for the 317 pledge, and when it can expect to receive a frame. The Enhanced 318 Beacon provides the link-layer address of the JP and it may also 319 provide its link-local IPv6 address. 321 2. The pledge configures its link-local IPv6 address and advertises 322 it to the JP using Neighbor Discovery. The advertisement step 323 may be omitted if the link-local address has been derived from a 324 known unique interface identifier, such as an EUI-64 address. 326 3. The pledge sends a Join Request to the JP in order to securely 327 identify itself to the network. The Join Request is forwarded to 328 the JRC. 330 4. In case of successful processing of the request, the pledge 331 receives a Join Response from the JRC (via the JP). The Join 332 Response contains configuration parameters necessary for the 333 pledge to join the network. 335 From the pledge's perspective, joining is a local phenomenon - the 336 pledge only interacts with the JP, and it needs not know how far it 337 is from the 6LBR, or how to route to the JRC. Only after 338 establishing one or more link-layer keys does it need to know about 339 the particulars of a 6TiSCH network. 341 The join process is shown as a transaction diagram in Figure 1: 343 +--------+ +-------+ +--------+ 344 | pledge | | JP | | JRC | 345 | | | | | | 346 +--------+ +-------+ +--------+ 347 | | | 348 |<---Enhanced Beacon (1)---| | 349 | | | 350 |<-Neighbor Discovery (2)->| | 351 | | | 352 |-----Join Request (3a)----|----Join Request (3a)---->| \ 353 | | | | CoJP 354 |<----Join Response (3b)---|----Join Response (3b)----| / 355 | | | 357 Figure 1: Overview of a successful join process. 359 As for other nodes in the network, the 6LBR node may act as the JP. 360 The 6LBR may in addition be co-located with the JRC. 362 The details of each step are described in the following sections. 364 4.1. Step 1 - Enhanced Beacon 366 The pledge synchronizes to the network by listening for, and 367 receiving, an Enhanced Beacon (EB) sent by a node already in the 368 network. This process is entirely defined by [IEEE802.15.4], and 369 described in [RFC7554]. 371 Once the pledge hears an EB, it synchronizes to the joining schedule 372 using the cells contained in the EB. The pledge can hear multiple 373 EBs; the selection of which EB to use is out of the scope for this 374 document, and is discussed in [RFC7554]. Implementers should make 375 use of information such as: what network identifier the EB contains, 376 the value of the Join Metric field within EBs, whether the source 377 link-layer address of the EB has been tried before, what signal 378 strength the different EBs were received at, etc. In addition, the 379 pledge may be pre-configured to search for EBs with a specific 380 network identifier. 382 If the pledge is not provisioned with the network identifier, it 383 attempts to join one network at a time, as described in 384 Section 8.1.1. 386 Once the pledge selects the EB, it synchronizes to it and transitions 387 into a low-power mode. It follows the schedule information contained 388 in the EB which indicates the slots that the pledge may use for the 389 join process. During the remainder of the join process, the node 390 that has sent the EB to the pledge acts as the JP. 392 At this point, the pledge may proceed to step 2, or continue to 393 listen for additional EBs. 395 4.2. Step 2 - Neighbor Discovery 397 The pledge forms its link-local IPv6 address based on the interface 398 identifier, as per [RFC4944]. The pledge MAY perform the Neighbor 399 Solicitation / Neighbor Advertisement exchange with the JP, as per 400 Section 5.6 of [RFC8505]. As per [RFC8505], there is no need to 401 perform duplicate address detection for the link-local address. The 402 pledge and the JP use their link-local IPv6 addresses for all 403 subsequent communication during the join process. 405 Note that Neighbor Discovery exchanges at this point are not 406 protected with link-layer security as the pledge is not in possession 407 of the keys. How the JP accepts these unprotected frames is 408 discussed in Section 5. 410 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution 412 The pledge triggers the join exchange of the Constrained Join 413 Protocol (CoJP). The join exchange consists of two messages: the 414 Join Request message (Step 3a), and the Join Response message 415 conditioned on the successful security processing of the request 416 (Step 3b). 418 All CoJP messages are exchanged over a secure end-to-end channel that 419 provides confidentiality, data authenticity and replay protection. 420 Frames carrying CoJP messages are not protected with link-layer 421 security when exchanged between the pledge and the JP as the pledge 422 is not in possession of the link-layer keys in use. How JP and 423 pledge accept these unprotected frames is discussed in Section 5. 424 When frames carrying CoJP messages are exchanged between nodes that 425 have already joined the network, the link-layer security is applied 426 according to the security configuration used in the network. 428 4.3.1. Step 3a - Join Request 430 The Join Request is a message sent from the pledge to the JP, and 431 which the JP forwards to the JRC. The pledge indicates in the Join 432 Request the role it requests to play in the network, as well as the 433 identifier of the network it requests to join. The JP forwards the 434 Join Request to the JRC on the existing links. How exactly this 435 happens is out of scope of this document; some networks may wish to 436 dedicate specific link layer resources for this join traffic. 438 4.3.2. Step 3b - Join Response 440 The Join Response is sent by the JRC to the pledge, and is forwarded 441 through the JP. The packet containing the Join Response travels from 442 the JRC to the JP using the operating routes in the network. The JP 443 delivers it to the pledge. The JP operates as an application-layer 444 proxy, see Section 7. 446 The Join Response contains different parameters needed by the pledge 447 to become a fully operational network node. These parameters include 448 the link-layer key(s) currently in use in the network, the short 449 address assigned to the pledge, the IPv6 address of the JRC needed by 450 the pledge to operate as the JP, among others. 452 4.4. The Special Case of the 6LBR Pledge Joining 454 The 6LBR pledge performs Section 4.3 of the join process described 455 above, just as any other pledge, albeit over a different network 456 interface. There is no JP intermediating the communication between 457 the 6LBR pledge and the JRC, as described in Section 6. The other 458 steps of the described join process do not apply to the 6LBR pledge. 459 How the 6LBR pledge obtains an IPv6 address and triggers the 460 execution of the CoJP protocol is out of scope of this document. 462 5. Link-layer Configuration 464 In an operational 6TiSCH network, all frames use link-layer frame 465 security [RFC8180]. The IEEE Std 802.15.4 security attributes 466 include frame authenticity, and optionally frame confidentiality 467 (i.e. encryption). 469 Any node sending EB frames MUST be prepared to act as a JP for 470 potential pledges. 472 The pledge does not initially do any authenticity check of the EB 473 frames, as it does not possess the link-layer key(s) in use. The 474 pledge is still able to parse the contents of the received EBs and 475 synchronize to the network, as EBs are not encrypted [RFC8180]. 477 When sending frames during the join process, the pledge sends 478 unencrypted and unauthenticated frames at the link layer. In order 479 for the join process to be possible, the JP must accept these 480 unsecured frames for the duration of the join process. This behavior 481 may be implemented by setting the "secExempt" attribute in the IEEE 482 Std 802.15.4 security configuration tables. It is expected that the 483 lower layer provides an interface to indicate to the upper layer that 484 unsecured frames are being received from a device, and that the upper 485 layer can use that information to make a determination that a join 486 process is in place and the unsecured frames should be processed. 487 How the JP makes such a determination and interacts with the lower 488 layer is out of scope of this specification. The JP can additionally 489 make use of information such as the value of the join rate parameter 490 (Section 8.4.2) set by the JRC, physical button press, etc. 492 When the pledge initially synchronizes to the network, it has no 493 means of verifying the authenticity of EB frames. As an attacker can 494 craft a frame that looks like a legitimate EB frame this opens up a 495 DoS vector, as discussed in Section 9. 497 5.1. Distribution of Time 499 Nodes in a 6TiSCH network keep a global notion of time known as the 500 absolute slot number. Absolute slot number is used in the 501 construction of the link-layer nonce, as defined in [IEEE802.15.4]. 502 The pledge initially synchronizes to the EB frame sent by the JP, and 503 uses the value of the absolute slot number found in the TSCH 504 Synchronization Information Element. At the time of the 505 synchronization, the EB frame can neither be authenticated nor its 506 freshness verified. During the join process, the pledge sends frames 507 that are unprotected at the link-layer and protected end-to-end 508 instead. The pledge does not obtain the time information as the 509 output of the join process as this information is local to the 510 network and may not be known at the JRC. 512 This enables an attack on the pledge where the attacker replays to 513 the pledge legitimate EB frames obtained from the network and acts as 514 a man-in-the-middle between the pledge and the JP. The EB frames 515 will make the pledge believe that the replayed absolute slot number 516 value is the current notion of time in the network. By forwarding 517 the join traffic to the legitimate JP, the attacker enables the 518 pledge to join the network. Under different conditions relating to 519 the reuse of the pledge's short address by the JRC or its attempt to 520 rejoin the network, this may cause the pledge to reuse the link-layer 521 nonce in the first frame it sends protected after the join process is 522 completed. 524 For this reason, all frames originated at the JP and destined to the 525 pledge during the join process MUST be authenticated at the link- 526 layer using the key that is normally in use in the network. Link- 527 layer security processing at the pledge for these frames will fail as 528 the pledge is not yet in possession of the key. The pledge 529 acknowledges these frames without link-layer security, and JP accepts 530 the unsecured acknowledgment due to the secExempt attribute set for 531 the pledge. The frames should be passed to the upper layer for 532 processing using the promiscuous mode of [IEEE802.15.4] or another 533 appropriate mechanism. When the upper layer processing on the pledge 534 is completed and the link-layer keys are configured, the upper layer 535 MUST trigger the security processing of the corresponding frame. 536 Once the security processing of the frame carrying the Join Response 537 message is successful, the current absolute slot number kept locally 538 at the pledge SHALL be declared as valid. 540 6. Network-layer Configuration 542 The pledge and the JP SHOULD keep a separate neighbor cache for 543 untrusted entries and use it to store each other's information during 544 the join process. Mixing neighbor entries belonging to pledges and 545 nodes that are part of the network opens up the JP to a DoS attack, 546 as the attacker may fill JP's neighbor table and prevent the 547 discovery of legitimate neighbors. 549 Once the pledge obtains link-layer keys and becomes a joined node, it 550 is able to securely communicate with its neighbors, obtain the 551 network IPv6 prefix and form its global IPv6 address. The joined 552 node then undergoes an independent process to bootstrap its neighbor 553 cache entries, possibly with a node that formerly acted as a JP, 554 following [RFC8505]. From the point of view of the JP, there is no 555 relationship between the neighbor cache entry belonging to a pledge 556 and the joined node that formerly acted as a pledge. 558 The pledge does not communicate with the JRC at the network layer. 559 This allows the pledge to join without knowing the IPv6 address of 560 the JRC. Instead, the pledge communicates with the JP at the network 561 layer using link-local addressing, and with the JRC at the 562 application layer, as specified in Section 7. 564 The JP communicates with the JRC over global IPv6 addresses. The JP 565 discovers the network IPv6 prefix and configures its global IPv6 566 address upon successful completion of the join process and the 567 obtention of link-layer keys. The pledge learns the IPv6 address of 568 the JRC from the Join Response, as specified in Section 8.1.2; it 569 uses it once joined in order to operate as a JP. 571 As a special case, the 6LBR pledge may have an additional network 572 interface that it uses in order to obtain the configuration 573 parameters from the JRC and start advertising the 6TiSCH network. 574 This additional interface needs to be configured with a global IPv6 575 address, by a mechanism that is out of scope of this document. The 576 6LBR pledge uses this interface to directly communicate with the JRC 577 using global IPv6 addressing. 579 The JRC can be co-located on the 6LBR. In this special case, the 580 IPv6 address of the JRC can be omitted from the Join Response message 581 for space optimization. The 6LBR then MUST set the DODAGID field in 582 the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the 583 address of the JRC once joined and upon the reception of the first 584 RPL DIO message, and uses it to operate as a JP. 586 6.1. Identification of Unauthenticated Traffic 588 The traffic that is proxied by the Join Proxy (JP) comes from 589 unauthenticated pledges, and there may be an arbitrary amount of it. 590 In particular, an attacker may send fraudulent traffic in an attempt 591 to overwhelm the network. 593 When operating as part of a [RFC8180] 6TiSCH minimal network using 594 distributed scheduling algorithms, the traffic from unauthenticated 595 pledges may cause intermediate nodes to request additional bandwidth. 596 An attacker could use this property to cause the network to 597 overcommit bandwidth (and energy) to the join process. 599 The Join Proxy is aware of what traffic originates from 600 unauthenticated pledges, and so can avoid allocating additional 601 bandwidth itself. The Join Proxy implements a data cap on outgoing 602 join traffic by implementing the recommendation of 1 packet per 3 603 seconds in Section 3.1.3 of [RFC8085]. This can be achieved with the 604 congestion control mechanism specified in Section 4.7 of [RFC7252]. 605 This cap will not protect intermediate nodes as they can not tell 606 join traffic from regular traffic. Despite the data cap implemented 607 separately on each Join Proxy, the aggregate join traffic from many 608 Join Proxies may cause intermediate nodes to decide to allocate 609 additional cells. It is undesirable to do so in response to the 610 traffic originated at unauthenticated pledges. In order to permit 611 the intermediate nodes to avoid this, the traffic needs to be tagged. 612 [RFC2597] defines a set of per-hop behaviors that may be encoded into 613 the Diffserv Code Points (DSCPs). Based on the DSCP, intermediate 614 nodes can decide whether to act on a given packet. 616 6.1.1. Traffic from JP to JRC 618 The Join Proxy SHOULD set the DSCP of packets that it produces as 619 part of the forwarding process to AF43 code point (See Section 6 of 620 [RFC2597]). A Join Proxy that does not require a specific DSCP value 621 on traffic forwarded should set it to zero so that it is compressed 622 out. 624 A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT 625 allocate additional cells as a result of traffic with code point 626 AF43. Companion SF documents SHOULD specify how this recommended 627 behavior is achieved. One example is the 6TiSCH Minimal Scheduling 628 Function [I-D.ietf-6tisch-msf]. 630 6.1.2. Traffic from JRC to JP 632 The JRC SHOULD set the DSCP of join response packets addressed to the 633 Join Proxy to AF42 code point. AF42 has lower drop probability than 634 AF43, giving this traffic priority in buffers over the traffic going 635 towards the JRC. 637 The 6LBR links are often the most congested within a DODAG, and from 638 that point down there is progressively less (or equal) congestion. 639 If the 6LBR paces itself when sending join response traffic then it 640 ought to never exceed the bandwidth allocated to the best effort 641 traffic cells. If the 6LBR has the capacity (if it is not 642 constrained) then it should provide some buffers in order to satisfy 643 the Assured Forwarding behavior. 645 Companion SF documents SHOULD specify how traffic with code point 646 AF42 is handled with respect to cell allocation. In case the 647 recommended behavior described in this section is not followed, the 648 network may become prone to the attack discussed in Section 6.1. 650 7. Application-level Configuration 652 The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and 653 the secure channel provided by OSCORE [RFC8613]. The (6LBR) pledge 654 acts as a CoAP client; the JRC acts as a CoAP server. The JP 655 implements CoAP forward proxy functionality [RFC7252]. Because the 656 JP can also be a constrained device, it cannot implement a cache. 658 The pledge designates a JP as a proxy by including the Proxy-Scheme 659 option in CoAP requests it sends to the JP. The pledge also includes 660 in the requests the Uri-Host option with its value set to the well- 661 known JRC's alias, as specified in Section 8.1.1. 663 The JP resolves the alias to the IPv6 address of the JRC that it 664 learned when it acted as a pledge, and joined the network. This 665 allows the JP to reach the JRC at the network layer and forward the 666 requests on behalf of the pledge. 668 7.1. Statelessness of the JP 670 The CoAP proxy defined in [RFC7252] keeps per-client state 671 information in order to forward the response towards the originator 672 of the request. This state information includes at least the CoAP 673 token, the IPv6 address of the client, and the UDP source port 674 number. Since the JP can be a constrained device that acts as a CoAP 675 proxy, memory limitations make it prone to a Denial-of-Service (DoS) 676 attack. 678 This DoS vector on the JP can be mitigated by making the JP act as a 679 stateless CoAP proxy, where "state" encompasses the information 680 related to individual pledges. The JP can wrap the state it needs to 681 keep for a given pledge throughout the network stack in a "state 682 object" and include it as a CoAP token in the forwarded request to 683 the JRC. The JP may use the CoAP token as defined in [RFC7252], if 684 the size of the serialized state object permits, or use the extended 685 CoAP token defined in [I-D.ietf-core-stateless], to transport the 686 state object. The JRC and any other potential proxy on the JP - JRC 687 path MUST support extended token lengths, as defined in 688 [I-D.ietf-core-stateless]. Since the CoAP token is echoed back in 689 the response, the JP is able to decode the state object and configure 690 the state needed to forward the response to the pledge. The 691 information that the JP needs to encode in the state object to 692 operate in a fully stateless manner with respect to a given pledge is 693 implementation specific. 695 It is RECOMMENDED that the JP operates in a stateless manner and 696 signals the per-pledge state within the CoAP token, for every request 697 it forwards into the network on behalf of unauthenticated pledges. 698 When the JP is operating in a stateless manner, the security 699 considerations from [I-D.ietf-core-stateless] apply and the type of 700 the CoAP message that the JP forwards on behalf of the pledge MUST be 701 non-confirmable (NON), regardless of the message type received from 702 the pledge. The use of a non-confirmable message by the JP 703 alleviates the JP from keeping CoAP message exchange state. The 704 retransmission burden is then entirely shifted to the pledge. A JP 705 that operates in a stateless manner still needs to keep congestion 706 control state with the JRC, see Section 9. Recommended values of 707 CoAP settings for use during the join process, both by the pledge and 708 the JP, are given in Section 7.2. 710 Note that in some networking stack implementations, a fully (per- 711 pledge) stateless operation of the JP may be challenging from the 712 implementation's point of view. In those cases, the JP may operate 713 as a statefull proxy that stores the per-pledge state until the 714 response is received or timed out, but this comes at a price of a DoS 715 vector. 717 7.2. Recommended Settings 719 This section gives RECOMMENDED values of CoAP settings during the 720 join process. 722 +-------------------+---------------+ 723 | Name | Default Value | 724 +-------------------+---------------+ 725 | ACK_TIMEOUT | 10 seconds | 726 | | | 727 | ACK_RANDOM_FACTOR | 1.5 | 728 | | | 729 | MAX_RETRANSMIT | 4 | 730 | | | 731 | NSTART | 1 | 732 | | | 733 | DEFAULT_LEISURE | 5 seconds | 734 | | | 735 | PROBING_RATE | 1 byte/second | 736 +-------------------+---------------+ 738 Recommended CoAP settings. 740 These values may be configured to values specific to the deployment. 741 The default values have been chosen to accommodate a wide range of 742 deployments, taking into account dense networks. 744 The PROBING_RATE value at the JP is controlled by the join rate 745 parameter, see Section 8.4.2. Following [RFC7252], the average data 746 rate in sending to the JRC must not exceed PROBING_RATE. For 747 security reasons, the average data rate SHOULD be measured over a 748 rather short window, e.g. ACK_TIMEOUT, see Section 9. 750 7.3. OSCORE 752 Before the (6LBR) pledge and the JRC start exchanging CoAP messages 753 protected with OSCORE, they need to derive the OSCORE security 754 context from the provisioned parameters, as discussed in Section 3. 756 The OSCORE security context MUST be derived as per Section 3 of 757 [RFC8613]. 759 o the Master Secret MUST be the PSK. 761 o the Master Salt MUST be the empty byte string. 763 o the ID Context MUST be set to the pledge identifier. 765 o the ID of the pledge MUST be set to the empty byte string. This 766 identifier is used as the OSCORE Sender ID of the pledge in the 767 security context derivation, since the pledge initially acts as a 768 CoAP client. 770 o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" 771 in ASCII). This identifier is used as the OSCORE Recipient ID of 772 the pledge in the security context derivation, as the JRC 773 initially acts as a CoAP server. 775 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 776 of-band by the same mechanism used to provision the PSK. The 777 default is AES-CCM-16-64-128. 779 o the Key Derivation Function MUST be agreed out-of-band by the same 780 mechanism used to provision the PSK. Default is HKDF SHA-256 781 [RFC5869]. 783 Since the pledge's OSCORE Sender ID is the empty byte string, when 784 constructing the OSCORE option, the pledge sets the k bit in the 785 OSCORE flag byte, but indicates a 0-length kid. The pledge 786 transports its pledge identifier within the kid context field of the 787 OSCORE option. The derivation in [RFC8613] results in OSCORE keys 788 and a common IV for each side of the conversation. Nonces are 789 constructed by XOR'ing the common IV with the current sequence 790 number. For details on nonce and OSCORE option construction, refer 791 to [RFC8613]. 793 Implementations MUST ensure that multiple CoAP requests, including to 794 different JRCs, are properly incrementing the sequence numbers, so 795 that the same sequence number is never reused in distinct requests 796 protected under the same PSK. The pledge typically sends requests to 797 different JRCs if it is not provisioned with the network identifier 798 and attempts to join one network at a time. Failure to comply will 799 break the security guarantees of the Authenticated Encryption with 800 Associated Data (AEAD) algorithm because of nonce reuse. 802 This OSCORE security context is used for initial joining of the 803 (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well 804 as for any later parameter updates, where the JRC acts as a CoAP 805 client and the joined node as a CoAP server, as discussed in 806 Section 8.2. Note that when the (6LBR) pledge and the JRC change 807 roles between CoAP client and CoAP server, the same OSCORE security 808 context as initially derived remains in use and the derived 809 parameters are unchanged, for example Sender ID when sending and 810 Recipient ID when receiving (see Section 3.1 of [RFC8613]). A (6LBR) 811 pledge is expected to have exactly one OSCORE security context with 812 the JRC. 814 7.3.1. Replay Window and Persistency 816 Both (6LBR) pledge and the JRC MUST implement a replay protection 817 mechanism. The use of the default OSCORE replay protection mechanism 818 specified in Section 3.2.2 of [RFC8613] is RECOMMENDED. 820 Implementations MUST ensure that mutable OSCORE context parameters 821 (Sender Sequence Number, Replay Window) are stored in persistent 822 memory. A technique detailed in Appendix B.1.1 of [RFC8613] that 823 prevents reuse of sequence numbers MUST be implemented. Each update 824 of the OSCORE Replay Window MUST be written to persistent memory. 826 This is an important security requirement in order to guarantee nonce 827 uniqueness and resistance to replay attacks across reboots and 828 rejoins. Traffic between the (6LBR) pledge and the JRC is rare, 829 making security outweigh the cost of writing to persistent memory. 831 7.3.2. OSCORE Error Handling 833 Errors raised by OSCORE during the join process MUST be silently 834 dropped, with no error response being signaled. The pledge MUST 835 silently discard any response not protected with OSCORE, including 836 error codes. 838 Such errors may happen for a number of reasons, including failed 839 lookup of an appropriate security context (e.g. the pledge attempting 840 to join a wrong network), failed decryption, positive replay window 841 lookup, formatting errors (possibly due to malicious alterations in 842 transit). Silently dropping OSCORE messages prevents a DoS attack on 843 the pledge where the attacker could send bogus error responses, 844 forcing the pledge to attempt joining one network at a time, until 845 all networks have been tried. 847 7.3.3. Mandatory to Implement Algorithms 849 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 850 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 851 securing IEEE Std 802.15.4 frames, and hardware acceleration for it 852 is present in virtually all compliant radio chips. With this choice, 853 CoAP messages are protected with an 8-byte CCM authentication tag, 854 and the algorithm uses 13-byte long nonces. 856 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The 857 mandatory to implement key derivation function is HKDF [RFC5869], 858 instantiated with a SHA-256 hash. See Appendix B for implementation 859 guidance when code footprint is important. 861 8. Constrained Join Protocol (CoJP) 863 The Constrained Join Protocol (CoJP) is a lightweight protocol over 864 CoAP [RFC7252] and a secure channel provided by OSCORE [RFC8613]. 865 CoJP allows a (6LBR) pledge to request admission into a network 866 managed by the JRC. It enables the JRC to configure the pledge with 867 the necessary parameters. The JRC may update the parameters at any 868 time, by reaching out to the joined node that formerly acted as a 869 (6LBR) pledge. For example, network-wide rekeying can be implemented 870 by updating the keying material on each node. 872 CoJP relies on the security properties provided by OSCORE. This 873 includes end-to-end confidentiality, data authenticity, replay 874 protection, and a secure binding of responses to requests. 876 +-----------------------------------+ 877 | Constrained Join Protocol (CoJP) | 878 +-----------------------------------+ 879 +-----------------------------------+ \ 880 | Requests / Responses | | 881 |-----------------------------------| | 882 | OSCORE | | CoAP 883 |-----------------------------------| | 884 | Messaging Layer | | 885 +-----------------------------------+ / 886 +-----------------------------------+ 887 | UDP | 888 +-----------------------------------+ 890 Figure 2: Abstract layering of CoJP. 892 When a (6LBR) pledge requests admission to a given network, it 893 undergoes the CoJP join exchange that consists of: 895 o the Join Request message, sent by the (6LBR) pledge to the JRC, 896 potentially proxied by the JP. The Join Request message and its 897 mapping to CoAP is specified in Section 8.1.1. 899 o the Join Response message, sent by the JRC to the (6LBR) pledge, 900 if the JRC successfully processes the Join Request using OSCORE 901 and it determines through a mechanism that is out of scope of this 902 specification that the (6LBR) pledge is authorized to join the 903 network. The Join Response message is potentially proxied by the 904 JP. The Join Response message and its mapping to CoAP is 905 specified in Section 8.1.2. 907 When the JRC needs to update the parameters of a joined node that 908 formerly acted as a (6LBR) pledge, it executes the CoJP parameter 909 update exchange that consists of: 911 o the Parameter Update message, sent by the JRC to the joined node 912 that formerly acted as a (6LBR) pledge. The Parameter Update 913 message and its mapping to CoAP is specified in Section 8.2.1. 915 The payload of CoJP messages is encoded with CBOR [RFC7049]. The 916 CBOR data structures that may appear as the payload of different CoJP 917 messages are specified in Section 8.4. 919 8.1. Join Exchange 921 This section specifies the messages exchanged when the (6LBR) pledge 922 requests admission and configuration parameters from the JRC. 924 8.1.1. Join Request Message 926 The Join Request message that the (6LBR) pledge sends SHALL be mapped 927 to a CoAP request: 929 o The request method is POST. 931 o The type is Confirmable (CON). 933 o The Proxy-Scheme option is set to "coap". 935 o The Uri-Host option is set to "6tisch.arpa". This is an anycast 936 type of identifier of the JRC that is resolved to its IPv6 address 937 by the JP or the 6LBR pledge. 939 o The Uri-Path option is set to "j". 941 o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE 942 security context used is the one derived in Section 7.3. The 943 OSCORE kid context allows the JRC to retrieve the security context 944 for a given pledge. 946 o The payload is a Join_Request CBOR object, as defined in 947 Section 8.4.1. 949 Since the Join Request is a confirmable message, the transmission at 950 (6LBR) pledge will be controlled by CoAP's retransmission mechanism. 951 The JP, when operating in a stateless manner, forwards this Join 952 Request as a non-confirmable (NON) CoAP message, as specified in 953 Section 7. If the CoAP implementation at (6LBR) pledge declares the 954 message transmission as failure, the (6LBR) pledge SHOULD attempt to 955 join a 6TiSCH network advertised with a different network identifier. 956 See Section 7.2 for recommended values of CoAP settings to use during 957 the join exchange. 959 If all join attempts to advertised networks have failed, the (6LBR) 960 pledge SHOULD signal the presence of an error condition, through some 961 out-of-band mechanism. 963 BCP190 [RFC7320] provides guidelines on URI design and ownership. It 964 recommends that whenever a third party wants to mandate a URL to web 965 authority that it SHOULD go under "/.well-known" (as per [RFC5785]). 966 In the case of CoJP, the Uri-Host option is always set to 967 "6tisch.arpa", and based upon the recommendations in the Introduction 968 of [RFC7320], it is asserted that this document is the owner of the 969 CoJP service. As such, the concerns of [RFC7320] do not apply, and 970 thus the Uri-Path is only "/j". 972 8.1.2. Join Response Message 974 The Join Response message that the JRC sends SHALL be mapped to a 975 CoAP response: 977 o The response Code is 2.04 (Changed). 979 o The payload is a Configuration CBOR object, as defined in 980 Section 8.4.2. 982 8.2. Parameter Update Exchange 984 During the network lifetime, parameters returned as part of the Join 985 Response may need to be updated. One typical example is the update 986 of link-layer keying material for the network, a process known as 987 rekeying. This section specifies a generic mechanism when this 988 parameter update is initiated by the JRC. 990 At the time of the join, the (6LBR) pledge acts as a CoAP client and 991 requests the network parameters through a representation of the "/j" 992 resource, exposed by the JRC. In order for the update of these 993 parameters to happen, the JRC needs to asynchronously contact the 994 joined node. The use of the CoAP Observe option for this purpose is 995 not feasible due to the change in the IPv6 address when the pledge 996 becomes the joined node and obtains a global address. 998 Instead, once the (6LBR) pledge receives and successfully validates 999 the Join Response and so becomes a joined node, it becomes a CoAP 1000 server. The joined node creates a CoAP service at the Uri-Host value 1001 of "6tisch.arpa", and the joined node exposes the "/j" resource that 1002 is used by the JRC to update the parameters. Consequently, the JRC 1003 operates as a CoAP client when updating the parameters. The request/ 1004 response exchange between the JRC and the (6LBR) pledge happens over 1005 the already-established OSCORE secure channel. 1007 8.2.1. Parameter Update Message 1009 The Parameter Update message that the JRC sends to the joined node 1010 SHALL be mapped to a CoAP request: 1012 o The request method is POST. 1014 o The type is Confirmable (CON). 1016 o The Uri-Host option is set to "6tisch.arpa". 1018 o The Uri-Path option is set to "j". 1020 o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE 1021 security context used is the one derived in Section 7.3. When a 1022 joined node receives a request with the Sender ID set to 0x4a5243 1023 (ID of the JRC), it is able to correctly retrieve the security 1024 context with the JRC. 1026 o The payload is a Configuration CBOR object, as defined in 1027 Section 8.4.2. 1029 The JRC has implicit knowledge on the global IPv6 address of the 1030 joined node, as it knows the pledge identifier that the joined node 1031 used when it acted as a pledge, and the IPv6 network prefix. The JRC 1032 uses this implicitly derived IPv6 address of the joined node to 1033 directly address CoAP messages to it. 1035 In case the JRC does not receive a response to a Parameter Update 1036 message, it attempts multiple retransmissions, as configured by the 1037 underlying CoAP retransmission mechanism triggered for confirmable 1038 messages. Finally, if the CoAP implementation declares the 1039 transmission as failure, the JRC may consider this as a hint that the 1040 joined node is no longer in the network. How the JRC decides when to 1041 stop attempting to contact a previously joined node is out of scope 1042 of this specification but security considerations on the reuse of 1043 assigned resources apply, as discussed in Section 9. 1045 8.3. Error Handling 1047 8.3.1. CoJP CBOR Object Processing 1049 CoJP CBOR objects are transported within both CoAP requests and 1050 responses. This section describes handling in case certain CoJP CBOR 1051 object parameters are not supported by the implementation or their 1052 processing fails. See Section 7.3.2 for the handling of errors that 1053 may be raised by the underlying OSCORE implementation. 1055 When such a parameter is detected in a CoAP request (Join Request 1056 message, Parameter Update message), a Diagnostic Response message 1057 MUST be returned. A Diagnostic Response message maps to a CoAP 1058 response and is specified in Section 8.3.2. 1060 When a parameter that cannot be acted upon is encountered while 1061 processing a CoJP object in a CoAP response (Join Response message), 1062 a (6LBR) pledge SHOULD reattempt to join. In this case, the (6LBR) 1063 pledge SHOULD include the Unsupported Configuration CBOR object 1064 within the Join Request object in the following Join Request message. 1065 The Unsupported Configuration CBOR object is self-contained and 1066 enables the (6LBR) pledge to signal any parameters that the 1067 implementation of the networking stack may not support. A (6LBR) 1068 pledge MUST NOT attempt more than COJP_MAX_JOIN_ATTEMPTS number of 1069 attempts to join if the processing of the Join Response message fails 1070 each time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached 1071 without success, the (6LBR) pledge SHOULD signal the presence of an 1072 error condition, through some out-of-band mechanism. 1074 Note that COJP_MAX_JOIN_ATTEMPTS relates to the application-level 1075 handling of the CoAP response and is different from CoAP's 1076 MAX_RETRANSMIT setting that drives the retransmission mechanism of 1077 the underlying CoAP message. 1079 8.3.2. Diagnostic Response Message 1081 The Diagnostic Response message is returned for any CoJP request when 1082 the processing of the payload failed. The Diagnostic Response 1083 message is protected by OSCORE as any other CoJP protocol message. 1085 The Diagnostic Response message SHALL be mapped to a CoAP response: 1087 o The response Code is 4.00 (Bad Request). 1089 o The payload is an Unsupported Configuration CBOR object, as 1090 defined in Section 8.4.5, containing more information about the 1091 parameter that triggered the sending of this message. 1093 8.3.3. Failure Handling 1095 The Parameter Update exchange may be triggered at any time during the 1096 network lifetime, which may span several years. During this period, 1097 it may occur that a joined node or the JRC experience unexpected 1098 events such as reboots or complete failures. 1100 This document mandates that the mutable parameters in the security 1101 context are written to persistent memory (see Section 7.3.1) by both 1102 the JRC and pledges (joined nodes). As the joined node (pledge) is 1103 typically a constrained device that handles the write operations to 1104 persistent memory in a predictable manner, the retrieval of mutable 1105 security context parameters is feasible across reboots such that 1106 there is no risk of AEAD nonce reuse due to reinitialized Sender 1107 Sequence numbers, or of a replay attack due to the reinitialized 1108 replay window. JRC may be hosted on a generic machine where the 1109 write operation to persistent memory may lead to unpredictable delays 1110 due to caching. In case of a reboot event at JRC occurring before 1111 the cached data is written to persistent memory, the loss of mutable 1112 security context parameters is likely which consequently poses the 1113 risk of AEAD nonce reuse. 1115 In the event of a complete device failure, where the mutable security 1116 context parameters cannot be retrieved, it is expected that a failed 1117 joined node is replaced with a new physical device, using a new 1118 pledge identifier and a PSK. When such a failure event occurs at the 1119 JRC, it is possible that the static information on provisioned 1120 pledges, like PSKs and pledge identifiers, can be retrieved through 1121 available backups. However, it is likely that the information about 1122 joined nodes, their assigned short identifiers and mutable security 1123 context parameters is lost. If this is the case, during the process 1124 of JRC reinitialization, the network administrator MUST force through 1125 out-of-band means all the networks managed by the failed JRC to 1126 rejoin, through e.g. the reinitialization of the 6LBR nodes and 1127 freshly generated dynamic cryptographic keys and other parameters 1128 that have influence on the security properties of the network. 1130 In order to recover from such a failure event, the reinitialized JRC 1131 can trigger the renegotiation of the OSCORE security context through 1132 the procedure described in Appendix B.2 of [RFC8613]. Aware of the 1133 failure event, the reinitialized JRC responds to the first join 1134 request of each pledge it is managing with a 4.01 Unauthorized error 1135 and a random nonce. The pledge verifies the error response and then 1136 initiates the CoJP join exchange using a new OSCORE security context 1137 derived from an ID Context consisting of the concatenation of two 1138 nonces, one that it received from the JRC and the other that the 1139 pledge generates locally. After verifying the join request with the 1140 new ID Context and the derived OSCORE security context, the JRC 1141 should consequently take action in mapping the new ID Context with 1142 the previously used pledge identifier. How JRC handles this mapping 1143 is out of scope of this document. 1145 The described procedure is specified in Appendix B.2 of [RFC8613] and 1146 is RECOMMENDED in order to handle the failure events or any other 1147 event that may lead to the loss of mutable security context 1148 parameters. The length of nonces exchanged using this procedure MUST 1149 be at least 8 bytes. 1151 The procedure does require both the pledge and the JRC to have good 1152 sources of randomness. While this is typically not an issue at the 1153 JRC side, the constrained device hosting the pledge may pose 1154 limitations in this regard. If the procedure outlined in 1155 Appendix B.2 of [RFC8613] is not supported by the pledge, the network 1156 administrator MUST take action in reprovisioning the concerned 1157 devices with freshly generated parameters, through out-of-band means. 1159 8.4. CoJP Objects 1161 This section specifies the structure of CoJP CBOR objects that may be 1162 carried as the payload of CoJP messages. Some of these objects may 1163 be received both as part of the CoJP join exchange when the device 1164 operates as a (CoJP) pledge, or the parameter update exchange, when 1165 the device operates as a joined (6LBR) node. 1167 8.4.1. Join Request Object 1169 The Join_Request structure is built on a CBOR map object. 1171 The set of parameters that can appear in a Join_Request object is 1172 summarized below. The labels can be found in the "CoJP Parameters" 1173 registry Section 11.1. 1175 o role: The identifier of the role that the pledge requests to play 1176 in the network once it joins, encoded as an unsigned integer. 1177 Possible values are specified in Table 2. This parameter MAY be 1178 included. In case the parameter is omitted, the default value of 1179 0, i.e. the role "6TiSCH Node", MUST be assumed. 1181 o network identifier: The identifier of the network, as discussed in 1182 Section 3, encoded as a CBOR byte string. When present in the 1183 Join_Request, it hints to the JRC the network that the pledge is 1184 requesting to join, enabling the JRC to manage multiple networks. 1185 The pledge obtains the value of the network identifier from the 1186 received EB frames. This parameter MUST be included in a 1187 Join_Request object regardless of the role parameter value. 1189 o unsupported configuration: The identifier of the parameters that 1190 are not supported by the implementation, encoded as an 1191 Unsupported_Configuration object described in Section 8.4.5. This 1192 parameter MAY be included. If a (6LBR) pledge previously 1193 attempted to join and received a valid Join Response message over 1194 OSCORE, but failed to act on its payload (Configuration object), 1195 it SHOULD include this parameter to facilitate the recovery and 1196 debugging. 1198 Table 1 summarizes the parameters that may appear in a Join_Request 1199 object. 1201 +---------------------------+-------+------------------+ 1202 | Name | Label | CBOR Type | 1203 +---------------------------+-------+------------------+ 1204 | role | 1 | unsigned integer | 1205 | | | | 1206 | network identifier | 5 | byte string | 1207 | | | | 1208 | unsupported configuration | 8 | array | 1209 +---------------------------+-------+------------------+ 1211 Table 1: Summary of Join_Request parameters. 1213 The CDDL fragment that represents the text above for the Join_Request 1214 follows. 1216 Join_Request = { 1217 ? 1 : uint, ; role 1218 5 : bstr, ; network identifier 1219 ? 8 : Unsupported_Configuration ; unsupported configuration 1220 } 1222 +--------+-------+-------------------------------------+------------+ 1223 | Name | Value | Description | Reference | 1224 +--------+-------+-------------------------------------+------------+ 1225 | 6TiSCH | 0 | The pledge requests to play the | [[this | 1226 | Node | | role of a regular 6TiSCH node, i.e. | document]] | 1227 | | | non-6LBR node. | | 1228 | | | | | 1229 | 6LBR | 1 | The pledge requests to play the | [[this | 1230 | | | role of 6LoWPAN Border Router | document]] | 1231 | | | (6LBR). | | 1232 +--------+-------+-------------------------------------+------------+ 1234 Table 2: Role values. 1236 8.4.2. Configuration Object 1238 The Configuration structure is built on a CBOR map object. The set 1239 of parameters that can appear in a Configuration object is summarized 1240 below. The labels can be found in "CoJP Parameters" registry 1241 Section 11.1. 1243 o link-layer key set: An array encompassing a set of cryptographic 1244 keys and their identifiers that are currently in use in the 1245 network, or that are scheduled to be used in the future. The 1246 encoding of individual keys is described in Section 8.4.3. The 1247 link-layer key set parameter MAY be included in a Configuration 1248 object. When present, the link-layer key set parameter MUST 1249 contain at least one key. This parameter is also used to 1250 implement rekeying in the network. How the keys are installed and 1251 used differs for the 6LBR and other (regular) nodes, and this is 1252 explained in Section 8.4.3.1 and Section 8.4.3.2. 1254 o short identifier: a compact identifier assigned to the pledge. 1255 The short identifier structure is described in Section 8.4.4. The 1256 short identifier parameter MAY be included in a Configuration 1257 object. 1259 o JRC address: the IPv6 address of the JRC, encoded as a byte 1260 string, with the length of 16 bytes. If the length of the byte 1261 string is different from 16, the parameter MUST be discarded. If 1262 the JRC is not co-located with the 6LBR and has a different IPv6 1263 address than the 6LBR, this parameter MUST be included. In the 1264 special case where the JRC is co-located with the 6LBR and has the 1265 same IPv6 address as the 6LBR, this parameter MAY be included. If 1266 the JRC address parameter is not present in the Configuration 1267 object, this indicates that the JRC has the same IPv6 address as 1268 the 6LBR. The joined node can then discover the IPv6 address of 1269 the JRC through network control traffic. See Section 6. 1271 o blacklist: An array encompassing a list of pledge identifiers that 1272 are blacklisted by the JRC, with each pledge identifier encoded as 1273 a byte string. The blacklist parameter MAY be included in a 1274 Configuration object. When present, the array MUST contain zero 1275 or more byte strings encoding pledge identifiers. The joined node 1276 MUST silently drop any link-layer frames originating from the 1277 pledge identifiers enclosed in the blacklist parameter. When this 1278 parameter is received, its value MUST overwrite any previously set 1279 values. This parameter allows the JRC to configure the node 1280 acting as a JP to filter out traffic from misconfigured or 1281 malicious pledges before their traffic is forwarded into the 1282 network. If the JRC decides to remove a given pledge identifier 1283 from a blacklist, it omits the pledge identifier in the blacklist 1284 parameter value it sends next. Since the blacklist parameter 1285 carries the pledge identifiers, privacy considerations apply. See 1286 Section 10. 1288 o join rate: Average data rate (in units of bytes/second) of join 1289 traffic forwarded into the network that should not be exceeded 1290 when a joined node operates as a JP, encoded as an unsigned 1291 integer. The join rate parameter MAY be included in a 1292 Configuration object. This parameter allows the JRC to configure 1293 different nodes in the network to operate as JP, and act in case 1294 of an attack by throttling the rate at which JP forwards 1295 unauthenticated traffic into the network. When this parameter is 1296 present in a Configuration object, the value MUST be used to set 1297 the PROBING_RATE of CoAP at the joined node for communication with 1298 the JRC. In case this parameter is set to zero, a joined node 1299 MUST silently drop any join traffic coming from unauthenticated 1300 pledges. In case this parameter is omitted, the value of positive 1301 infinity SHOULD be assumed. Node operating as a JP MAY use 1302 another mechanism that is out of scope of this specification to 1303 configure PROBING_RATE of CoAP in the absence of a join rate 1304 parameter from the Configuration object. 1306 Table 3 summarizes the parameters that may appear in a Configuration 1307 object. 1309 +--------------------+-------+------------------+ 1310 | Name | Label | CBOR Type | 1311 +--------------------+-------+------------------+ 1312 | link-layer key set | 2 | array | 1313 | | | | 1314 | short identifier | 3 | array | 1315 | | | | 1316 | JRC address | 4 | byte string | 1317 | | | | 1318 | blacklist | 6 | array | 1319 | | | | 1320 | join rate | 7 | unsigned integer | 1321 +--------------------+-------+------------------+ 1323 Table 3: Summary of Configuration parameters. 1325 The CDDL fragment that represents the text above for the 1326 Configuration follows. Structures Link_Layer_Key and 1327 Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. 1329 Configuration = { 1330 ? 2 : [ +Link_Layer_Key ], ; link-layer key set 1331 ? 3 : Short_Identifier, ; short identifier 1332 ? 4 : bstr, ; JRC address 1333 ? 6 : [ *bstr ], ; blacklist 1334 ? 7 : uint ; join rate 1335 } 1336 +---------------+-------+----------+-------------------+------------+ 1337 | Name | Label | CBOR | Description | Reference | 1338 | | | type | | | 1339 +---------------+-------+----------+-------------------+------------+ 1340 | role | 1 | unsigned | Identifies the | [[this | 1341 | | | integer | role parameter | document]] | 1342 | | | | | | 1343 | link-layer | 2 | array | Identifies the | [[this | 1344 | key set | | | array carrying | document]] | 1345 | | | | one or more link- | | 1346 | | | | level | | 1347 | | | | cryptographic | | 1348 | | | | keys | | 1349 | | | | | | 1350 | short | 3 | array | Identifies the | [[this | 1351 | identifier | | | assigned short | document]] | 1352 | | | | identifier | | 1353 | | | | | | 1354 | JRC address | 4 | byte | Identifies the | [[this | 1355 | | | string | IPv6 address of | document]] | 1356 | | | | the JRC | | 1357 | | | | | | 1358 | network | 5 | byte | Identifies the | [[this | 1359 | identifier | | string | network | document]] | 1360 | | | | identifier | | 1361 | | | | parameter | | 1362 | | | | | | 1363 | blacklist | 6 | array | Identifies the | [[this | 1364 | | | | blacklist | document]] | 1365 | | | | parameter | | 1366 | | | | | | 1367 | join rate | 7 | unsigned | Identifier the | [[this | 1368 | | | integer | join rate | document]] | 1369 | | | | parameter | | 1370 | | | | | | 1371 | unsupported | 8 | array | Identifies the | [[this | 1372 | configuration | | | unsupported | document]] | 1373 | | | | configuration | | 1374 | | | | parameter | | 1375 +---------------+-------+----------+-------------------+------------+ 1377 Table 4: CoJP parameters map labels. 1379 8.4.3. Link-Layer Key 1381 The Link_Layer_Key structure encompasses the parameters needed to 1382 configure the link-layer security module: the key identifier; the 1383 value of the cryptographic key; the link-layer algorithm identifier 1384 and the security level and the frame types that it should be used 1385 with, both for outgoing and incoming security operations; and any 1386 additional information that may be needed to configure the key. 1388 For encoding compactness, the Link_Layer_Key object is not enclosed 1389 in a top-level CBOR object. Rather, it is transported as a sequence 1390 of CBOR elements [I-D.ietf-cbor-sequence], some being optional. 1392 The set of parameters that can appear in a Link_Layer_Key object is 1393 summarized below, in order: 1395 o key_id: The identifier of the key, encoded as a CBOR unsigned 1396 integer. This parameter MUST be included. If the decoded CBOR 1397 unsigned integer value is larger than the maximum link-layer key 1398 identifier, the key is considered invalid. In case the key is 1399 considered invalid, the key MUST be discarded and the 1400 implementation MUST signal the error as specified in 1401 Section 8.3.1. 1403 o key_usage: The identifier of the link-layer algorithm, security 1404 level and link-layer frame types that can be used with the key, 1405 encoded as an integer. This parameter MAY be included. Possible 1406 values and the corresponding link-layer settings are specified in 1407 IANA "CoJP Key Usage" registry (Section 11.2). In case the 1408 parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC- 1409 MIC32) from Table 5 MUST be assumed. This default value has been 1410 chosen such that it results in byte savings in the most 1411 constrained settings but does not imply a recommendation for its 1412 general usage. 1414 o key_value: The value of the cryptographic key, encoded as a byte 1415 string. This parameter MUST be included. If the length of the 1416 byte string is different than the corresponding key length for a 1417 given algorithm specified by the key_usage parameter, the key MUST 1418 be discarded and the implementation MUST signal the error as 1419 specified in Section 8.3.1. 1421 o key_addinfo: Additional information needed to configure the link- 1422 layer key, encoded as a byte string. This parameter MAY be 1423 included. The processing of this parameter is dependent on the 1424 link-layer technology in use and a particular keying mode. 1426 To be able to decode the keys that are present in the link-layer key 1427 set, and to identify individual parameters of a single Link_Layer_Key 1428 object, the CBOR decoder needs to differentiate between elements 1429 based on the CBOR type. For example, a uint that follows a byte 1430 string signals to the decoder that a new Link_Layer_Key object is 1431 being processed. 1433 The CDDL fragment that represents the text above for the 1434 Link_Layer_Key follows. 1436 Link_Layer_Key = ( 1437 key_id : uint, 1438 ? key_usage : int, 1439 key_value : bstr, 1440 ? key_addinfo : bstr, 1441 ) 1443 +-----------------+-----+------------------+-------------+----------+ 1444 | Name | Val | Algorithm | Description | Referenc | 1445 | | ue | | | e | 1446 +-----------------+-----+------------------+-------------+----------+ 1447 | 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | 1448 | -ENC-MIC32 | | CCM-128 | for EBs, | ocument] | 1449 | | | | ENC-MIC-32 | ] | 1450 | | | | for DATA | | 1451 | | | | and ACKNOWL | | 1452 | | | | EDGMENT. | | 1453 | | | | | | 1454 | 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | 1455 | -ENC-MIC64 | | CCM-128 | for EBs, | ocument] | 1456 | | | | ENC-MIC-64 | ] | 1457 | | | | for DATA | | 1458 | | | | and ACKNOWL | | 1459 | | | | EDGMENT. | | 1460 | | | | | | 1461 | 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | 1462 | -ENC-MIC128 | | CCM-128 | for EBs, | ocument] | 1463 | | | | ENC-MIC-128 | ] | 1464 | | | | for DATA | | 1465 | | | | and ACKNOWL | | 1466 | | | | EDGMENT. | | 1467 | | | | | | 1468 | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | 1469 | K1K2-MIC32 | | CCM-128 | for EBs, | ocument] | 1470 | | | | DATA and AC | ] | 1471 | | | | KNOWLEDGMEN | | 1472 | | | | T. | | 1473 | | | | | | 1474 | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | 1475 | K1K2-MIC64 | | CCM-128 | for EBs, | ocument] | 1476 | | | | DATA and AC | ] | 1477 | | | | KNOWLEDGMEN | | 1478 | | | | T. | | 1479 | | | | | | 1480 | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | 1481 | K1K2-MIC128 | | CCM-128 | for EBs, | ocument] | 1482 | | | | DATA and AC | ] | 1483 | | | | KNOWLEDGMEN | | 1484 | | | | T. | | 1485 | | | | | | 1486 | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | 1487 | | | CCM-128 | for EBs. | ocument] | 1488 | | | | | ] | 1489 | | | | | | 1490 | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | 1491 | | | CCM-128 | for EBs. | ocument] | 1492 | | | | | ] | 1493 | | | | | | 1494 | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | 1495 | 8 | | CCM-128 | for EBs. | ocument] | 1496 | | | | | ] | 1497 | | | | | | 1498 | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | 1499 | | | CCM-128 | for DATA | ocument] | 1500 | | | | and ACKNOWL | ] | 1501 | | | | EDGMENT. | | 1502 | | | | | | 1503 | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | 1504 | | | CCM-128 | for DATA | ocument] | 1505 | | | | and ACKNOWL | ] | 1506 | | | | EDGMENT. | | 1507 | | | | | | 1508 | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | 1509 | 8 | | CCM-128 | for DATA | ocument] | 1510 | | | | and ACKNOWL | ] | 1511 | | | | EDGMENT. | | 1512 | | | | | | 1513 | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | 1514 | MIC32 | | CCM-128 | MIC-32 for | ocument] | 1515 | | | | DATA and AC | ] | 1516 | | | | KNOWLEDGMEN | | 1517 | | | | T. | | 1518 | | | | | | 1519 | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | 1520 | MIC64 | | CCM-128 | MIC-64 for | ocument] | 1521 | | | | DATA and AC | ] | 1522 | | | | KNOWLEDGMEN | | 1523 | | | | T. | | 1524 | | | | | | 1525 | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | 1526 | MIC128 | | CCM-128 | MIC-128 for | ocument] | 1527 | | | | DATA and AC | ] | 1528 | | | | KNOWLEDGMEN | | 1529 | | | | T. | | 1530 +-----------------+-----+------------------+-------------+----------+ 1532 Table 5: Key Usage values. 1534 8.4.3.1. Rekeying of (6LoWPAN) Border Routers (6LBR) 1536 When the 6LoWPAN Border Router (6LBR) receives the Configuration 1537 object containing a link-layer key set, it MUST immediately install 1538 and start using the new keys for all outgoing traffic, and remove any 1539 old keys it has installed from the previous key set after a delay of 1540 COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the 1541 JRC to force the 6LBR to start sending traffic with the new key. The 1542 decision is taken by the JRC when it has determined that the new key 1543 has been made available to all (or some overwhelming majority) of 1544 nodes. Any node that the JRC has not yet reached at that point is 1545 either non-functional or in extended sleep such that it will not be 1546 reached. To get the key update, such node needs to go through the 1547 join process anew. 1549 8.4.3.2. Rekeying of regular (6LoWPAN) Nodes (6LN) 1551 When a regular 6LN node receives the Configuration object with a 1552 link-layer key set, it MUST install the new keys. The 6LN will use 1553 both the old and the new keys to decrypt and authenticate any 1554 incoming traffic that arrives based upon the key identifier in the 1555 packet. It MUST continue to use the old keys for all outgoing 1556 traffic until it has detected that the network has switched to the 1557 new key set. 1559 The detection of network switch is based upon the receipt of traffic 1560 secured with the new keys. Upon reception and successful security 1561 processing of a link-layer frame secured with a key from the new key 1562 set, a 6LN node MUST then switch to sending outgoing traffic using 1563 the keys from the new set for all outgoing traffic. The 6LN node 1564 MUST remove any old keys it has installed from the previous key set 1565 after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts 1566 using the new key set. 1568 Sending of traffic with the new keys signals to other downstream 1569 nodes to switch to their new key, and the effect is that there is a 1570 ripple of key updates around each 6LBR. 1572 8.4.3.3. Use in IEEE Std 802.15.4 1574 When Link_Layer_Key is used in the context of [IEEE802.15.4], the 1575 following considerations apply. 1577 Signaling of different keying modes of [IEEE802.15.4] is done based 1578 on the parameter values present in a Link_Layer_Key object. For 1579 instance, the value of the key_id parameter in combination with 1580 key_addinfo denotes which of the four Key ID modes of [IEEE802.15.4] 1581 is used and how. 1583 o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be 1584 set to 0. key_addinfo parameter MUST be present. key_addinfo 1585 parameter MUST be set to the link-layer address(es) of a single 1586 peer with whom the key should be used. Depending on the 1587 configuration of the network, key_addinfo may carry the peer's 1588 long link-layer address (i.e. pledge identifier), short link-layer 1589 address, or their concatenation with the long address being 1590 encoded first. Which address type(s) is carried is determined 1591 from the length of the byte string. 1593 o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a 1594 value different than 0. key_addinfo parameter MUST NOT be present. 1596 o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter 1597 MUST be set to a value different than 0. key_addinfo parameter 1598 MUST be present. key_addinfo parameter MUST be set to a byte 1599 string, exactly 4 bytes long. key_addinfo parameter carries the 1600 Key Source parameter used to configure [IEEE802.15.4]. 1602 o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter 1603 MUST be set to a value different than 0. key_addinfo parameter 1604 MUST be present. key_addinfo parameter MUST be set to a byte 1605 string, exactly 8 bytes long. key_addinfo parameter carries the 1606 Key Source parameter used to configure [IEEE802.15.4]. 1608 In all cases, key_usage parameter determines how a particular key 1609 should be used in respect to incoming and outgoing security policies. 1611 For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" 1612 parameter of [IEEE802.15.4] that is signaled in all outgoing frames 1613 secured with a given key. The maximum value key_id can have is 254. 1614 The value of 255 is reserved in [IEEE802.15.4] and is therefore 1615 considered invalid. 1617 Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a 1618 trusted third party and assign pairwise keys between nodes in the 1619 network. How JRC learns about the network topology is out of scope 1620 of this specification, but could be done through 6LBR - JRC signaling 1621 for example. Pairwise keys could also be derived through a key 1622 agreement protocol executed between the peers directly, where the 1623 authentication is based on the symmetric cryptographic material 1624 provided to both peers by the JRC. Such a protocol is out of scope 1625 of this specification. 1627 Implementations MUST use different link-layer keys when using 1628 different authentication tag (MIC) lengths, as using the same key 1629 with different authentication tag lengths might be unsafe. For 1630 example, this prohibits the usage of the same key for both MIC-32 and 1631 MIC-64 levels. See Annex B.4.3 of [IEEE802.15.4] for more 1632 information. 1634 8.4.4. Short Identifier 1636 The Short_Identifier object represents an identifier assigned to the 1637 pledge. It is encoded as a CBOR array object, containing, in order: 1639 o identifier: The short identifier assigned to the pledge, encoded 1640 as a byte string. This parameter MUST be included. The 1641 identifier MUST be unique in the set of all identifiers assigned 1642 in a network that is managed by a JRC. In case the identifier is 1643 invalid, the decoder MUST silently ignore the Short_Identifier 1644 object. 1646 o lease_time: The validity of the identifier in hours after the 1647 reception of the CBOR object, encoded as a CBOR unsigned integer. 1648 This parameter MAY be included. The node MUST stop using the 1649 assigned short identifier after the expiry of the lease_time 1650 interval. It is up to the JRC to renew the lease before the 1651 expiry of the previous interval. The JRC updates the lease by 1652 executing the Parameter Update exchange with the node and 1653 including the Short_Identifier in the Configuration object, as 1654 described in Section 8.2. In case the lease expires, the node 1655 SHOULD initiate a new join exchange, as described in Section 8.1. 1656 In case this parameter is omitted, the value of positive infinity 1657 MUST be assumed, meaning that the identifier is valid for as long 1658 as the node participates in the network. 1660 The CDDL fragment that represents the text above for the 1661 Short_Identifier follows. 1663 Short_Identifier = [ 1664 identifier : bstr, 1665 ? lease_time : uint 1666 ] 1668 8.4.4.1. Use in IEEE Std 802.15.4 1670 When Short_Identifier is used in the context of [IEEE802.15.4], the 1671 following considerations apply. 1673 The identifier MUST be used to set the short address of IEEE Std 1674 802.15.4 module. When operating in TSCH mode, the identifier MUST be 1675 unique in the set of all identifiers assigned in multiple networks 1676 that share link-layer key(s). If the length of the byte string 1677 corresponding to the identifier parameter is different than 2, the 1678 identifier is considered invalid. The values 0xfffe and 0xffff are 1679 reserved by [IEEE802.15.4] and their use is considered invalid. 1681 The security properties offered by the [IEEE802.15.4] link-layer in 1682 TSCH mode are conditioned on the uniqueness requirement of the short 1683 identifier (i.e. short address). The short address is one of the 1684 inputs in the construction of the nonce, which is used to protect 1685 link-layer frames. If a misconfiguration occurs, and the same short 1686 address is assigned twice under the same link-layer key, the loss of 1687 security properties is imminent. For this reason, practices where 1688 the pledge generates the short identifier locally are not safe and 1689 are likely to result in the loss of link-layer security properties. 1691 The JRC MUST ensure that at any given time there are never two same 1692 short identifiers being used under the same link-layer key. If the 1693 lease_time parameter of a given Short_Identifier object is set to 1694 positive infinity, care needs to be taken that the corresponding 1695 identifier is not assigned to another node until the JRC is certain 1696 that it is no longer in use, potentially through out-of-band 1697 signaling. If the lease_time parameter expires for any reason, the 1698 JRC should take into consideration potential ongoing transmissions by 1699 the joined node, which may be hanging in the queues, before assigning 1700 the same identifier to another node. 1702 Care needs to be taken on how the pledge (joined node) configures the 1703 expiration of the lease. Since units of the lease_time parameter are 1704 in hours after the reception of the CBOR object, the pledge needs to 1705 convert the received time to the corresponding absolute slot number 1706 in the network. The joined node (pledge) MUST only use the absolute 1707 slot number as the appropriate reference of time to determine whether 1708 the assigned short identifier is still valid. 1710 8.4.5. Unsupported Configuration Object 1712 The Unsupported_Configuration object is encoded as a CBOR array, 1713 containing at least one Unsupported_Parameter object. Each 1714 Unsupported_Parameter object is a sequence of CBOR elements without 1715 an enclosing top-level CBOR object for compactness. The set of 1716 parameters that appear in an Unsupported_Parameter object is 1717 summarized below, in order: 1719 o code: Indicates the capability of acting on the parameter signaled 1720 by parameter_label, encoded as an integer. This parameter MUST be 1721 included. Possible values of this parameter are specified in the 1722 IANA "CoJP Unsupported Configuration Code Registry" 1723 (Section 11.3). 1725 o parameter_label: Indicates the parameter. This parameter MUST be 1726 included. Possible values of this parameter are specified in the 1727 label column of the IANA "CoJP Parameters" registry 1728 (Section 11.1). 1730 o parameter_addinfo: Additional information about the parameter that 1731 cannot be acted upon. This parameter MUST be included. In case 1732 the code is set to "Unsupported", parameter_addinfo gives 1733 additional information to the JRC. If the parameter indicated by 1734 parameter_label cannot be acted upon regardless of its value, 1735 parameter_addinfo MUST be set to null, signaling to the JRC that 1736 it SHOULD NOT attempt to configure the parameter again. If the 1737 pledge can act on the parameter, but cannot configure the setting 1738 indicated by the parameter value, the pledge can hint this to the 1739 JRC. In this case, parameter_addinfo MUST be set to the value of 1740 the parameter that cannot be acted upon following the normative 1741 parameter structure specified in this document. For example, it 1742 is possible to include the link-layer key set object, signaling a 1743 subset of keys that cannot be acted upon, or the entire key set 1744 that was received. In that case, the value of the 1745 parameter_addinfo follows the link-layer key set structure defined 1746 in Section 8.4.2. In case the code is set to "Malformed", 1747 parameter_addinfo MUST be set to null, signaling to the JRC that 1748 it SHOULD NOT attempt to configure the parameter again. 1750 The CDDL fragment that represents the text above for 1751 Unsupported_Configuration and Unsupported_Parameter objects follows. 1753 Unsupported_Configuration = [ 1754 + parameter : Unsupported_Parameter 1755 ] 1757 Unsupported_Parameter = ( 1758 code : int, 1759 parameter_label : int, 1760 parameter_addinfo : nil / any 1761 ) 1762 +-------------+-------+--------------------------------+------------+ 1763 | Name | Value | Description | Reference | 1764 +-------------+-------+--------------------------------+------------+ 1765 | Unsupported | 0 | The indicated setting is not | [[this | 1766 | | | supported by the networking | document]] | 1767 | | | stack implementation. | | 1768 | | | | | 1769 | Malformed | 1 | The indicated parameter value | [[this | 1770 | | | is malformed. | document]] | 1771 +-------------+-------+--------------------------------+------------+ 1773 Table 6: Unsupported Configuration code values. 1775 8.5. Recommended Settings 1777 This section gives RECOMMENDED values of CoJP settings. 1779 +--------------------------+---------------+ 1780 | Name | Default Value | 1781 +--------------------------+---------------+ 1782 | COJP_MAX_JOIN_ATTEMPTS | 4 | 1783 | | | 1784 | COJP_REKEYING_GUARD_TIME | 12 seconds | 1785 +--------------------------+---------------+ 1787 Recommended CoJP settings. 1789 The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible 1790 retransmissions at the link layer due to imperfect wireless links. 1792 9. Security Considerations 1794 Since this document uses the pledge identifier to set the ID Context 1795 parameter of OSCORE, an important security requirement is that the 1796 pledge identifier is unique in the set of all pledge identifiers 1797 managed by a JRC. The uniqueness of the pledge identifier ensures 1798 unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also 1799 allows the JRC to retrieve the correct security context, upon the 1800 reception of a Join Request message. The management of pledge 1801 identifiers is simplified if the globally unique EUI-64 is used, but 1802 this comes with privacy risks, as discussed in Section 10. 1804 This document further mandates that the (6LBR) pledge and the JRC are 1805 provisioned with unique PSKs. While the process of provisioning PSKs 1806 to all pledges can result in a substantial operational overhead, it 1807 is vital to do so for the security properties of the network. The 1808 PSK is used to set the OSCORE Master Secret during security context 1809 derivation. This derivation process results in OSCORE keys that are 1810 important for mutual authentication of the (6LBR) pledge and the JRC. 1811 The resulting security context shared between the pledge (joined 1812 node) and the JRC is used for the purpose of joining and is long- 1813 lived in that it can be used throughout the lifetime of a joined node 1814 for parameter update exchanges. Should an attacker come to know the 1815 PSK, then a man-in-the-middle attack is possible. 1817 Note that while OSCORE provides replay protection, it does not 1818 provide an indication of freshness in the presence of an attacker 1819 that can drop/reorder traffic. Since the join request contains no 1820 randomness, and the sequence number is predictable, the JRC could in 1821 principle anticipate a join request from a particular pledge and pre- 1822 calculate the response. In such a scenario, the JRC does not have to 1823 be alive at the time when the request is received. This could be 1824 relevant in case the JRC was temporarily compromised and control 1825 subsequently regained by the legitimate owner. 1827 It is of utmost importance to avoid unsafe practices when generating 1828 and provisioning PSKs. The use of a single PSK shared among a group 1829 of devices is a common pitfall that results in poor security. In 1830 this case, the compromise of a single device is likely to lead to a 1831 compromise of the entire batch, with the attacker having the ability 1832 to impersonate a legitimate device and join the network, generate 1833 bogus data and disturb the network operation. Additionally, some 1834 vendors use methods such as scrambling or hashing of device serial 1835 numbers or their EUI-64 to generate "unique" PSKs. Without any 1836 secret information involved, the effort that the attacker needs to 1837 invest into breaking these unsafe derivation methods is quite low, 1838 resulting in the possible impersonation of any device from the batch, 1839 without even needing to compromise a single device. The use of 1840 cryptographically secure random number generators to generate the PSK 1841 is RECOMMENDED, see [NIST800-90A] for different mechanisms using 1842 deterministic methods. 1844 The JP forwards the unauthenticated join traffic into the network. A 1845 data cap on the JP prevents it from forwarding more traffic than the 1846 network can handle and enables throttling in case of an attack. Note 1847 that this traffic can only be directed at the JRC so that the JRC 1848 needs to be prepared to handle such unsanitized inputs. The data cap 1849 can be configured by the JRC by including a join rate parameter in 1850 the Join Response and it is implemented through the CoAP's 1851 PROBING_RATE setting. The use of a data cap at a JP forces attackers 1852 to use more than one JP if they wish to overwhelm the network. 1853 Marking the join traffic packets with a non-zero DSCP allows the 1854 network to carry the traffic if it has capacity, but encourages the 1855 network to drop the extra traffic rather than add bandwidth due to 1856 that traffic. 1858 The shared nature of the "minimal" cell used for the join traffic 1859 makes the network prone to a DoS attack by congesting the JP with 1860 bogus traffic. Such an attacker is limited by its maximum transmit 1861 power. The redundancy in the number of deployed JPs alleviates the 1862 issue and also gives the pledge a possibility to use the best 1863 available link for joining. How a network node decides to become a 1864 JP is out of scope of this specification. 1866 At the beginning of the join process, the pledge has no means of 1867 verifying the content in the EB, and has to accept it at "face 1868 value". In case the pledge tries to join an attacker's network, the 1869 Join Response message will either fail the security check or time 1870 out. The pledge may implement a temporary blacklist in order to 1871 filter out undesired EBs and try to join using the next seemingly 1872 valid EB. This blacklist alleviates the issue, but is effectively 1873 limited by the node's available memory. Note that this temporary 1874 blacklist is different from the one communicated as part of the CoJP 1875 Configuration object as it helps pledge fight a DoS attack. The 1876 bogus beacons prolong the join time of the pledge, and so the time 1877 spent in "minimal" [RFC8180] duty cycle mode. The blacklist 1878 communicated as part of the CoJP Configuration object helps JP fight 1879 a DoS attack by a malicious pledge. 1881 During the network lifetime, the JRC may at any time initiate a 1882 Parameter Update exchange with a joined node. The Parameter Update 1883 message uses the same OSCORE security context as is used for the join 1884 exchange, except that the server/client roles are interchanged. As a 1885 consequence, each Parameter Update message carries the well-known 1886 OSCORE Sender ID of the JRC. A passive attacker may use the OSCORE 1887 Sender ID to identify the Parameter Update traffic in case the link- 1888 layer protection does not provide confidentiality. A countermeasure 1889 against such traffic analysis attack is to use encryption at the 1890 link-layer. Note that the join traffic does not undergo link-layer 1891 protection at the first hop, as the pledge is not yet in possession 1892 of cryptographic keys. Similarly, enhanced beacon traffic in the 1893 network is not encrypted. This makes it easy for a passive attacker 1894 to identify these types of traffic. 1896 10. Privacy Considerations 1898 The join solution specified in this document relies on the uniqueness 1899 of the pledge identifier in the set of all pledge identifiers managed 1900 by a JRC. This identifier is transferred in clear as an OSCORE kid 1901 context. The use of the globally unique EUI-64 as pledge identifier 1902 simplifies the management but comes with certain privacy risks. The 1903 implications are thoroughly discussed in [RFC7721] and comprise 1904 correlation of activities over time, location tracking, address 1905 scanning and device-specific vulnerability exploitation. Since the 1906 join process occurs rarely compared to the network lifetime, long- 1907 term threats that arise from using EUI-64 as the pledge identifier 1908 are minimal. However, the use of EUI-64 after the join process 1909 completes, in the form of a layer-2 or layer-3 address, extends the 1910 aforementioned privacy threats to long term. 1912 As an optional mitigation technique, the Join Response message may 1913 contain a short address which is assigned by the JRC to the (6LBR) 1914 pledge. The assigned short address SHOULD be uncorrelated with the 1915 long-term pledge identifier. The short address is encrypted in the 1916 response. Once the join process completes, the new node may use the 1917 short addresses for all further layer-2 (and layer-3) operations. 1918 This reduces the privacy threats as the short layer-2 address 1919 (visible even when the network is encrypted) does not disclose the 1920 manufacturer, as is the case of EUI-64. However, an eavesdropper 1921 with access to the radio medium during the join process may be able 1922 to correlate the assigned short address with the extended address 1923 based on timing information with a non-negligible probability. This 1924 probability decreases with an increasing number of pledges joining 1925 concurrently. 1927 11. IANA Considerations 1929 Note to RFC Editor: Please replace all occurrences of "[[this 1930 document]]" with the RFC number of this specification. 1932 This document allocates a well-known name under the .arpa name space 1933 according to the rules given in [RFC3172]. The name "6tisch.arpa" is 1934 requested. No subdomains are expected, and addition of any such 1935 subdomains requires the publication of an IETF standards-track RFC. 1936 No A, AAAA or PTR record is requested. 1938 11.1. CoJP Parameters Registry 1940 This section defines a sub-registry within the "IPv6 over the TSCH 1941 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1942 "Constrained Join Protocol Parameters Registry". 1944 The columns of the registry are: 1946 Name: This is a descriptive name that enables an easier reference to 1947 the item. It is not used in the encoding. 1949 Label: The value to be used to identify this parameter. The label is 1950 an integer. 1952 CBOR type: This field contains the CBOR type for the field. 1954 Description: This field contains a brief description for the field. 1956 Reference: This field contains a pointer to the public specification 1957 for the field, if one exists. 1959 This registry is to be populated with the values in Table 4. 1961 The amending formula for this sub-registry is: Different ranges of 1962 values use different registration policies [RFC8126]. Integer values 1963 from -256 to 255 are designated as Standards Action. Integer values 1964 from -65536 to -257 and from 256 to 65535 are designated as 1965 Specification Required. Integer values greater than 65535 are 1966 designated as Expert Review. Integer values less than -65536 are 1967 marked as Private Use. 1969 11.2. CoJP Key Usage Registry 1971 This section defines a sub-registry within the "IPv6 over the TSCH 1972 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1973 "Constrained Join Protocol Key Usage Registry". 1975 The columns of this registry are: 1977 Name: This is a descriptive name that enables easier reference to the 1978 item. The name MUST be unique. It is not used in the encoding. 1980 Value: This is the value used to identify the key usage setting. 1981 These values MUST be unique. The value is an integer. 1983 Algorithm: This is a descriptive name of the link-layer algorithm in 1984 use and uniquely determines the key length. The name is not used in 1985 the encoding. 1987 Description: This field contains a description of the key usage 1988 setting. The field should describe in enough detail how the key is 1989 to be used with different frame types, specific for the link-layer 1990 technology in question. 1992 Reference: This contains a pointer to the public specification for 1993 the field, if one exists. 1995 This registry is to be populated with the values in Table 5. 1997 The amending formula for this sub-registry is: Different ranges of 1998 values use different registration policies [RFC8126]. Integer values 1999 from -256 to 255 are designated as Standards Action. Integer values 2000 from -65536 to -257 and from 256 to 65535 are designated as 2001 Specification Required. Integer values greater than 65535 are 2002 designated as Expert Review. Integer values less than -65536 are 2003 marked as Private Use. 2005 11.3. CoJP Unsupported Configuration Code Registry 2007 This section defines a sub-registry within the "IPv6 over the TSCH 2008 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 2009 "Constrained Join Protocol Unsupported Configuration Code Registry". 2011 The columns of this registry are: 2013 Name: This is a descriptive name that enables easier reference to the 2014 item. The name MUST be unique. It is not used in the encoding. 2016 Value: This is the value used to identify the diagnostic code. These 2017 values MUST be unique. The value is an integer. 2019 Description: This is a descriptive human-readable name. The 2020 description MUST be unique. It is not used in the encoding. 2022 Reference: This contains a pointer to the public specification for 2023 the field, if one exists. 2025 This registry is to be populated with the values in Table 6. 2027 The amending formula for this sub-registry is: Different ranges of 2028 values use different registration policies [RFC8126]. Integer values 2029 from -256 to 255 are designated as Standards Action. Integer values 2030 from -65536 to -257 and from 256 to 65535 are designated as 2031 Specification Required. Integer values greater than 65535 are 2032 designated as Expert Review. Integer values less than -65536 are 2033 marked as Private Use. 2035 12. Acknowledgments 2037 The work on this document has been partially supported by the 2038 European Union's H2020 Programme for research, technological 2039 development and demonstration under grant agreements: No 644852, 2040 project ARMOUR; No 687884, project F-Interop and open-call project 2041 SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA. 2043 The following individuals provided input to this document (in 2044 alphabetic order): Christian Amsuss, Tengfei Chang, Klaus Hartke, 2045 Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal 2046 Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne. 2048 13. References 2050 13.1. Normative References 2052 [I-D.ietf-6tisch-architecture] 2053 Thubert, P., "An Architecture for IPv6 over the TSCH mode 2054 of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work 2055 in progress), October 2019. 2057 [I-D.ietf-core-stateless] 2058 Hartke, K., "Extended Tokens and Stateless Clients in the 2059 Constrained Application Protocol (CoAP)", draft-ietf-core- 2060 stateless-03 (work in progress), October 2019. 2062 [IEEE802.15.4] 2063 IEEE standard for Information Technology, ., "IEEE Std 2064 802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 2066 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2067 Requirement Levels", BCP 14, RFC 2119, 2068 DOI 10.17487/RFC2119, March 1997, 2069 . 2071 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 2072 "Assured Forwarding PHB Group", RFC 2597, 2073 DOI 10.17487/RFC2597, June 1999, 2074 . 2076 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 2077 Requirements for the Address and Routing Parameter Area 2078 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 2079 September 2001, . 2081 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2082 Key Derivation Function (HKDF)", RFC 5869, 2083 DOI 10.17487/RFC5869, May 2010, 2084 . 2086 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2087 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2088 October 2013, . 2090 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2091 Application Protocol (CoAP)", RFC 7252, 2092 DOI 10.17487/RFC7252, June 2014, 2093 . 2095 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 2096 RFC 7320, DOI 10.17487/RFC7320, July 2014, 2097 . 2099 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 2100 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 2101 Internet of Things (IoT): Problem Statement", RFC 7554, 2102 DOI 10.17487/RFC7554, May 2015, 2103 . 2105 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2106 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2107 March 2017, . 2109 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2110 Writing an IANA Considerations Section in RFCs", BCP 26, 2111 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2112 . 2114 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2115 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2116 . 2118 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2120 May 2017, . 2122 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2123 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2124 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2125 May 2017, . 2127 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2128 Perkins, "Registration Extensions for IPv6 over Low-Power 2129 Wireless Personal Area Network (6LoWPAN) Neighbor 2130 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2131 . 2133 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2134 "Object Security for Constrained RESTful Environments 2135 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2136 . 2138 13.2. Informative References 2140 [I-D.ietf-6tisch-msf] 2141 Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and 2142 D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", 2143 draft-ietf-6tisch-msf-08 (work in progress), November 2144 2019. 2146 [I-D.ietf-anima-grasp] 2147 Bormann, C., Carpenter, B., and B. Liu, "A Generic 2148 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 2149 grasp-15 (work in progress), July 2017. 2151 [I-D.ietf-cbor-cddl] 2152 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 2153 definition language (CDDL): a notational convention to 2154 express CBOR and JSON data structures", draft-ietf-cbor- 2155 cddl-08 (work in progress), March 2019. 2157 [I-D.ietf-cbor-sequence] 2158 Bormann, C., "Concise Binary Object Representation (CBOR) 2159 Sequences", draft-ietf-cbor-sequence-02 (work in 2160 progress), September 2019. 2162 [NIST800-90A] 2163 NIST Special Publication 800-90A, Revision 1, ., Barker, 2164 E., and J. Kelsey, "Recommendation for Random Number 2165 Generation Using Deterministic Random Bit Generators", 2166 2015. 2168 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 2169 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 2170 RFC 4231, DOI 10.17487/RFC4231, December 2005, 2171 . 2173 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2174 "Transmission of IPv6 Packets over IEEE 802.15.4 2175 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2176 . 2178 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2179 Uniform Resource Identifiers (URIs)", RFC 5785, 2180 DOI 10.17487/RFC5785, April 2010, 2181 . 2183 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2184 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2185 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2186 Low-Power and Lossy Networks", RFC 6550, 2187 DOI 10.17487/RFC6550, March 2012, 2188 . 2190 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2191 DOI 10.17487/RFC6762, February 2013, 2192 . 2194 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2195 Considerations for IPv6 Address Generation Mechanisms", 2196 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2197 . 2199 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2200 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2201 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2202 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2203 . 2205 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 2206 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 2207 DOI 10.17487/RFC8480, November 2018, 2208 . 2210 Appendix A. Example 2212 Figure 3 illustrates a successful join protocol exchange. The pledge 2213 instantiates the OSCORE context and derives the OSCORE keys and 2214 nonces from the PSK. It uses the instantiated context to protect the 2215 Join Request addressed with a Proxy-Scheme option, the well-known 2216 host name of the JRC in the Uri-Host option, and its EUI-64 as pledge 2217 identifier and OSCORE kid context. Triggered by the presence of a 2218 Proxy-Scheme option, the JP forwards the request to the JRC and sets 2219 the CoAP token to the internally needed state. The JP has learned 2220 the IPv6 address of the JRC when it acted as a pledge and joined the 2221 network. Once the JRC receives the request, it looks up the correct 2222 context based on the kid context parameter. The OSCORE data 2223 authenticity verification ensures that the request has not been 2224 modified in transit. In addition, replay protection is ensured 2225 through persistent handling of mutable context parameters. 2227 Once the JP receives the Join Response, it authenticates the state 2228 within the CoAP token before deciding where to forward. The JP sets 2229 its internal state to that found in the token, and forwards the Join 2230 Response to the correct pledge. Note that the JP does not possess 2231 the key to decrypt the CoJP object (configuration) present in the 2232 payload. The Join Response is matched to the Join Request and 2233 verified for replay protection at the pledge using OSCORE processing 2234 rules. In this example, the Join Response does not contain the IPv6 2235 address of the JRC, the pledge hence understands the JRC is co- 2236 located with the 6LBR. 2238 <---E2E OSCORE--> 2239 Client Proxy Server 2240 Pledge JP JRC 2241 | | | 2242 | Join | | Code: 0.02 (POST) 2243 | Request | | Token: - 2244 +--------->| | Proxy-Scheme: coap 2245 | | | Uri-Host: 6tisch.arpa 2246 | | | OSCORE: kid: -, 2247 | | | kid_context: EUI-64, 2248 | | | Partial IV: 1 2249 | | | Payload: { Code: 0.02 (POST), 2250 | | | Uri-Path: "j", 2251 | | | join_request, } 2252 | | | 2253 | | Join | Code: 0.02 (POST) 2254 | | Request | Token: opaque state 2255 | +--------->| OSCORE: kid: -, 2256 | | | kid_context: EUI-64, 2257 | | | Partial IV: 1 2258 | | | Payload: { Code: 0.02 (POST), 2259 | | | Uri-Path: "j", 2260 | | | join_request, } 2261 | | | 2262 | | | 2263 | | Join | Code: 2.04 (Changed) 2264 | | Response | Token: opaque state 2265 | |<---------+ OSCORE: - 2266 | | | Payload: { Code: 2.04 (Changed), 2267 | | | configuration, } 2268 | | | 2269 | | | 2270 | Join | | Code: 2.04 (Changed) 2271 | Response | | Token: - 2272 |<---------+ | OSCORE: - 2273 | | | Payload: { Code: 2.04 (Changed), 2274 | | | configuration, } 2275 | | | 2277 Figure 3: Example of a successful join protocol exchange. { ... } 2278 denotes authenticated encryption, denotes the authentication 2279 tag. 2281 Where the join_request object is: 2283 join_request: 2284 { 2285 5 : h'cafe' / PAN ID of the network pledge is attempting to join / 2286 } 2288 Since the role parameter is not present, the default role of "6TiSCH 2289 Node" is implied. 2291 The join_request object encodes to h'a10542cafe' with a size of 5 2292 bytes. 2294 And the configuration object is: 2296 configuration: 2297 { 2298 2 : [ / link-layer key set / 2299 1, / key_id / 2300 h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / 2301 ], 2302 3 : [ / short identifier / 2303 h'af93' / assigned short address / 2304 ] 2305 } 2307 Since the key_usage parameter is not present in the link-layer key 2308 set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. 2309 Since key_addinfo parameter is not present and key_id is different 2310 than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since 2311 the lease_time parameter is not present in the short identifier 2312 object, the default value of positive infinity is implied. 2314 The configuration object encodes to 2316 h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size 2317 of 26 bytes. 2319 Appendix B. Lightweight Implementation Option 2321 In environments where optimizing the implementation footprint is 2322 important, it is possible to implement this specification without 2323 having the implementations of HKDF [RFC5869] and SHA [RFC4231] on 2324 constrained devices. HKDF and SHA are used during the OSCORE 2325 security context derivation phase. This derivation can also be done 2326 by the JRC or a provisioning device, on behalf of the (6LBR) pledge 2327 during the provisioning phase. In that case, the derived OSCORE 2328 security context parameters are written directly into the (6LBR) 2329 pledge, without requiring the PSK be provisioned to the (6LBR) 2330 pledge. 2332 The use of HKDF to derive OSCORE security context parameters ensures 2333 that the resulting OSCORE keys have good security properties, and are 2334 unique as long as the input for different pledges varies. This 2335 specification ensures the uniqueness by mandating unique pledge 2336 identifiers and a unique PSK for each (6LBR) pledge. From the AEAD 2337 nonce reuse viewpoint, having a unique pledge identifier is a 2338 sufficient condition. However, as discussed in Section 9, the use of 2339 a single PSK shared among many devices is a common security pitfall. 2340 The compromise of this shared PSK on a single device would lead to 2341 the compromise of the entire batch. When using the implementation/ 2342 deployment scheme outlined above, the PSK does not need to be written 2343 to individual pledges. As a consequence, even if a shared PSK is 2344 used, the scheme offers a comparable level of security as in the 2345 scenario where each pledge is provisioned with a unique PSK. In this 2346 case, there is still a latent risk of the shared PSK being 2347 compromised from the provisioning device, which would compromise all 2348 devices in the batch. 2350 Authors' Addresses 2352 Malisa Vucinic (editor) 2353 Inria 2354 2 Rue Simone Iff 2355 Paris 75012 2356 France 2358 Email: malisa.vucinic@inria.fr 2360 Jonathan Simon 2361 Analog Devices 2362 32990 Alvarado-Niles Road, Suite 910 2363 Union City, CA 94587 2364 USA 2366 Email: jonathan.simon@analog.com 2368 Kris Pister 2369 University of California Berkeley 2370 512 Cory Hall 2371 Berkeley, CA 94720 2372 USA 2374 Email: pister@eecs.berkeley.edu 2375 Michael Richardson 2376 Sandelman Software Works 2377 470 Dawson Avenue 2378 Ottawa, ON K1Z5V7 2379 Canada 2381 Email: mcr+ietf@sandelman.ca