idnits 2.17.1 draft-ietf-6tisch-minimal-security-14.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 05, 2019) is 1598 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' ** 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) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 5 errors (**), 0 flaws (~~), 4 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 7, 2020 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 December 05, 2019 12 Constrained Join Protocol (CoJP) for 6TiSCH 13 draft-ietf-6tisch-minimal-security-14 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 7, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 44 98 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 99 13.2. Informative References . . . . . . . . . . . . . . . . . 46 100 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 48 101 Appendix B. Lightweight Implementation Option . . . . . . . . . 50 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 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. 629 6.1.2. Traffic from JRC to JP 631 The JRC SHOULD set the DSCP of join response packets addressed to the 632 Join Proxy to AF42 code point. AF42 has lower drop probability than 633 AF43, giving this traffic priority in buffers over the traffic going 634 towards the JRC. 636 The 6LBR links are often the most congested within a DODAG, and from 637 that point down there is progressively less (or equal) congestion. 638 If the 6LBR paces itself when sending join response traffic then it 639 ought to never exceed the bandwidth allocated to the best effort 640 traffic cells. If the 6LBR has the capacity (if it is not 641 constrained) then it should provide some buffers in order to satisfy 642 the Assured Forwarding behavior. 644 Companion SF documents SHOULD specify how traffic with code point 645 AF42 is handled with respect to cell allocation. In case the 646 recommended behavior described in this section is not followed, the 647 network may become prone to the attack discussed in Section 6.1. 649 7. Application-level Configuration 651 The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and 652 the secure channel provided by OSCORE [RFC8613]. The (6LBR) pledge 653 acts as a CoAP client; the JRC acts as a CoAP server. The JP 654 implements CoAP forward proxy functionality [RFC7252]. Because the 655 JP can also be a constrained device, it cannot implement a cache. 657 The pledge designates a JP as a proxy by including the Proxy-Scheme 658 option in CoAP requests it sends to the JP. The pledge also includes 659 in the requests the Uri-Host option with its value set to the well- 660 known JRC's alias, as specified in Section 8.1.1. 662 The JP resolves the alias to the IPv6 address of the JRC that it 663 learned when it acted as a pledge, and joined the network. This 664 allows the JP to reach the JRC at the network layer and forward the 665 requests on behalf of the pledge. 667 7.1. Statelessness of the JP 669 The CoAP proxy defined in [RFC7252] keeps per-client state 670 information in order to forward the response towards the originator 671 of the request. This state information includes at least the CoAP 672 token, the IPv6 address of the client, and the UDP source port 673 number. Since the JP can be a constrained device that acts as a CoAP 674 proxy, memory limitations make it prone to a Denial-of-Service (DoS) 675 attack. 677 This DoS vector on the JP can be mitigated by making the JP act as a 678 stateless CoAP proxy, where "state" encompasses the information 679 related to individual pledges. The JP can wrap the state it needs to 680 keep for a given pledge throughout the network stack in a "state 681 object" and include it as a CoAP token in the forwarded request to 682 the JRC. The JP may use the CoAP token as defined in [RFC7252], if 683 the size of the serialized state object permits, or use the extended 684 CoAP token defined in [I-D.ietf-core-stateless], to transport the 685 state object. The JRC and any other potential proxy on the JP - JRC 686 path MUST support extended token lengths, as defined in 687 [I-D.ietf-core-stateless]. Since the CoAP token is echoed back in 688 the response, the JP is able to decode the state object and configure 689 the state needed to forward the response to the pledge. The 690 information that the JP needs to encode in the state object to 691 operate in a fully stateless manner with respect to a given pledge is 692 implementation specific. 694 It is RECOMMENDED that the JP operates in a stateless manner and 695 signals the per-pledge state within the CoAP token, for every request 696 it forwards into the network on behalf of unauthenticated pledges. 697 When the JP is operating in a stateless manner, the security 698 considerations from [I-D.ietf-core-stateless] apply and the type of 699 the CoAP message that the JP forwards on behalf of the pledge MUST be 700 non-confirmable (NON), regardless of the message type received from 701 the pledge. The use of a non-confirmable message by the JP 702 alleviates the JP from keeping CoAP message exchange state. The 703 retransmission burden is then entirely shifted to the pledge. A JP 704 that operates in a stateless manner still needs to keep congestion 705 control state with the JRC, see Section 9. Recommended values of 706 CoAP settings for use during the join process, both by the pledge and 707 the JP, are given in Section 7.2. 709 Note that in some networking stack implementations, a fully (per- 710 pledge) stateless operation of the JP may be challenging from the 711 implementation's point of view. In those cases, the JP may operate 712 as a statefull proxy that stores the per-pledge state until the 713 response is received or timed out, but this comes at a price of a DoS 714 vector. 716 7.2. Recommended Settings 718 This section gives RECOMMENDED values of CoAP settings during the 719 join process. 721 +-------------------+---------------+ 722 | Name | Default Value | 723 +-------------------+---------------+ 724 | ACK_TIMEOUT | 10 seconds | 725 | | | 726 | ACK_RANDOM_FACTOR | 1.5 | 727 | | | 728 | MAX_RETRANSMIT | 4 | 729 | | | 730 | NSTART | 1 | 731 | | | 732 | DEFAULT_LEISURE | 5 seconds | 733 | | | 734 | PROBING_RATE | 1 byte/second | 735 +-------------------+---------------+ 737 Recommended CoAP settings. 739 These values may be configured to values specific to the deployment. 740 The default values have been chosen to accommodate a wide range of 741 deployments, taking into account dense networks. 743 The PROBING_RATE value at the JP is controlled by the join rate 744 parameter, see Section 8.4.2. Following [RFC7252], the average data 745 rate in sending to the JRC must not exceed PROBING_RATE. For 746 security reasons, the average data rate SHOULD be measured over a 747 rather short window, e.g. ACK_TIMEOUT, see Section 9. 749 7.3. OSCORE 751 Before the (6LBR) pledge and the JRC start exchanging CoAP messages 752 protected with OSCORE, they need to derive the OSCORE security 753 context from the provisioned parameters, as discussed in Section 3. 755 The OSCORE security context MUST be derived as per Section 3 of 756 [RFC8613]. 758 o the Master Secret MUST be the PSK. 760 o the Master Salt MUST be the empty byte string. 762 o the ID Context MUST be set to the pledge identifier. 764 o the ID of the pledge MUST be set to the empty byte string. This 765 identifier is used as the OSCORE Sender ID of the pledge in the 766 security context derivation, since the pledge initially acts as a 767 CoAP client. 769 o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" 770 in ASCII). This identifier is used as the OSCORE Recipient ID of 771 the pledge in the security context derivation, as the JRC 772 initially acts as a CoAP server. 774 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 775 of-band by the same mechanism used to provision the PSK. The 776 default is AES-CCM-16-64-128. 778 o the Key Derivation Function MUST be agreed out-of-band by the same 779 mechanism used to provision the PSK. Default is HKDF SHA-256 780 [RFC5869]. 782 Since the pledge's OSCORE Sender ID is the empty byte string, when 783 constructing the OSCORE option, the pledge sets the k bit in the 784 OSCORE flag byte, but indicates a 0-length kid. The pledge 785 transports its pledge identifier within the kid context field of the 786 OSCORE option. The derivation in [RFC8613] results in OSCORE keys 787 and a common IV for each side of the conversation. Nonces are 788 constructed by XOR'ing the common IV with the current sequence 789 number. For details on nonce and OSCORE option construction, refer 790 to [RFC8613]. 792 Implementations MUST ensure that multiple CoAP requests, including to 793 different JRCs, are properly incrementing the sequence numbers, so 794 that the same sequence number is never reused in distinct requests 795 protected under the same PSK. The pledge typically sends requests to 796 different JRCs if it is not provisioned with the network identifier 797 and attempts to join one network at a time. Failure to comply will 798 break the security guarantees of the Authenticated Encryption with 799 Associated Data (AEAD) algorithm because of nonce reuse. 801 This OSCORE security context is used for initial joining of the 802 (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well 803 as for any later parameter updates, where the JRC acts as a CoAP 804 client and the joined node as a CoAP server, as discussed in 805 Section 8.2. Note that when the (6LBR) pledge and the JRC change 806 roles between CoAP client and CoAP server, the same OSCORE security 807 context as initially derived remains in use and the derived 808 parameters are unchanged, for example Sender ID when sending and 809 Recipient ID when receiving (see Section 3.1 of [RFC8613]). A (6LBR) 810 pledge is expected to have exactly one OSCORE security context with 811 the JRC. 813 7.3.1. Replay Window and Persistency 815 Both (6LBR) pledge and the JRC MUST implement a replay protection 816 mechanism. The use of the default OSCORE replay protection mechanism 817 specified in Section 3.2.2 of [RFC8613] is RECOMMENDED. 819 Implementations MUST ensure that mutable OSCORE context parameters 820 (Sender Sequence Number, Replay Window) are stored in persistent 821 memory. A technique detailed in Appendix B.1.1 of [RFC8613] that 822 prevents reuse of sequence numbers MUST be implemented. Each update 823 of the OSCORE Replay Window MUST be written to persistent memory. 825 This is an important security requirement in order to guarantee nonce 826 uniqueness and resistance to replay attacks across reboots and 827 rejoins. Traffic between the (6LBR) pledge and the JRC is rare, 828 making security outweigh the cost of writing to persistent memory. 830 7.3.2. OSCORE Error Handling 832 Errors raised by OSCORE during the join process MUST be silently 833 dropped, with no error response being signaled. The pledge MUST 834 silently discard any response not protected with OSCORE, including 835 error codes. 837 Such errors may happen for a number of reasons, including failed 838 lookup of an appropriate security context (e.g. the pledge attempting 839 to join a wrong network), failed decryption, positive replay window 840 lookup, formatting errors (possibly due to malicious alterations in 841 transit). Silently dropping OSCORE messages prevents a DoS attack on 842 the pledge where the attacker could send bogus error responses, 843 forcing the pledge to attempt joining one network at a time, until 844 all networks have been tried. 846 7.3.3. Mandatory to Implement Algorithms 848 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 849 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 850 securing IEEE Std 802.15.4 frames, and hardware acceleration for it 851 is present in virtually all compliant radio chips. With this choice, 852 CoAP messages are protected with an 8-byte CCM authentication tag, 853 and the algorithm uses 13-byte long nonces. 855 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The 856 mandatory to implement key derivation function is HKDF [RFC5869], 857 instantiated with a SHA-256 hash. See Appendix B for implementation 858 guidance when code footprint is important. 860 8. Constrained Join Protocol (CoJP) 862 The Constrained Join Protocol (CoJP) is a lightweight protocol over 863 CoAP [RFC7252] and a secure channel provided by OSCORE [RFC8613]. 864 CoJP allows a (6LBR) pledge to request admission into a network 865 managed by the JRC. It enables the JRC to configure the pledge with 866 the necessary parameters. The JRC may update the parameters at any 867 time, by reaching out to the joined node that formerly acted as a 868 (6LBR) pledge. For example, network-wide rekeying can be implemented 869 by updating the keying material on each node. 871 CoJP relies on the security properties provided by OSCORE. This 872 includes end-to-end confidentiality, data authenticity, replay 873 protection, and a secure binding of responses to requests. 875 +-----------------------------------+ 876 | Constrained Join Protocol (CoJP) | 877 +-----------------------------------+ 878 +-----------------------------------+ \ 879 | Requests / Responses | | 880 |-----------------------------------| | 881 | OSCORE | | CoAP 882 |-----------------------------------| | 883 | Messaging Layer | | 884 +-----------------------------------+ / 885 +-----------------------------------+ 886 | UDP | 887 +-----------------------------------+ 889 Figure 2: Abstract layering of CoJP. 891 When a (6LBR) pledge requests admission to a given network, it 892 undergoes the CoJP join exchange that consists of: 894 o the Join Request message, sent by the (6LBR) pledge to the JRC, 895 potentially proxied by the JP. The Join Request message and its 896 mapping to CoAP is specified in Section 8.1.1. 898 o the Join Response message, sent by the JRC to the (6LBR) pledge, 899 if the JRC successfully processes the Join Request using OSCORE 900 and it determines through a mechanism that is out of scope of this 901 specification that the (6LBR) pledge is authorized to join the 902 network. The Join Response message is potentially proxied by the 903 JP. The Join Response message and its mapping to CoAP is 904 specified in Section 8.1.2. 906 When the JRC needs to update the parameters of a joined node that 907 formerly acted as a (6LBR) pledge, it executes the CoJP parameter 908 update exchange that consists of: 910 o the Parameter Update message, sent by the JRC to the joined node 911 that formerly acted as a (6LBR) pledge. The Parameter Update 912 message and its mapping to CoAP is specified in Section 8.2.1. 914 The payload of CoJP messages is encoded with CBOR [RFC7049]. The 915 CBOR data structures that may appear as the payload of different CoJP 916 messages are specified in Section 8.4. 918 8.1. Join Exchange 920 This section specifies the messages exchanged when the (6LBR) pledge 921 requests admission and configuration parameters from the JRC. 923 8.1.1. Join Request Message 925 The Join Request message that the (6LBR) pledge sends SHALL be mapped 926 to a CoAP request: 928 o The request method is POST. 930 o The type is Confirmable (CON). 932 o The Proxy-Scheme option is set to "coap". 934 o The Uri-Host option is set to "6tisch.arpa". This is an anycast 935 type of identifier of the JRC that is resolved to its IPv6 address 936 by the JP or the 6LBR pledge. 938 o The Uri-Path option is set to "j". 940 o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE 941 security context used is the one derived in Section 7.3. The 942 OSCORE kid context allows the JRC to retrieve the security context 943 for a given pledge. 945 o The payload is a Join_Request CBOR object, as defined in 946 Section 8.4.1. 948 Since the Join Request is a confirmable message, the transmission at 949 (6LBR) pledge will be controlled by CoAP's retransmission mechanism. 950 The JP, when operating in a stateless manner, forwards this Join 951 Request as a non-confirmable (NON) CoAP message, as specified in 952 Section 7. If the CoAP implementation at (6LBR) pledge declares the 953 message transmission as failure, the (6LBR) pledge SHOULD attempt to 954 join a 6TiSCH network advertised with a different network identifier. 955 See Section 7.2 for recommended values of CoAP settings to use during 956 the join exchange. 958 If all join attempts to advertised networks have failed, the (6LBR) 959 pledge SHOULD signal the presence of an error condition, through some 960 out-of-band mechanism. 962 BCP190 [RFC7320] provides guidelines on URI design and ownership. It 963 recommends that whenever a third party wants to mandate a URL to web 964 authority that it SHOULD go under "/.well-known" (as per [RFC5785]). 965 In the case of CoJP, the Uri-Host option is always set to 966 "6tisch.arpa", and based upon the recommendations in the Introduction 967 of [RFC7320], it is asserted that this document is the owner of the 968 CoJP service. As such, the concerns of [RFC7320] do not apply, and 969 thus the Uri-Path is only "/j". 971 8.1.2. Join Response Message 973 The Join Response message that the JRC sends SHALL be mapped to a 974 CoAP response: 976 o The response Code is 2.04 (Changed). 978 o The payload is a Configuration CBOR object, as defined in 979 Section 8.4.2. 981 8.2. Parameter Update Exchange 983 During the network lifetime, parameters returned as part of the Join 984 Response may need to be updated. One typical example is the update 985 of link-layer keying material for the network, a process known as 986 rekeying. This section specifies a generic mechanism when this 987 parameter update is initiated by the JRC. 989 At the time of the join, the (6LBR) pledge acts as a CoAP client and 990 requests the network parameters through a representation of the "/j" 991 resource, exposed by the JRC. In order for the update of these 992 parameters to happen, the JRC needs to asynchronously contact the 993 joined node. The use of the CoAP Observe option for this purpose is 994 not feasible due to the change in the IPv6 address when the pledge 995 becomes the joined node and obtains a global address. 997 Instead, once the (6LBR) pledge receives and successfully validates 998 the Join Response and so becomes a joined node, it becomes a CoAP 999 server. The joined node creates a CoAP service at the Uri-Host value 1000 of "6tisch.arpa", and the joined node exposes the "/j" resource that 1001 is used by the JRC to update the parameters. Consequently, the JRC 1002 operates as a CoAP client when updating the parameters. The request/ 1003 response exchange between the JRC and the (6LBR) pledge happens over 1004 the already-established OSCORE secure channel. 1006 8.2.1. Parameter Update Message 1008 The Parameter Update message that the JRC sends to the joined node 1009 SHALL be mapped to a CoAP request: 1011 o The request method is POST. 1013 o The type is Confirmable (CON). 1015 o The Uri-Host option is set to "6tisch.arpa". 1017 o The Uri-Path option is set to "j". 1019 o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE 1020 security context used is the one derived in Section 7.3. When a 1021 joined node receives a request with the Sender ID set to 0x4a5243 1022 (ID of the JRC), it is able to correctly retrieve the security 1023 context with the JRC. 1025 o The payload is a Configuration CBOR object, as defined in 1026 Section 8.4.2. 1028 The JRC has implicit knowledge on the global IPv6 address of the 1029 joined node, as it knows the pledge identifier that the joined node 1030 used when it acted as a pledge, and the IPv6 network prefix. The JRC 1031 uses this implicitly derived IPv6 address of the joined node to 1032 directly address CoAP messages to it. 1034 In case the JRC does not receive a response to a Parameter Update 1035 message, it attempts multiple retransmissions, as configured by the 1036 underlying CoAP retransmission mechanism triggered for confirmable 1037 messages. Finally, if the CoAP implementation declares the 1038 transmission as failure, the JRC may consider this as a hint that the 1039 joined node is no longer in the network. How the JRC decides when to 1040 stop attempting to contact a previously joined node is out of scope 1041 of this specification but security considerations on the reuse of 1042 assigned resources apply, as discussed in Section 9. 1044 8.3. Error Handling 1046 8.3.1. CoJP CBOR Object Processing 1048 CoJP CBOR objects are transported within both CoAP requests and 1049 responses. This section describes handling in case certain CoJP CBOR 1050 object parameters are not supported by the implementation or their 1051 processing fails. See Section 7.3.2 for the handling of errors that 1052 may be raised by the underlying OSCORE implementation. 1054 When such a parameter is detected in a CoAP request (Join Request 1055 message, Parameter Update message), a Diagnostic Response message 1056 MUST be returned. A Diagnostic Response message maps to a CoAP 1057 response and is specified in Section 8.3.2. 1059 When a parameter that cannot be acted upon is encountered while 1060 processing a CoJP object in a CoAP response (Join Response message), 1061 a (6LBR) pledge SHOULD reattempt to join. In this case, the (6LBR) 1062 pledge SHOULD include the Unsupported Configuration CBOR object 1063 within the Join Request object in the following Join Request message. 1064 The Unsupported Configuration CBOR object is self-contained and 1065 enables the (6LBR) pledge to signal any parameters that the 1066 implementation of the networking stack may not support. A (6LBR) 1067 pledge MUST NOT attempt more than COJP_MAX_JOIN_ATTEMPTS number of 1068 attempts to join if the processing of the Join Response message fails 1069 each time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached 1070 without success, the (6LBR) pledge SHOULD signal the presence of an 1071 error condition, through some out-of-band mechanism. 1073 Note that COJP_MAX_JOIN_ATTEMPTS relates to the application-level 1074 handling of the CoAP response and is different from CoAP's 1075 MAX_RETRANSMIT setting that drives the retransmission mechanism of 1076 the underlying CoAP message. 1078 8.3.2. Diagnostic Response Message 1080 The Diagnostic Response message is returned for any CoJP request when 1081 the processing of the payload failed. The Diagnostic Response 1082 message is protected by OSCORE as any other CoJP protocol message. 1084 The Diagnostic Response message SHALL be mapped to a CoAP response: 1086 o The response Code is 4.00 (Bad Request). 1088 o The payload is an Unsupported Configuration CBOR object, as 1089 defined in Section 8.4.5, containing more information about the 1090 parameter that triggered the sending of this message. 1092 8.3.3. Failure Handling 1094 The Parameter Update exchange may be triggered at any time during the 1095 network lifetime, which may span several years. During this period, 1096 it may occur that a joined node or the JRC experience unexpected 1097 events such as reboots or complete failures. 1099 This document mandates that the mutable parameters in the security 1100 context are written to persistent memory (see Section 7.3.1) by both 1101 the JRC and pledges (joined nodes). As the joined node (pledge) is 1102 typically a constrained device that handles the write operations to 1103 persistent memory in a predictable manner, the retrieval of mutable 1104 security context parameters is feasible across reboots such that 1105 there is no risk of AEAD nonce reuse due to reinitialized Sender 1106 Sequence numbers, or of a replay attack due to the reinitialized 1107 replay window. JRC may be hosted on a generic machine where the 1108 write operation to persistent memory may lead to unpredictable delays 1109 due to caching. In case of a reboot event at JRC occurring before 1110 the cached data is written to persistent memory, the loss of mutable 1111 security context parameters is likely which consequently poses the 1112 risk of AEAD nonce reuse. 1114 In the event of a complete device failure, where the mutable security 1115 context parameters cannot be retrieved, it is expected that a failed 1116 joined node is replaced with a new physical device, using a new 1117 pledge identifier and a PSK. When such a failure event occurs at the 1118 JRC, it is possible that the static information on provisioned 1119 pledges, like PSKs and pledge identifiers, can be retrieved through 1120 available backups. However, it is likely that the information about 1121 joined nodes, their assigned short identifiers and mutable security 1122 context parameters is lost. If this is the case, during the process 1123 of JRC reinitialization, the network administrator MUST force through 1124 out-of-band means all the networks managed by the failed JRC to 1125 rejoin, through e.g. the reinitialization of the 6LBR nodes and 1126 freshly generated dynamic cryptographic keys and other parameters 1127 that have influence on the security properties of the network. 1129 In order to recover from such a failure event, the reinitialized JRC 1130 can trigger the renegotiation of the OSCORE security context through 1131 the procedure described in Appendix B.2 of [RFC8613]. Aware of the 1132 failure event, the reinitialized JRC responds to the first join 1133 request of each pledge it is managing with a 4.01 Unauthorized error 1134 and a random nonce. The pledge verifies the error response and then 1135 initiates the CoJP join exchange using a new OSCORE security context 1136 derived from an ID Context consisting of the concatenation of two 1137 nonces, one that it received from the JRC and the other that the 1138 pledge generates locally. After verifying the join request with the 1139 new ID Context and the derived OSCORE security context, the JRC 1140 should consequently take action in mapping the new ID Context with 1141 the previously used pledge identifier. How JRC handles this mapping 1142 is out of scope of this document. 1144 The described procedure is specified in Appendix B.2 of [RFC8613] and 1145 is RECOMMENDED in order to handle the failure events or any other 1146 event that may lead to the loss of mutable security context 1147 parameters. The length of nonces exchanged using this procedure MUST 1148 be at least 8 bytes. 1150 The procedure does require both the pledge and the JRC to have good 1151 sources of randomness. While this is typically not an issue at the 1152 JRC side, the constrained device hosting the pledge may pose 1153 limitations in this regard. If the procedure outlined in 1154 Appendix B.2 of [RFC8613] is not supported by the pledge, the network 1155 administrator MUST take action in reprovisioning the concerned 1156 devices with freshly generated parameters, through out-of-band means. 1158 8.4. CoJP Objects 1160 This section specifies the structure of CoJP CBOR objects that may be 1161 carried as the payload of CoJP messages. Some of these objects may 1162 be received both as part of the CoJP join exchange when the device 1163 operates as a (CoJP) pledge, or the parameter update exchange, when 1164 the device operates as a joined (6LBR) node. 1166 8.4.1. Join Request Object 1168 The Join_Request structure is built on a CBOR map object. 1170 The set of parameters that can appear in a Join_Request object is 1171 summarized below. The labels can be found in the "CoJP Parameters" 1172 registry Section 11.1. 1174 o role: The identifier of the role that the pledge requests to play 1175 in the network once it joins, encoded as an unsigned integer. 1176 Possible values are specified in Table 2. This parameter MAY be 1177 included. In case the parameter is omitted, the default value of 1178 0, i.e. the role "6TiSCH Node", MUST be assumed. 1180 o network identifier: The identifier of the network, as discussed in 1181 Section 3, encoded as a CBOR byte string. When present in the 1182 Join_Request, it hints to the JRC the network that the pledge is 1183 requesting to join, enabling the JRC to manage multiple networks. 1184 The pledge obtains the value of the network identifier from the 1185 received EB frames. This parameter MUST be included in a 1186 Join_Request object regardless of the role parameter value. 1188 o unsupported configuration: The identifier of the parameters that 1189 are not supported by the implementation, encoded as an 1190 Unsupported_Configuration object described in Section 8.4.5. This 1191 parameter MAY be included. If a (6LBR) pledge previously 1192 attempted to join and received a valid Join Response message over 1193 OSCORE, but failed to act on its payload (Configuration object), 1194 it SHOULD include this parameter to facilitate the recovery and 1195 debugging. 1197 Table 1 summarizes the parameters that may appear in a Join_Request 1198 object. 1200 +---------------------------+-------+------------------+ 1201 | Name | Label | CBOR Type | 1202 +---------------------------+-------+------------------+ 1203 | role | 1 | unsigned integer | 1204 | | | | 1205 | network identifier | 5 | byte string | 1206 | | | | 1207 | unsupported configuration | 8 | array | 1208 +---------------------------+-------+------------------+ 1210 Table 1: Summary of Join_Request parameters. 1212 The CDDL fragment that represents the text above for the Join_Request 1213 follows. 1215 Join_Request = { 1216 ? 1 : uint, ; role 1217 5 : bstr, ; network identifier 1218 ? 8 : Unsupported_Configuration ; unsupported configuration 1219 } 1221 +--------+-------+-------------------------------------+------------+ 1222 | Name | Value | Description | Reference | 1223 +--------+-------+-------------------------------------+------------+ 1224 | 6TiSCH | 0 | The pledge requests to play the | [[this | 1225 | Node | | role of a regular 6TiSCH node, i.e. | document]] | 1226 | | | non-6LBR node. | | 1227 | | | | | 1228 | 6LBR | 1 | The pledge requests to play the | [[this | 1229 | | | role of 6LoWPAN Border Router | document]] | 1230 | | | (6LBR). | | 1231 +--------+-------+-------------------------------------+------------+ 1233 Table 2: Role values. 1235 8.4.2. Configuration Object 1237 The Configuration structure is built on a CBOR map object. The set 1238 of parameters that can appear in a Configuration object is summarized 1239 below. The labels can be found in "CoJP Parameters" registry 1240 Section 11.1. 1242 o link-layer key set: An array encompassing a set of cryptographic 1243 keys and their identifiers that are currently in use in the 1244 network, or that are scheduled to be used in the future. The 1245 encoding of individual keys is described in Section 8.4.3. The 1246 link-layer key set parameter MAY be included in a Configuration 1247 object. When present, the link-layer key set parameter MUST 1248 contain at least one key. This parameter is also used to 1249 implement rekeying in the network. How the keys are installed and 1250 used differs for the 6LBR and other (regular) nodes, and this is 1251 explained in Section 8.4.3.1 and Section 8.4.3.2. 1253 o short identifier: a compact identifier assigned to the pledge. 1254 The short identifier structure is described in Section 8.4.4. The 1255 short identifier parameter MAY be included in a Configuration 1256 object. 1258 o JRC address: the IPv6 address of the JRC, encoded as a byte 1259 string, with the length of 16 bytes. If the length of the byte 1260 string is different from 16, the parameter MUST be discarded. If 1261 the JRC is not co-located with the 6LBR and has a different IPv6 1262 address than the 6LBR, this parameter MUST be included. In the 1263 special case where the JRC is co-located with the 6LBR and has the 1264 same IPv6 address as the 6LBR, this parameter MAY be included. If 1265 the JRC address parameter is not present in the Configuration 1266 object, this indicates that the JRC has the same IPv6 address as 1267 the 6LBR. The joined node can then discover the IPv6 address of 1268 the JRC through network control traffic. See Section 6. 1270 o blacklist: An array encompassing a list of pledge identifiers that 1271 are blacklisted by the JRC, with each pledge identifier encoded as 1272 a byte string. The blacklist parameter MAY be included in a 1273 Configuration object. When present, the array MUST contain zero 1274 or more byte strings encoding pledge identifiers. The joined node 1275 MUST silently drop any link-layer frames originating from the 1276 pledge identifiers enclosed in the blacklist parameter. When this 1277 parameter is received, its value MUST overwrite any previously set 1278 values. This parameter allows the JRC to configure the node 1279 acting as a JP to filter out traffic from misconfigured or 1280 malicious pledges before their traffic is forwarded into the 1281 network. If the JRC decides to remove a given pledge identifier 1282 from a blacklist, it omits the pledge identifier in the blacklist 1283 parameter value it sends next. Since the blacklist parameter 1284 carries the pledge identifiers, privacy considerations apply. See 1285 Section 10. 1287 o join rate: Average data rate (in units of bytes/second) of join 1288 traffic forwarded into the network that should not be exceeded 1289 when a joined node operates as a JP, encoded as an unsigned 1290 integer. The join rate parameter MAY be included in a 1291 Configuration object. This parameter allows the JRC to configure 1292 different nodes in the network to operate as JP, and act in case 1293 of an attack by throttling the rate at which JP forwards 1294 unauthenticated traffic into the network. When this parameter is 1295 present in a Configuration object, the value MUST be used to set 1296 the PROBING_RATE of CoAP at the joined node for communication with 1297 the JRC. In case this parameter is set to zero, a joined node 1298 MUST silently drop any join traffic coming from unauthenticated 1299 pledges. In case this parameter is omitted, the value of positive 1300 infinity SHOULD be assumed. Node operating as a JP MAY use 1301 another mechanism that is out of scope of this specification to 1302 configure PROBING_RATE of CoAP in the absence of a join rate 1303 parameter from the Configuration object. 1305 Table 3 summarizes the parameters that may appear in a Configuration 1306 object. 1308 +--------------------+-------+------------------+ 1309 | Name | Label | CBOR Type | 1310 +--------------------+-------+------------------+ 1311 | link-layer key set | 2 | array | 1312 | | | | 1313 | short identifier | 3 | array | 1314 | | | | 1315 | JRC address | 4 | byte string | 1316 | | | | 1317 | blacklist | 6 | array | 1318 | | | | 1319 | join rate | 7 | unsigned integer | 1320 +--------------------+-------+------------------+ 1322 Table 3: Summary of Configuration parameters. 1324 The CDDL fragment that represents the text above for the 1325 Configuration follows. Structures Link_Layer_Key and 1326 Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. 1328 Configuration = { 1329 ? 2 : [ +Link_Layer_Key ], ; link-layer key set 1330 ? 3 : Short_Identifier, ; short identifier 1331 ? 4 : bstr, ; JRC address 1332 ? 6 : [ *bstr ], ; blacklist 1333 ? 7 : uint ; join rate 1334 } 1335 +---------------+-------+----------+-------------------+------------+ 1336 | Name | Label | CBOR | Description | Reference | 1337 | | | type | | | 1338 +---------------+-------+----------+-------------------+------------+ 1339 | role | 1 | unsigned | Identifies the | [[this | 1340 | | | integer | role parameter | document]] | 1341 | | | | | | 1342 | link-layer | 2 | array | Identifies the | [[this | 1343 | key set | | | array carrying | document]] | 1344 | | | | one or more link- | | 1345 | | | | level | | 1346 | | | | cryptographic | | 1347 | | | | keys | | 1348 | | | | | | 1349 | short | 3 | array | Identifies the | [[this | 1350 | identifier | | | assigned short | document]] | 1351 | | | | identifier | | 1352 | | | | | | 1353 | JRC address | 4 | byte | Identifies the | [[this | 1354 | | | string | IPv6 address of | document]] | 1355 | | | | the JRC | | 1356 | | | | | | 1357 | network | 5 | byte | Identifies the | [[this | 1358 | identifier | | string | network | document]] | 1359 | | | | identifier | | 1360 | | | | parameter | | 1361 | | | | | | 1362 | blacklist | 6 | array | Identifies the | [[this | 1363 | | | | blacklist | document]] | 1364 | | | | parameter | | 1365 | | | | | | 1366 | join rate | 7 | unsigned | Identifier the | [[this | 1367 | | | integer | join rate | document]] | 1368 | | | | parameter | | 1369 | | | | | | 1370 | unsupported | 8 | array | Identifies the | [[this | 1371 | configuration | | | unsupported | document]] | 1372 | | | | configuration | | 1373 | | | | parameter | | 1374 +---------------+-------+----------+-------------------+------------+ 1376 Table 4: CoJP parameters map labels. 1378 8.4.3. Link-Layer Key 1380 The Link_Layer_Key structure encompasses the parameters needed to 1381 configure the link-layer security module: the key identifier; the 1382 value of the cryptographic key; the link-layer algorithm identifier 1383 and the security level and the frame types that it should be used 1384 with, both for outgoing and incoming security operations; and any 1385 additional information that may be needed to configure the key. 1387 For encoding compactness, the Link_Layer_Key object is not enclosed 1388 in a top-level CBOR object. Rather, it is transported as a sequence 1389 of CBOR elements [I-D.ietf-cbor-sequence], some being optional. 1391 The set of parameters that can appear in a Link_Layer_Key object is 1392 summarized below, in order: 1394 o key_id: The identifier of the key, encoded as a CBOR unsigned 1395 integer. This parameter MUST be included. If the decoded CBOR 1396 unsigned integer value is larger than the maximum link-layer key 1397 identifier, the key is considered invalid. In case the key is 1398 considered invalid, the key MUST be discarded and the 1399 implementation MUST signal the error as specified in 1400 Section 8.3.1. 1402 o key_usage: The identifier of the link-layer algorithm, security 1403 level and link-layer frame types that can be used with the key, 1404 encoded as an integer. This parameter MAY be included. Possible 1405 values and the corresponding link-layer settings are specified in 1406 IANA "CoJP Key Usage" registry (Section 11.2). In case the 1407 parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC- 1408 MIC32) from Table 5 MUST be assumed. This default value has been 1409 chosen such that it results in byte savings in the most 1410 constrained settings but does not imply a recommendation for its 1411 general usage. 1413 o key_value: The value of the cryptographic key, encoded as a byte 1414 string. This parameter MUST be included. If the length of the 1415 byte string is different than the corresponding key length for a 1416 given algorithm specified by the key_usage parameter, the key MUST 1417 be discarded and the implementation MUST signal the error as 1418 specified in Section 8.3.1. 1420 o key_addinfo: Additional information needed to configure the link- 1421 layer key, encoded as a byte string. This parameter MAY be 1422 included. The processing of this parameter is dependent on the 1423 link-layer technology in use and a particular keying mode. 1425 To be able to decode the keys that are present in the link-layer key 1426 set, and to identify individual parameters of a single Link_Layer_Key 1427 object, the CBOR decoder needs to differentiate between elements 1428 based on the CBOR type. For example, a uint that follows a byte 1429 string signals to the decoder that a new Link_Layer_Key object is 1430 being processed. 1432 The CDDL fragment that represents the text above for the 1433 Link_Layer_Key follows. 1435 Link_Layer_Key = ( 1436 key_id : uint, 1437 ? key_usage : int, 1438 key_value : bstr, 1439 ? key_addinfo : bstr, 1440 ) 1442 +-----------------+-----+------------------+-------------+----------+ 1443 | Name | Val | Algorithm | Description | Referenc | 1444 | | ue | | | e | 1445 +-----------------+-----+------------------+-------------+----------+ 1446 | 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | 1447 | -ENC-MIC32 | | CCM-128 | for EBs, | ocument] | 1448 | | | | ENC-MIC-32 | ] | 1449 | | | | for DATA | | 1450 | | | | and ACKNOWL | | 1451 | | | | EDGMENT. | | 1452 | | | | | | 1453 | 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | 1454 | -ENC-MIC64 | | CCM-128 | for EBs, | ocument] | 1455 | | | | ENC-MIC-64 | ] | 1456 | | | | for DATA | | 1457 | | | | and ACKNOWL | | 1458 | | | | EDGMENT. | | 1459 | | | | | | 1460 | 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | 1461 | -ENC-MIC128 | | CCM-128 | for EBs, | ocument] | 1462 | | | | ENC-MIC-128 | ] | 1463 | | | | for DATA | | 1464 | | | | and ACKNOWL | | 1465 | | | | EDGMENT. | | 1466 | | | | | | 1467 | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | 1468 | K1K2-MIC32 | | CCM-128 | for EBs, | ocument] | 1469 | | | | DATA and AC | ] | 1470 | | | | KNOWLEDGMEN | | 1471 | | | | T. | | 1472 | | | | | | 1473 | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | 1474 | K1K2-MIC64 | | CCM-128 | for EBs, | ocument] | 1475 | | | | DATA and AC | ] | 1476 | | | | KNOWLEDGMEN | | 1477 | | | | T. | | 1478 | | | | | | 1479 | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | 1480 | K1K2-MIC128 | | CCM-128 | for EBs, | ocument] | 1481 | | | | DATA and AC | ] | 1482 | | | | KNOWLEDGMEN | | 1483 | | | | T. | | 1484 | | | | | | 1485 | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | 1486 | | | CCM-128 | for EBs. | ocument] | 1487 | | | | | ] | 1488 | | | | | | 1489 | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | 1490 | | | CCM-128 | for EBs. | ocument] | 1491 | | | | | ] | 1492 | | | | | | 1493 | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | 1494 | 8 | | CCM-128 | for EBs. | ocument] | 1495 | | | | | ] | 1496 | | | | | | 1497 | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | 1498 | | | CCM-128 | for DATA | ocument] | 1499 | | | | and ACKNOWL | ] | 1500 | | | | EDGMENT. | | 1501 | | | | | | 1502 | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | 1503 | | | CCM-128 | for DATA | ocument] | 1504 | | | | and ACKNOWL | ] | 1505 | | | | EDGMENT. | | 1506 | | | | | | 1507 | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | 1508 | 8 | | CCM-128 | for DATA | ocument] | 1509 | | | | and ACKNOWL | ] | 1510 | | | | EDGMENT. | | 1511 | | | | | | 1512 | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | 1513 | MIC32 | | CCM-128 | MIC-32 for | ocument] | 1514 | | | | DATA and AC | ] | 1515 | | | | KNOWLEDGMEN | | 1516 | | | | T. | | 1517 | | | | | | 1518 | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | 1519 | MIC64 | | CCM-128 | MIC-64 for | ocument] | 1520 | | | | DATA and AC | ] | 1521 | | | | KNOWLEDGMEN | | 1522 | | | | T. | | 1523 | | | | | | 1524 | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | 1525 | MIC128 | | CCM-128 | MIC-128 for | ocument] | 1526 | | | | DATA and AC | ] | 1527 | | | | KNOWLEDGMEN | | 1528 | | | | T. | | 1529 +-----------------+-----+------------------+-------------+----------+ 1531 Table 5: Key Usage values. 1533 8.4.3.1. Rekeying of (6LoWPAN) Border Routers (6LBR) 1535 When the 6LoWPAN Border Router (6LBR) receives the Configuration 1536 object containing a link-layer key set, it MUST immediately install 1537 and start using the new keys for all outgoing traffic, and remove any 1538 old keys it has installed from the previous key set after a delay of 1539 COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the 1540 JRC to force the 6LBR to start sending traffic with the new key. The 1541 decision is taken by the JRC when it has determined that the new key 1542 has been made available to all (or some overwhelming majority) of 1543 nodes. Any node that the JRC has not yet reached at that point is 1544 either non-functional or in extended sleep such that it will not be 1545 reached. To get the key update, such node needs to go through the 1546 join process anew. 1548 8.4.3.2. Rekeying of regular (6LoWPAN) Nodes (6LN) 1550 When a regular 6LN node receives the Configuration object with a 1551 link-layer key set, it MUST install the new keys. The 6LN will use 1552 both the old and the new keys to decrypt and authenticate any 1553 incoming traffic that arrives based upon the key identifier in the 1554 packet. It MUST continue to use the old keys for all outgoing 1555 traffic until it has detected that the network has switched to the 1556 new key set. 1558 The detection of network switch is based upon the receipt of traffic 1559 secured with the new keys. Upon reception and successful security 1560 processing of a link-layer frame secured with a key from the new key 1561 set, a 6LN node MUST then switch to sending outgoing traffic using 1562 the keys from the new set for all outgoing traffic. The 6LN node 1563 MUST remove any old keys it has installed from the previous key set 1564 after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts 1565 using the new key set. 1567 Sending of traffic with the new keys signals to other downstream 1568 nodes to switch to their new key, and the effect is that there is a 1569 ripple of key updates around each 6LBR. 1571 8.4.3.3. Use in IEEE Std 802.15.4 1573 When Link_Layer_Key is used in the context of [IEEE802.15.4], the 1574 following considerations apply. 1576 Signaling of different keying modes of [IEEE802.15.4] is done based 1577 on the parameter values present in a Link_Layer_Key object. For 1578 instance, the value of the key_id parameter in combination with 1579 key_addinfo denotes which of the four Key ID modes of [IEEE802.15.4] 1580 is used and how. 1582 o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be 1583 set to 0. key_addinfo parameter MUST be present. key_addinfo 1584 parameter MUST be set to the link-layer address(es) of a single 1585 peer with whom the key should be used. Depending on the 1586 configuration of the network, key_addinfo may carry the peer's 1587 long link-layer address (i.e. pledge identifier), short link-layer 1588 address, or their concatenation with the long address being 1589 encoded first. Which address type(s) is carried is determined 1590 from the length of the byte string. 1592 o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a 1593 value different than 0. key_addinfo parameter MUST NOT be present. 1595 o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter 1596 MUST be set to a value different than 0. key_addinfo parameter 1597 MUST be present. key_addinfo parameter MUST be set to a byte 1598 string, exactly 4 bytes long. key_addinfo parameter carries the 1599 Key Source parameter used to configure [IEEE802.15.4]. 1601 o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter 1602 MUST be set to a value different than 0. key_addinfo parameter 1603 MUST be present. key_addinfo parameter MUST be set to a byte 1604 string, exactly 8 bytes long. key_addinfo parameter carries the 1605 Key Source parameter used to configure [IEEE802.15.4]. 1607 In all cases, key_usage parameter determines how a particular key 1608 should be used in respect to incoming and outgoing security policies. 1610 For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" 1611 parameter of [IEEE802.15.4] that is signaled in all outgoing frames 1612 secured with a given key. The maximum value key_id can have is 254. 1613 The value of 255 is reserved in [IEEE802.15.4] and is therefore 1614 considered invalid. 1616 Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a 1617 trusted third party and assign pairwise keys between nodes in the 1618 network. How JRC learns about the network topology is out of scope 1619 of this specification, but could be done through 6LBR - JRC signaling 1620 for example. Pairwise keys could also be derived through a key 1621 agreement protocol executed between the peers directly, where the 1622 authentication is based on the symmetric cryptographic material 1623 provided to both peers by the JRC. Such a protocol is out of scope 1624 of this specification. 1626 Implementations MUST use different link-layer keys when using 1627 different authentication tag (MIC) lengths, as using the same key 1628 with different authentication tag lengths might be unsafe. For 1629 example, this prohibits the usage of the same key for both MIC-32 and 1630 MIC-64 levels. See Annex B.4.3 of [IEEE802.15.4] for more 1631 information. 1633 8.4.4. Short Identifier 1635 The Short_Identifier object represents an identifier assigned to the 1636 pledge. It is encoded as a CBOR array object, containing, in order: 1638 o identifier: The short identifier assigned to the pledge, encoded 1639 as a byte string. This parameter MUST be included. The 1640 identifier MUST be unique in the set of all identifiers assigned 1641 in a network that is managed by a JRC. In case the identifier is 1642 invalid, the decoder MUST silently ignore the Short_Identifier 1643 object. 1645 o lease_time: The validity of the identifier in hours after the 1646 reception of the CBOR object, encoded as a CBOR unsigned integer. 1647 This parameter MAY be included. The node MUST stop using the 1648 assigned short identifier after the expiry of the lease_time 1649 interval. It is up to the JRC to renew the lease before the 1650 expiry of the previous interval. The JRC updates the lease by 1651 executing the Parameter Update exchange with the node and 1652 including the Short_Identifier in the Configuration object, as 1653 described in Section 8.2. In case the lease expires, the node 1654 SHOULD initiate a new join exchange, as described in Section 8.1. 1655 In case this parameter is omitted, the value of positive infinity 1656 MUST be assumed, meaning that the identifier is valid for as long 1657 as the node participates in the network. 1659 The CDDL fragment that represents the text above for the 1660 Short_Identifier follows. 1662 Short_Identifier = [ 1663 identifier : bstr, 1664 ? lease_time : uint 1665 ] 1667 8.4.4.1. Use in IEEE Std 802.15.4 1669 When Short_Identifier is used in the context of [IEEE802.15.4], the 1670 following considerations apply. 1672 The identifier MUST be used to set the short address of IEEE Std 1673 802.15.4 module. When operating in TSCH mode, the identifier MUST be 1674 unique in the set of all identifiers assigned in multiple networks 1675 that share link-layer key(s). If the length of the byte string 1676 corresponding to the identifier parameter is different than 2, the 1677 identifier is considered invalid. The values 0xfffe and 0xffff are 1678 reserved by [IEEE802.15.4] and their use is considered invalid. 1680 The security properties offered by the [IEEE802.15.4] link-layer in 1681 TSCH mode are conditioned on the uniqueness requirement of the short 1682 identifier (i.e. short address). The short address is one of the 1683 inputs in the construction of the nonce, which is used to protect 1684 link-layer frames. If a misconfiguration occurs, and the same short 1685 address is assigned twice under the same link-layer key, the loss of 1686 security properties is imminent. For this reason, practices where 1687 the pledge generates the short identifier locally are not safe and 1688 are likely to result in the loss of link-layer security properties. 1690 The JRC MUST ensure that at any given time there are never two same 1691 short identifiers being used under the same link-layer key. If the 1692 lease_time parameter of a given Short_Identifier object is set to 1693 positive infinity, care needs to be taken that the corresponding 1694 identifier is not assigned to another node until the JRC is certain 1695 that it is no longer in use, potentially through out-of-band 1696 signaling. If the lease_time parameter expires for any reason, the 1697 JRC should take into consideration potential ongoing transmissions by 1698 the joined node, which may be hanging in the queues, before assigning 1699 the same identifier to another node. 1701 Care needs to be taken on how the pledge (joined node) configures the 1702 expiration of the lease. Since units of the lease_time parameter are 1703 in hours after the reception of the CBOR object, the pledge needs to 1704 convert the received time to the corresponding absolute slot number 1705 in the network. The joined node (pledge) MUST only use the absolute 1706 slot number as the appropriate reference of time to determine whether 1707 the assigned short identifier is still valid. 1709 8.4.5. Unsupported Configuration Object 1711 The Unsupported_Configuration object is encoded as a CBOR array, 1712 containing at least one Unsupported_Parameter object. Each 1713 Unsupported_Parameter object is a sequence of CBOR elements without 1714 an enclosing top-level CBOR object for compactness. The set of 1715 parameters that appear in an Unsupported_Parameter object is 1716 summarized below, in order: 1718 o code: Indicates the capability of acting on the parameter signaled 1719 by parameter_label, encoded as an integer. This parameter MUST be 1720 included. Possible values of this parameter are specified in the 1721 IANA "CoJP Unsupported Configuration Code Registry" 1722 (Section 11.3). 1724 o parameter_label: Indicates the parameter. This parameter MUST be 1725 included. Possible values of this parameter are specified in the 1726 label column of the IANA "CoJP Parameters" registry 1727 (Section 11.1). 1729 o parameter_addinfo: Additional information about the parameter that 1730 cannot be acted upon. This parameter MUST be included. In case 1731 the code is set to "Unsupported", parameter_addinfo gives 1732 additional information to the JRC. If the parameter indicated by 1733 parameter_label cannot be acted upon regardless of its value, 1734 parameter_addinfo MUST be set to null, signaling to the JRC that 1735 it SHOULD NOT attempt to configure the parameter again. If the 1736 pledge can act on the parameter, but cannot configure the setting 1737 indicated by the parameter value, the pledge can hint this to the 1738 JRC. In this case, parameter_addinfo MUST be set to the value of 1739 the parameter that cannot be acted upon following the normative 1740 parameter structure specified in this document. For example, it 1741 is possible to include the link-layer key set object, signaling a 1742 subset of keys that cannot be acted upon, or the entire key set 1743 that was received. In that case, the value of the 1744 parameter_addinfo follows the link-layer key set structure defined 1745 in Section 8.4.2. In case the code is set to "Malformed", 1746 parameter_addinfo MUST be set to null, signaling to the JRC that 1747 it SHOULD NOT attempt to configure the parameter again. 1749 The CDDL fragment that represents the text above for 1750 Unsupported_Configuration and Unsupported_Parameter objects follows. 1752 Unsupported_Configuration = [ 1753 + parameter : Unsupported_Parameter 1754 ] 1756 Unsupported_Parameter = ( 1757 code : int, 1758 parameter_label : int, 1759 parameter_addinfo : nil / any 1760 ) 1761 +-------------+-------+--------------------------------+------------+ 1762 | Name | Value | Description | Reference | 1763 +-------------+-------+--------------------------------+------------+ 1764 | Unsupported | 0 | The indicated setting is not | [[this | 1765 | | | supported by the networking | document]] | 1766 | | | stack implementation. | | 1767 | | | | | 1768 | Malformed | 1 | The indicated parameter value | [[this | 1769 | | | is malformed. | document]] | 1770 +-------------+-------+--------------------------------+------------+ 1772 Table 6: Unsupported Configuration code values. 1774 8.5. Recommended Settings 1776 This section gives RECOMMENDED values of CoJP settings. 1778 +--------------------------+---------------+ 1779 | Name | Default Value | 1780 +--------------------------+---------------+ 1781 | COJP_MAX_JOIN_ATTEMPTS | 4 | 1782 | | | 1783 | COJP_REKEYING_GUARD_TIME | 12 seconds | 1784 +--------------------------+---------------+ 1786 Recommended CoJP settings. 1788 The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible 1789 retransmissions at the link layer due to imperfect wireless links. 1791 9. Security Considerations 1793 Since this document uses the pledge identifier to set the ID Context 1794 parameter of OSCORE, an important security requirement is that the 1795 pledge identifier is unique in the set of all pledge identifiers 1796 managed by a JRC. The uniqueness of the pledge identifier ensures 1797 unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also 1798 allows the JRC to retrieve the correct security context, upon the 1799 reception of a Join Request message. The management of pledge 1800 identifiers is simplified if the globally unique EUI-64 is used, but 1801 this comes with privacy risks, as discussed in Section 10. 1803 This document further mandates that the (6LBR) pledge and the JRC are 1804 provisioned with unique PSKs. While the process of provisioning PSKs 1805 to all pledges can result in a substantial operational overhead, it 1806 is vital to do so for the security properties of the network. The 1807 PSK is used to set the OSCORE Master Secret during security context 1808 derivation. This derivation process results in OSCORE keys that are 1809 important for mutual authentication of the (6LBR) pledge and the JRC. 1810 The resulting security context shared between the pledge (joined 1811 node) and the JRC is used for the purpose of joining and is long- 1812 lived in that it can be used throughout the lifetime of a joined node 1813 for parameter update exchanges. Should an attacker come to know the 1814 PSK, then a man-in-the-middle attack is possible. 1816 Note that while OSCORE provides replay protection, it does not 1817 provide an indication of freshness in the presence of an attacker 1818 that can drop/reorder traffic. Since the join request contains no 1819 randomness, and the sequence number is predictable, the JRC could in 1820 principle anticipate a join request from a particular pledge and pre- 1821 calculate the response. In such a scenario, the JRC does not have to 1822 be alive at the time when the request is received. This could be 1823 relevant in case the JRC was temporarily compromised and control 1824 subsequently regained by the legitimate owner. 1826 It is of utmost importance to avoid unsafe practices when generating 1827 and provisioning PSKs. The use of a single PSK shared among a group 1828 of devices is a common pitfall that results in poor security. In 1829 this case, the compromise of a single device is likely to lead to a 1830 compromise of the entire batch, with the attacker having the ability 1831 to impersonate a legitimate device and join the network, generate 1832 bogus data and disturb the network operation. Additionally, some 1833 vendors use methods such as scrambling or hashing of device serial 1834 numbers or their EUI-64 to generate "unique" PSKs. Without any 1835 secret information involved, the effort that the attacker needs to 1836 invest into breaking these unsafe derivation methods is quite low, 1837 resulting in the possible impersonation of any device from the batch, 1838 without even needing to compromise a single device. The use of 1839 cryptographically secure random number generators to generate the PSK 1840 is RECOMMENDED, see [NIST800-90A] for different mechanisms using 1841 deterministic methods. 1843 The JP forwards the unauthenticated join traffic into the network. A 1844 data cap on the JP prevents it from forwarding more traffic than the 1845 network can handle and enables throttling in case of an attack. Note 1846 that this traffic can only be directed at the JRC so that the JRC 1847 needs to be prepared to handle such unsanitized inputs. The data cap 1848 can be configured by the JRC by including a join rate parameter in 1849 the Join Response and it is implemented through the CoAP's 1850 PROBING_RATE setting. The use of a data cap at a JP forces attackers 1851 to use more than one JP if they wish to overwhelm the network. 1852 Marking the join traffic packets with a non-zero DSCP allows the 1853 network to carry the traffic if it has capacity, but encourages the 1854 network to drop the extra traffic rather than add bandwidth due to 1855 that traffic. 1857 The shared nature of the "minimal" cell used for the join traffic 1858 makes the network prone to a DoS attack by congesting the JP with 1859 bogus traffic. Such an attacker is limited by its maximum transmit 1860 power. The redundancy in the number of deployed JPs alleviates the 1861 issue and also gives the pledge a possibility to use the best 1862 available link for joining. How a network node decides to become a 1863 JP is out of scope of this specification. 1865 At the beginning of the join process, the pledge has no means of 1866 verifying the content in the EB, and has to accept it at "face 1867 value". In case the pledge tries to join an attacker's network, the 1868 Join Response message will either fail the security check or time 1869 out. The pledge may implement a temporary blacklist in order to 1870 filter out undesired EBs and try to join using the next seemingly 1871 valid EB. This blacklist alleviates the issue, but is effectively 1872 limited by the node's available memory. Note that this temporary 1873 blacklist is different from the one communicated as part of the CoJP 1874 Configuration object as it helps pledge fight a DoS attack. The 1875 bogus beacons prolong the join time of the pledge, and so the time 1876 spent in "minimal" [RFC8180] duty cycle mode. The blacklist 1877 communicated as part of the CoJP Configuration object helps JP fight 1878 a DoS attack by a malicious pledge. 1880 During the network lifetime, the JRC may at any time initiate a 1881 Parameter Update exchange with a joined node. The Parameter Update 1882 message uses the same OSCORE security context as is used for the join 1883 exchange, except that the server/client roles are interchanged. As a 1884 consequence, each Parameter Update message carries the well-known 1885 OSCORE Sender ID of the JRC. A passive attacker may use the OSCORE 1886 Sender ID to identify the Parameter Update traffic in case the link- 1887 layer protection does not provide confidentiality. A countermeasure 1888 against such traffic analysis attack is to use encryption at the 1889 link-layer. Note that the join traffic does not undergo link-layer 1890 protection at the first hop, as the pledge is not yet in possession 1891 of cryptographic keys. Similarly, enhanced beacon traffic in the 1892 network is not encrypted. This makes it easy for a passive attacker 1893 to identify these types of traffic. 1895 10. Privacy Considerations 1897 The join solution specified in this document relies on the uniqueness 1898 of the pledge identifier in the set of all pledge identifiers managed 1899 by a JRC. This identifier is transferred in clear as an OSCORE kid 1900 context. The use of the globally unique EUI-64 as pledge identifier 1901 simplifies the management but comes with certain privacy risks. The 1902 implications are thoroughly discussed in [RFC7721] and comprise 1903 correlation of activities over time, location tracking, address 1904 scanning and device-specific vulnerability exploitation. Since the 1905 join process occurs rarely compared to the network lifetime, long- 1906 term threats that arise from using EUI-64 as the pledge identifier 1907 are minimal. In addition, the Join Response message contains a short 1908 address which is assigned by the JRC to the (6LBR) pledge. The 1909 assigned short address SHOULD be uncorrelated with the long-term 1910 pledge identifier. The short address is encrypted in the response. 1911 Once the join process completes, the new node uses the short 1912 addresses for all further layer 2 (and layer-3) operations. This 1913 reduces the aforementioned privacy risks as the short layer-2 address 1914 (visible even when the network is encrypted) is not traceable between 1915 locations and does not disclose the manufacturer, as is the case of 1916 EUI-64. However, an eavesdropper with access to the radio medium 1917 during the join process may be able to correlate the assigned short 1918 address with the extended address based on timing information with a 1919 non-negligible probability. This probability decreases with an 1920 increasing number of pledges joining concurrently. 1922 11. IANA Considerations 1924 Note to RFC Editor: Please replace all occurrences of "[[this 1925 document]]" with the RFC number of this specification. 1927 This document allocates a well-known name under the .arpa name space 1928 according to the rules given in [RFC3172]. The name "6tisch.arpa" is 1929 requested. No subdomains are expected, and addition of any such 1930 subdomains requires the publication of an IETF standards-track RFC. 1931 No A, AAAA or PTR record is requested. 1933 11.1. CoJP Parameters Registry 1935 This section defines a sub-registry within the "IPv6 over the TSCH 1936 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1937 "Constrained Join Protocol Parameters Registry". 1939 The columns of the registry are: 1941 Name: This is a descriptive name that enables an easier reference to 1942 the item. It is not used in the encoding. 1944 Label: The value to be used to identify this parameter. The label is 1945 an integer. 1947 CBOR type: This field contains the CBOR type for the field. 1949 Description: This field contains a brief description for the field. 1951 Reference: This field contains a pointer to the public specification 1952 for the field, if one exists. 1954 This registry is to be populated with the values in Table 4. 1956 The amending formula for this sub-registry is: Different ranges of 1957 values use different registration policies [RFC8126]. Integer values 1958 from -256 to 255 are designated as Standards Action. Integer values 1959 from -65536 to -257 and from 256 to 65535 are designated as 1960 Specification Required. Integer values greater than 65535 are 1961 designated as Expert Review. Integer values less than -65536 are 1962 marked as Private Use. 1964 11.2. CoJP Key Usage Registry 1966 This section defines a sub-registry within the "IPv6 over the TSCH 1967 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1968 "Constrained Join Protocol Key Usage Registry". 1970 The columns of this registry are: 1972 Name: This is a descriptive name that enables easier reference to the 1973 item. The name MUST be unique. It is not used in the encoding. 1975 Value: This is the value used to identify the key usage setting. 1976 These values MUST be unique. The value is an integer. 1978 Algorithm: This is a descriptive name of the link-layer algorithm in 1979 use and uniquely determines the key length. The name is not used in 1980 the encoding. 1982 Description: This field contains a description of the key usage 1983 setting. The field should describe in enough detail how the key is 1984 to be used with different frame types, specific for the link-layer 1985 technology in question. 1987 Reference: This contains a pointer to the public specification for 1988 the field, if one exists. 1990 This registry is to be populated with the values in Table 5. 1992 The amending formula for this sub-registry is: Different ranges of 1993 values use different registration policies [RFC8126]. Integer values 1994 from -256 to 255 are designated as Standards Action. Integer values 1995 from -65536 to -257 and from 256 to 65535 are designated as 1996 Specification Required. Integer values greater than 65535 are 1997 designated as Expert Review. Integer values less than -65536 are 1998 marked as Private Use. 2000 11.3. CoJP Unsupported Configuration Code Registry 2002 This section defines a sub-registry within the "IPv6 over the TSCH 2003 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 2004 "Constrained Join Protocol Unsupported Configuration Code Registry". 2006 The columns of this registry are: 2008 Name: This is a descriptive name that enables easier reference to the 2009 item. The name MUST be unique. It is not used in the encoding. 2011 Value: This is the value used to identify the diagnostic code. These 2012 values MUST be unique. The value is an integer. 2014 Description: This is a descriptive human-readable name. The 2015 description MUST be unique. It is not used in the encoding. 2017 Reference: This contains a pointer to the public specification for 2018 the field, if one exists. 2020 This registry is to be populated with the values in Table 6. 2022 The amending formula for this sub-registry is: Different ranges of 2023 values use different registration policies [RFC8126]. Integer values 2024 from -256 to 255 are designated as Standards Action. Integer values 2025 from -65536 to -257 and from 256 to 65535 are designated as 2026 Specification Required. Integer values greater than 65535 are 2027 designated as Expert Review. Integer values less than -65536 are 2028 marked as Private Use. 2030 12. Acknowledgments 2032 The work on this document has been partially supported by the 2033 European Union's H2020 Programme for research, technological 2034 development and demonstration under grant agreements: No 644852, 2035 project ARMOUR; No 687884, project F-Interop and open-call project 2036 SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA. 2038 The following individuals provided input to this document (in 2039 alphabetic order): Christian Amsuss, Tengfei Chang, Klaus Hartke, 2040 Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal 2041 Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne. 2043 13. References 2044 13.1. Normative References 2046 [I-D.ietf-6tisch-architecture] 2047 Thubert, P., "An Architecture for IPv6 over the TSCH mode 2048 of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work 2049 in progress), October 2019. 2051 [I-D.ietf-core-stateless] 2052 Hartke, K., "Extended Tokens and Stateless Clients in the 2053 Constrained Application Protocol (CoAP)", draft-ietf-core- 2054 stateless-03 (work in progress), October 2019. 2056 [IEEE802.15.4] 2057 IEEE standard for Information Technology, ., "IEEE Std 2058 802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 2060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2061 Requirement Levels", BCP 14, RFC 2119, 2062 DOI 10.17487/RFC2119, March 1997, 2063 . 2065 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 2066 "Assured Forwarding PHB Group", RFC 2597, 2067 DOI 10.17487/RFC2597, June 1999, 2068 . 2070 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 2071 Requirements for the Address and Routing Parameter Area 2072 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 2073 September 2001, . 2075 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2076 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2077 October 2013, . 2079 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2080 Application Protocol (CoAP)", RFC 7252, 2081 DOI 10.17487/RFC7252, June 2014, 2082 . 2084 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 2085 RFC 7320, DOI 10.17487/RFC7320, July 2014, 2086 . 2088 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 2089 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 2090 Internet of Things (IoT): Problem Statement", RFC 7554, 2091 DOI 10.17487/RFC7554, May 2015, 2092 . 2094 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2095 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2096 March 2017, . 2098 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2099 Writing an IANA Considerations Section in RFCs", BCP 26, 2100 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2101 . 2103 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2104 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2105 . 2107 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2108 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2109 May 2017, . 2111 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2112 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2113 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2114 May 2017, . 2116 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2117 Perkins, "Registration Extensions for IPv6 over Low-Power 2118 Wireless Personal Area Network (6LoWPAN) Neighbor 2119 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2120 . 2122 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2123 "Object Security for Constrained RESTful Environments 2124 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2125 . 2127 13.2. Informative References 2129 [I-D.ietf-anima-grasp] 2130 Bormann, C., Carpenter, B., and B. Liu, "A Generic 2131 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 2132 grasp-15 (work in progress), July 2017. 2134 [I-D.ietf-cbor-cddl] 2135 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 2136 definition language (CDDL): a notational convention to 2137 express CBOR and JSON data structures", draft-ietf-cbor- 2138 cddl-08 (work in progress), March 2019. 2140 [I-D.ietf-cbor-sequence] 2141 Bormann, C., "Concise Binary Object Representation (CBOR) 2142 Sequences", draft-ietf-cbor-sequence-02 (work in 2143 progress), September 2019. 2145 [NIST800-90A] 2146 NIST Special Publication 800-90A, Revision 1, ., Barker, 2147 E., and J. Kelsey, "Recommendation for Random Number 2148 Generation Using Deterministic Random Bit Generators", 2149 2015. 2151 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 2152 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 2153 RFC 4231, DOI 10.17487/RFC4231, December 2005, 2154 . 2156 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2157 "Transmission of IPv6 Packets over IEEE 802.15.4 2158 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2159 . 2161 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2162 Uniform Resource Identifiers (URIs)", RFC 5785, 2163 DOI 10.17487/RFC5785, April 2010, 2164 . 2166 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2167 Key Derivation Function (HKDF)", RFC 5869, 2168 DOI 10.17487/RFC5869, May 2010, 2169 . 2171 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2172 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2173 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2174 Low-Power and Lossy Networks", RFC 6550, 2175 DOI 10.17487/RFC6550, March 2012, 2176 . 2178 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2179 DOI 10.17487/RFC6762, February 2013, 2180 . 2182 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2183 Considerations for IPv6 Address Generation Mechanisms", 2184 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2185 . 2187 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2188 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2189 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2190 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2191 . 2193 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 2194 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 2195 DOI 10.17487/RFC8480, November 2018, 2196 . 2198 Appendix A. Example 2200 Figure 3 illustrates a successful join protocol exchange. The pledge 2201 instantiates the OSCORE context and derives the OSCORE keys and 2202 nonces from the PSK. It uses the instantiated context to protect the 2203 Join Request addressed with a Proxy-Scheme option, the well-known 2204 host name of the JRC in the Uri-Host option, and its EUI-64 as pledge 2205 identifier and OSCORE kid context. Triggered by the presence of a 2206 Proxy-Scheme option, the JP forwards the request to the JRC and sets 2207 the CoAP token to the internally needed state. The JP has learned 2208 the IPv6 address of the JRC when it acted as a pledge and joined the 2209 network. Once the JRC receives the request, it looks up the correct 2210 context based on the kid context parameter. The OSCORE data 2211 authenticity verification ensures that the request has not been 2212 modified in transit. In addition, replay protection is ensured 2213 through persistent handling of mutable context parameters. 2215 Once the JP receives the Join Response, it authenticates the state 2216 within the CoAP token before deciding where to forward. The JP sets 2217 its internal state to that found in the token, and forwards the Join 2218 Response to the correct pledge. Note that the JP does not possess 2219 the key to decrypt the CoJP object (configuration) present in the 2220 payload. The Join Response is matched to the Join Request and 2221 verified for replay protection at the pledge using OSCORE processing 2222 rules. In this example, the Join Response does not contain the IPv6 2223 address of the JRC, the pledge hence understands the JRC is co- 2224 located with the 6LBR. 2226 <---E2E OSCORE--> 2227 Client Proxy Server 2228 Pledge JP JRC 2229 | | | 2230 | Join | | Code: 0.02 (POST) 2231 | Request | | Token: - 2232 +--------->| | Proxy-Scheme: coap 2233 | | | Uri-Host: 6tisch.arpa 2234 | | | OSCORE: kid: -, 2235 | | | kid_context: EUI-64, 2236 | | | Partial IV: 1 2237 | | | Payload: { Code: 0.02 (POST), 2238 | | | Uri-Path: "j", 2239 | | | join_request, } 2240 | | | 2241 | | Join | Code: 0.02 (POST) 2242 | | Request | Token: opaque state 2243 | +--------->| OSCORE: kid: -, 2244 | | | kid_context: EUI-64, 2245 | | | Partial IV: 1 2246 | | | Payload: { Code: 0.02 (POST), 2247 | | | Uri-Path: "j", 2248 | | | join_request, } 2249 | | | 2250 | | | 2251 | | Join | Code: 2.04 (Changed) 2252 | | Response | Token: opaque state 2253 | |<---------+ OSCORE: - 2254 | | | Payload: { Code: 2.04 (Changed), 2255 | | | configuration, } 2256 | | | 2257 | | | 2258 | Join | | Code: 2.04 (Changed) 2259 | Response | | Token: - 2260 |<---------+ | OSCORE: - 2261 | | | Payload: { Code: 2.04 (Changed), 2262 | | | configuration, } 2263 | | | 2265 Figure 3: Example of a successful join protocol exchange. { ... } 2266 denotes authenticated encryption, denotes the authentication 2267 tag. 2269 Where the join_request object is: 2271 join_request: 2272 { 2273 5 : h'cafe' / PAN ID of the network pledge is attempting to join / 2274 } 2276 Since the role parameter is not present, the default role of "6TiSCH 2277 Node" is implied. 2279 The join_request object encodes to h'a10542cafe' with a size of 5 2280 bytes. 2282 And the configuration object is: 2284 configuration: 2285 { 2286 2 : [ / link-layer key set / 2287 1, / key_id / 2288 h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / 2289 ], 2290 3 : [ / short identifier / 2291 h'af93' / assigned short address / 2292 ] 2293 } 2295 Since the key_usage parameter is not present in the link-layer key 2296 set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. 2297 Since key_addinfo parameter is not present and key_id is different 2298 than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since 2299 the lease_time parameter is not present in the short identifier 2300 object, the default value of positive infinity is implied. 2302 The configuration object encodes to 2304 h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size 2305 of 26 bytes. 2307 Appendix B. Lightweight Implementation Option 2309 In environments where optimizing the implementation footprint is 2310 important, it is possible to implement this specification without 2311 having the implementations of HKDF [RFC5869] and SHA [RFC4231] on 2312 constrained devices. HKDF and SHA are used during the OSCORE 2313 security context derivation phase. This derivation can also be done 2314 by the JRC or a provisioning device, on behalf of the (6LBR) pledge 2315 during the provisioning phase. In that case, the derived OSCORE 2316 security context parameters are written directly into the (6LBR) 2317 pledge, without requiring the PSK be provisioned to the (6LBR) 2318 pledge. 2320 The use of HKDF to derive OSCORE security context parameters ensures 2321 that the resulting OSCORE keys have good security properties, and are 2322 unique as long as the input for different pledges varies. This 2323 specification ensures the uniqueness by mandating unique pledge 2324 identifiers and a unique PSK for each (6LBR) pledge. From the AEAD 2325 nonce reuse viewpoint, having a unique pledge identifier is a 2326 sufficient condition. However, as discussed in Section 9, the use of 2327 a single PSK shared among many devices is a common security pitfall. 2328 The compromise of this shared PSK on a single device would lead to 2329 the compromise of the entire batch. When using the implementation/ 2330 deployment scheme outlined above, the PSK does not need to be written 2331 to individual pledges. As a consequence, even if a shared PSK is 2332 used, the scheme offers a comparable level of security as in the 2333 scenario where each pledge is provisioned with a unique PSK. In this 2334 case, there is still a latent risk of the shared PSK being 2335 compromised from the provisioning device, which would compromise all 2336 devices in the batch. 2338 Authors' Addresses 2340 Malisa Vucinic (editor) 2341 Inria 2342 2 Rue Simone Iff 2343 Paris 75012 2344 France 2346 Email: malisa.vucinic@inria.fr 2348 Jonathan Simon 2349 Analog Devices 2350 32990 Alvarado-Niles Road, Suite 910 2351 Union City, CA 94587 2352 USA 2354 Email: jonathan.simon@analog.com 2356 Kris Pister 2357 University of California Berkeley 2358 512 Cory Hall 2359 Berkeley, CA 94720 2360 USA 2362 Email: pister@eecs.berkeley.edu 2363 Michael Richardson 2364 Sandelman Software Works 2365 470 Dawson Avenue 2366 Ottawa, ON K1Z5V7 2367 Canada 2369 Email: mcr+ietf@sandelman.ca