idnits 2.17.1 draft-ietf-6tisch-minimal-security-07.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 date (October 23, 2018) is 2002 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 (-16) exists of draft-ietf-core-object-security-15 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-15 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Working Group M. Vucinic, Ed. 3 Internet-Draft University of Montenegro 4 Intended status: Standards Track J. Simon 5 Expires: April 26, 2019 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 October 23, 2018 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-07 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 configures the rest of the 6TiSCH communication stack 31 for this join process to occur in a secure manner. Additional 32 security mechanisms may be added on top of this minimal framework. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 26, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 6 71 5. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 72 5.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 73 5.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 74 5.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 75 5.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 76 6. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 77 7. Network-layer Configuration . . . . . . . . . . . . . . . . . 11 78 7.1. Identification of Join Request Traffic . . . . . . . . . 12 79 7.2. Identification of Join Response Traffic . . . . . . . . . 12 80 8. Application-level Configuration . . . . . . . . . . . . . . . 13 81 8.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 13 82 8.2. OSCORE Security Context . . . . . . . . . . . . . . . . . 14 83 9. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 16 84 9.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 17 85 9.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 18 86 9.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 19 87 9.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 22 88 9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 34 89 9.6. Mandatory to Implement Algorithms . . . . . . . . . . . . 34 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 91 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 93 12.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 37 94 12.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 37 95 12.3. CoJP Error Registry . . . . . . . . . . . . . . . . . . 38 97 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 99 14.1. Normative References . . . . . . . . . . . . . . . . . . 39 100 14.2. Informative References . . . . . . . . . . . . . . . . . 40 101 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 42 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 104 1. Introduction 106 This document presumes a 6TiSCH network as described by [RFC7554] and 107 [RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their 108 radio turned off most of the time, to conserve energy. As a 109 consequence, the link used by a new device for joining the network 110 has limited bandwidth [RFC8180]. The secure join solution defined in 111 this document therefore keeps the number of over-the-air exchanges 112 for join purposes to a minimum. 114 The micro-controllers at the heart of 6TiSCH nodes have a small 115 amount of code memory. It is therefore paramount to reuse existing 116 protocols available as part of the 6TiSCH stack. At the application 117 layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web 118 transfer, and on OSCORE [I-D.ietf-core-object-security] for its end- 119 to-end security. The secure join solution defined in this document 120 therefore reuses those two protocols as its building blocks. 122 This document defines a secure join solution for a new device, called 123 "pledge", to securely join a 6TiSCH network. The specification 124 defines the Constrained Join Protocol (CoJP) used by the pledge to 125 request admission into a network managed by the JRC, and for the JRC 126 to configure the pledge with the necessary parameters and update them 127 at a later time, a new CoAP option, and configures different layers 128 of the 6TiSCH protocol stack for the join process to occur in a 129 secure manner. 131 The Constrained Join Protocol defined in this document is generic and 132 can be used as-is in modes of IEEE Std 802.15.4 other than TSCH, that 133 6TiSCH is based on. The Constrained Join Protocol may as well be 134 used in other (low-power) networking technologies where efficiency in 135 terms of communication overhead and code footprint is important. In 136 such a case, it may be necessary to register configuration parameters 137 specific to the technology in question, through the IANA process. 138 The overall join process described in Section 5 and the configuration 139 of the stack is, however, specific to 6TiSCH. 141 The Constrained Join Protocol assumes the presence of a JRC (join 142 registrar/coordinator), a central entity. It further assumes that 143 the pledge and the JRC share a symmetric key, called PSK (pre-shared 144 key). The PSK is used to configure OSCORE to provide a secure 145 channel to CoJP. How the PSK is installed is out of scope of this 146 document: this may happen through the one-touch provisioning process 147 or by a key exchange protocol that may precede the execution of the 148 6TiSCH Join protocol. 150 When the pledge seeks admission to a 6TiSCH network, it first 151 synchronizes to it, by initiating the passive scan defined in 152 [IEEE802.15.4]. The pledge then exchanges messages with the JRC; 153 these messages can be forwarded by nodes already part of the 6TiSCH 154 network. The messages exchanged allow the JRC and the pledge to 155 mutually authenticate, based on the PSK. They also allow the JRC to 156 configure the pledge with link-layer keying material, short 157 identifier and other parameters. After this secure join process 158 successfully completes, the joined node can interact with its 159 neighbors to request additional bandwidth using the 6top Protocol 160 [I-D.ietf-6tisch-6top-protocol] and start sending the application 161 traffic. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. These 168 words may also appear in this document in lowercase, absent their 169 normative meanings. 171 The reader is expected to be familiar with the terms and concepts 172 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 173 [I-D.ietf-core-object-security], and [RFC8152]. 175 The specification also includes a set of informative specifications 176 using the Concise data definition language (CDDL) 177 [I-D.ietf-cbor-cddl]. 179 The following terms defined in [I-D.ietf-6tisch-terminology] are used 180 extensively throughout this document: 182 o pledge 184 o joined node 186 o join proxy (JP) 188 o join registrar/coordinator (JRC) 190 o enhanced beacon (EB) 192 o join protocol 193 o join process 195 The following terms defined in [RFC6775] are also used throughout 196 this document: 198 o 6LoWPAN Border Router (6LBR) 200 The term "6LBR" is used interchangeably with the term "DODAG root" 201 defined in [RFC6550], assuming the two entities are co-located, as 202 recommended by [I-D.ietf-6tisch-architecture]. 204 The term "pledge", as used throughout the document, explicitly 205 denotes non-6LBR devices attempting to join over an IEEE Std 802.15.4 206 network interface. The device that attempts to join as the 6LBR of 207 the network and does so over another network interface is explicitly 208 denoted as the "6LBR pledge". When the text equally applies to the 209 pledge and the 6LBR pledge, the "(6LBR) pledge" form is used. 211 In addition, we use the generic terms "network identifier" and 212 "pledge identifier". See Section 3. 214 3. Identifiers 216 The "network identifier" identifies the 6TiSCH network. The network 217 identifier MUST be carried within Enhanced Beacon (EB) frames. 218 Typically, the 16-bit Personal Area Network Identifier (PAN ID) 219 defined in [IEEE802.15.4] is used as the network identifier. 220 However, PAN ID is not considered a stable network identifier as it 221 may change during network lifetime if a collision with another 222 network is detected. Companion documents can specify the use of a 223 different network identifier for join purposes, but this is out of 224 scope of this specification. 226 The "pledge identifier" identifies the (6LBR) pledge. The pledge 227 identifier MUST be unique in the set of all pledge identifiers 228 managed by a JRC. The pledge identifier uniqueness is an important 229 security requirement, as discussed in Section 10. The pledge 230 identifier is typically the globally unique 64-bit Extended Unique 231 Identifier (EUI-64) of the IEEE Std 802.15.4 device. This identifier 232 is used to generate the IPv6 addresses of the (6LBR) pledge and to 233 identify it during the execution of the join protocol. For privacy 234 reasons (see Section 11), it is possible to use a pledge identifier 235 different from the EUI-64. For example, a pledge identifier may be a 236 random byte string, but care needs to be taken that such a string 237 meets the uniqueness requirement. How pledge identifier is 238 configured at the pledge is out of scope of this specification. 240 4. One-Touch Assumption 242 This document assumes a one-touch scenario. The (6LBR) pledge is 243 provisioned with certain parameters before attempting to join the 244 network, and the same parameters are provisioned to the JRC. 246 There are many ways by which this provisioning can be done. 247 Physically, the parameters can be written into the (6LBR) pledge 248 using a number of mechanisms, such as a JTAG interface, a serial 249 (craft) console interface, pushing buttons simultaneously on 250 different devices, over-the-air configuration in a Faraday cage, etc. 251 The provisioning can be done by the vendor, the manufacturer, the 252 integrator, etc. 254 Details of how this provisioning is done is out of scope of this 255 document. What is assumed is that there can be a secure, private 256 conversation between the JRC and the (6LBR) pledge, and that the two 257 devices can exchange the parameters. 259 Parameters that are provisioned to the (6LBR) pledge include: 261 o Pre-Shared Key (PSK). The JRC additionally needs to store the 262 pledge identifier bound to the given PSK. Each (6LBR) pledge MUST 263 be provisioned with a unique PSK. The PSK SHOULD be a 264 cryptographically strong key, at least 128 bits in length, 265 indistinguishable by feasible computation from a random uniform 266 string of the same length. How the PSK is generated and/or 267 provisioned is out of scope of this specification. This could be 268 done during a provisioning step or companion documents can specify 269 the use of a key agreement protocol. Common pitfalls when 270 generating PSKs are discussed in Section 10. 272 o Optionally, a network identifier. Provisioning the network 273 identifier is RECOMMENDED. However, due to the operational 274 constraints the network identifier may not be known at the time 275 when the provisioning is done. In case this parameter is not 276 provisioned to the pledge, the pledge attempts to join one network 277 at a time, which significantly prolongs the join process. In case 278 this parameter is not provisioned to the 6LBR pledge, the 6LBR 279 pledge can receive it from the JRC as part of the join protocol. 281 o Optionally, any non-default algorithms. The default algorithms 282 are specified in Section 9.6. When algorithm identifiers are not 283 exchanged, the use of these default algorithms is implied. 285 Additionally, the 6LBR pledge that is not co-located with the JRC 286 needs to be provisioned with: 288 o Global IPv6 address of the JRC. This address is used by the 6LBR 289 pledge to address the JRC during the join process. The 6LBR 290 pledge may also obtain the IPv6 address of the JRC through other 291 available mechanisms, such as DHCPv6, GRASP, mDNS, the use of 292 which is out of scope of this document. Pledges do not need to be 293 provisioned with this address as they discover it dynamically 294 during the join process. 296 5. Join Process Overview 298 This section describes the steps taken by a pledge in a 6TiSCH 299 network. When a pledge seeks admission to a 6TiSCH network, the 300 following exchange occurs: 302 1. The pledge listens for an Enhanced Beacon (EB) frame 303 [IEEE802.15.4]. This frame provides network synchronization 304 information, and tells the device when it can send a frame to the 305 node sending the beacons, which acts as a Join Proxy (JP) for the 306 pledge, and when it can expect to receive a frame. The Enhanced 307 Beacon provides the L2 address of the JP and it may also provide 308 its link-local IPv6 address. 310 2. The pledge configures its link-local IPv6 address and advertises 311 it to the JP using Neighbor Discovery. This step may be omitted 312 if the link-local address has been derived from a known unique 313 interface identifier, such as an EUI-64 address. 315 3. The pledge sends a Join Request to the JP in order to securely 316 identify itself to the network. The Join Request is forwarded to 317 the JRC. 319 4. In case of successful processing of the request, the pledge 320 receives a Join Response from the JRC (via the JP). The Join 321 Response contains configuration parameters necessary for the 322 pledge to join the network. 324 From the pledge's perspective, joining is a local phenomenon - the 325 pledge only interacts with the JP, and it needs not know how far it 326 is from the 6LBR, or how to route to the JRC. Only after 327 establishing one or more link-layer keys does it need to know about 328 the particulars of a 6TiSCH network. 330 The join process is shown as a transaction diagram in Figure 1: 332 +--------+ +-------+ +--------+ 333 | pledge | | JP | | JRC | 334 | | | | | | 335 +--------+ +-------+ +--------+ 336 | | | 337 |<---Enhanced Beacon (1)---| | 338 | | | 339 |<-Neighbor Discovery (2)->| | 340 | | | 341 |-----Join Request (3a)----|----Join Request (3a)---->| \ 342 | | | | CoJP 343 |<----Join Response (3b)---|----Join Response (3b)----| / 344 | | | 346 Figure 1: Overview of a successful join process. CoJP stands for 347 Constrained Join Protocol. 349 As other nodes in the network, the 6LBR node may act as the JP. The 350 6LBR may in addition be co-located with the JRC. 352 The details of each step are described in the following sections. 354 5.1. Step 1 - Enhanced Beacon 356 The pledge synchronizes to the network by listening for, and 357 receiving, an Enhanced Beacon (EB) sent by a node already in the 358 network. This process is entirely defined by [IEEE802.15.4], and 359 described in [RFC7554]. 361 Once the pledge hears an EB, it synchronizes to the joining schedule 362 using the cells contained in the EB. The pledge can hear multiple 363 EBs; the selection of which EB to use is out of the scope for this 364 document, and is discussed in [RFC7554]. Implementers should make 365 use of information such as: what network identifier the EB contains, 366 the value of the Join Metric field within EBs, whether the source 367 link-layer address of the EB has been tried before, what signal 368 strength the different EBs were received at, etc. In addition, the 369 pledge may be pre-configured to search for EBs with a specific 370 network identifier. 372 If the pledge is not provisioned with the network identifier, it 373 attempts to join one network at a time, as described in 374 Section 9.3.1. 376 Once the pledge selects the EB, it synchronizes to it and transitions 377 into a low-power mode. It follows the provided schedule which 378 indicates the slots that the pledge may use for the join process. 380 During the remainder of the join process, the node that has sent the 381 EB to the pledge acts as the JP. 383 At this point, the pledge may proceed to step 2, or continue to 384 listen for additional EBs. 386 5.2. Step 2 - Neighbor Discovery 388 The pledge forms its link-local IPv6 address based on the interface 389 identifier, as per [RFC4944]. The pledge MAY perform the Neighbor 390 Solicitation / Neighbor Advertisement exchange with the JP, as per 391 Section 5.5.1 of [RFC6775]. The pledge and the JP use their link- 392 local IPv6 addresses for all subsequent communication during the join 393 process. 395 Note that Neighbor Discovery exchanges at this point are not 396 protected with link-layer security as the pledge is not in possession 397 of the keys. How JP accepts these unprotected frames is discussed in 398 Section 6. 400 5.3. Step 3 - Constrained Join Protocol (CoJP) Execution 402 The pledge triggers the join exchange of the Constrained Join 403 Protocol (CoJP). The join exchange consists of two messages: the 404 Join Request message (Step 3a), and the Join Response message 405 conditioned on the successful security processing of the request 406 (Step 3b). 408 All CoJP messages are exchanged over a secure end-to-end channel that 409 provides confidentiality, data authenticity and replay protection. 410 Frames carrying CoJP messages are not protected with link-layer 411 security when exchanged between the pledge and the JP as the pledge 412 is not in possession of the link-layer keys in use. How JP and 413 pledge accept these unprotected frames is discussed in Section 6. 414 When frames carrying CoJP messages are exchanged between nodes that 415 have already joined the network, the link-layer security is applied 416 according to the security configuration used in the network. 418 5.3.1. Step 3a - Join Request 420 The Join Request is a message sent from the pledge to the JP, and 421 which the JP forwards to the JRC. The pledge indicates in the Join 422 Request the role it requests to play in the network as well as the 423 identifier of the network it requests to join. The JP forwards the 424 Join Request to the JRC on the existing 6TiSCH network. How exactly 425 this happens is out of scope of this document; some networks may wish 426 to dedicate specific slots for this join traffic. 428 5.3.2. Step 3b - Join Response 430 The Join Response is sent by the JRC to the pledge, and is forwarded 431 through the JP. The packet containing the Join Response travels from 432 the JRC to JP using the operating routes in the 6TiSCH network. The 433 JP delivers it to the pledge. The JP operates as the application- 434 layer proxy, and does not keep any state to forward the message. 436 The Join Response contains different parameters needed by the pledge 437 to become a fully operational network node. For example, these 438 parameters are the link-layer key(s) currently in use in the network, 439 the short link-layer address assigned to the pledge, the IPv6 address 440 of the JRC needed by the pledge to operate as the JP, and others. 442 5.4. The Special Case of the 6LBR Pledge Joining 444 The 6LBR pledge performs Section 5.3 of the join process described 445 above, just as any other pledge, albeit over another network 446 interface. There is no JP intermediating the communication between 447 the 6LBR pledge and the JRC, as described in Section 7. The other 448 steps of the described join process do not apply to the 6LBR pledge. 449 How the 6LBR pledge obtains an IPv6 address and triggers the 450 execution of the CoJP protocol is out of scope of this document. 452 6. Link-layer Configuration 454 In an operational 6TiSCH network, all frames MUST use link-layer 455 frame security [RFC8180]. The IEEE Std 802.15.4 security attributes 456 MUST include frame authenticity, and MAY include frame 457 confidentiality (i.e. encryption). 459 The pledge does not initially do any authenticity check of the EB 460 frames, as it does not possess the link-layer key(s) in use. The 461 pledge is still able to parse the contents of the received EBs and 462 synchronize to the network, as EBs are not encrypted [RFC8180]. 464 When sending frames during the join process, the pledge sends 465 unencrypted and unauthenticated frames. The JP accepts these 466 unsecured frames for the duration of the join process. This behavior 467 may be implemented by setting the "secExempt" attribute in the IEEE 468 Std 802.15.4 security configuration tables. How the JP learns 469 whether the join process is ongoing is out of scope of this 470 specification. 472 As the EB itself cannot be authenticated by the pledge, an attacker 473 may craft a frame that appears to be a valid EB, since the pledge can 474 neither verify the freshness nor verify the address of the JP. This 475 opens up a possibility of DoS attack, as discussed in Section 10. 477 7. Network-layer Configuration 479 The pledge and the JP SHOULD keep a separate neighbor cache for 480 untrusted entries and use it to store each other's information during 481 the join process. Mixing neighbor entries belonging to pledges and 482 nodes that are part of the network opens up the JP to a DoS attack, 483 as the attacker may fill JP's neighbor table and prevent the 484 discovery of legitimate neighbors. 486 Once the pledge obtains link-layer keys and becomes a joined node, it 487 is able to securely communicate with its neighbors, obtain the 488 network IPv6 prefix and form a global IPv6 address. The joined node 489 then undergoes an independent process to bootstrap the neighbor cache 490 entries, possibly with a node that formerly acted as a JP, following 491 [RFC6775]. From the point of view of the JP, there is no relation 492 between the neighbor cache entry belonging to a pledge and the joined 493 node that formerly acted as a pledge. 495 The pledge does not communicate with the JRC at the network layer. 496 This allows the pledge to join without knowing the IPv6 address of 497 the JRC. Instead, the pledge communicates with the JP at the network 498 layer using link-local addressing, and with the JRC at the 499 application layer, as specified in Section 8. 501 The JP communicates with the JRC over global IPv6 addresses. The JP 502 discovers the network IPv6 prefix and configures its global IPv6 503 address upon successful completion of the join process and the 504 obtention of link-layer keys. The pledge learns the actual IPv6 505 address of the JRC from the Join Response, as specified in 506 Section 9.1.2; it uses it once joined in order to operate as a JP. 508 As a special case, the 6LBR pledge is expected to have an additional 509 network interface that it uses in order to obtain the configuration 510 parameters from the JRC and start advertising the 6TiSCH network. 511 This additional interface needs to be configured with a global IPv6 512 address, by a mechanism that is out of scope of this document. The 513 6LBR pledge uses this interface to directly communicate with the JRC 514 using global IPv6 addressing. 516 The JRC can be co-located on the 6LBR. In this special case, the 517 IPv6 address of the JRC can be omitted from the Join Response message 518 for space optimization. The 6LBR then MUST set the DODAGID field in 519 the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the 520 address of the JRC once joined and upon the reception of the first 521 RPL DIO message, and uses it to operate as a JP. 523 7.1. Identification of Join Request Traffic 525 The join request traffic that is proxied by the Join Proxy (JP) comes 526 from unauthenticated nodes, and there may be an arbitrary amount of 527 it. In particular, an attacker may send fraudulent traffic in 528 attempt to overwhelm the network. 530 When operating as part of a [RFC8180] 6TiSCH minimal network using 531 distributed scheduling algorithms, the join request traffic present 532 may cause intermediate nodes to request additional bandwidth. An 533 attacker could use this property to cause the network to overcommit 534 bandwidth (and energy) to the join process. 536 The Join Proxy is aware of what traffic is join request traffic, and 537 so can avoid allocating additional bandwidth itself. The Join Proxy 538 SHOULD implement a bandwidth cap on outgoing join request traffic. 539 This cap will not protect intermediate nodes as they can not tell 540 join request traffic from regular traffic. Despite the bandwidth cap 541 implemented separately on each Join Proxy, the aggregate join request 542 traffic from many Join Proxies may cause intermediate nodes to decide 543 to allocate additional cells. It is undesirable to do so in response 544 to the join request traffic. In order to permit the intermediate 545 nodes to avoid this, the traffic needs to be tagged. 547 [RFC2597] defines a set of per-hop behaviors that may be encoded into 548 the Diffserv Code Points (DSCPs). The Join Proxy SHOULD set the DSCP 549 of join request packets that it produces as part of the relay process 550 to AF43 code point (See Section 6 of [RFC2597]). 552 A Join Proxy that does not set the DSCP on traffic forwarded should 553 set it to zero so that it is compressed out. 555 A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT 556 allocate additional cells as a result of traffic with code point 557 AF43. Companion SF documents SHOULD specify how this recommended 558 behavior is achieved. 560 7.2. Identification of Join Response Traffic 562 The JRC SHOULD set the DSCP of join response packets addressed to the 563 Join Proxy to AF42 code point. Join response traffic can not be 564 induced by an attacker as it is generated only in response to 565 legitimate pledges (see Section 9.3.1). AF42 has lower drop 566 probability than AF43, giving join response traffic priority in 567 buffers over join request traffic. 569 Due to the convergecast nature of the DODAG, the 6LBR links are often 570 the most congested, and from that point down there is progressively 571 less (or equal) congestion. If the 6LBR paces itself when sending 572 join response traffic then it ought to never exceed the bandwidth 573 allocated to the best effort traffic cells. If the 6LBR has the 574 capacity (if it is not constrained) then it should provide some 575 buffers in order to satisfy the Assured Forwarding behavior. 577 Companion SF documents SHOULD specify how traffic with code point 578 AF42 is handled with respect to cell allocation. 580 8. Application-level Configuration 582 The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and 583 the secure channel provided by OSCORE 584 [I-D.ietf-core-object-security]. The (6LBR) acts as a CoAP client; 585 the JRC acts as a CoAP server. The JP implements CoAP forward proxy 586 functionality [RFC7252]. Because the JP can also be a constrained 587 device, it cannot implement a cache. 589 The pledge designates a JP as a proxy by including the Proxy-Scheme 590 option in CoAP requests it sends to the JP. The pledge also includes 591 in the requests the Uri-Host option with its value set to the well- 592 known JRC's alias, as specified in Section 9.1.1. 594 The JP resolves the alias to the IPv6 address of the JRC that it 595 learned when it acted as a pledge, and joined the network. This 596 allows the JP to reach the JRC at the network layer and forward the 597 requests on behalf of the pledge. 599 The JP also tags all packets carrying the Join Request message at the 600 network layer, as specified in Section 7.1. 602 8.1. Statelessness of the JP 604 The CoAP proxy defined in [RFC7252] keeps per-client state 605 information in order to forward the response towards the originator 606 of the request. This state information includes at least the CoAP 607 token, the IPv6 address of the client, and the UDP source port 608 number. Since the JP can be a constrained device that acts as a CoAP 609 proxy, memory limitations make it prone to Denial-of-Service (DoS) 610 attacks. 612 The DoS risk on the JP can be mitigated by making the JP act as a 613 stateless CoAP proxy. The JP can wrap the state it needs to keep for 614 a given pledge throughout the network stack in a "state object" and 615 include it as a CoAP token in the forwarded request to the JRC (i.e. 616 origin server). The JP may use the CoAP token as defined in 617 [RFC7252], if the size of the serialized state object permits, or use 618 the extended CoAP token being defined in [I-D.hartke-core-stateless]. 620 Since the CoAP token is echoed back in the response, the JP is able 621 to decode the token and configure the state needed to forward the 622 response to the pledge. The information that the JP needs to encode 623 in the state object to operate in a fully stateless manner with 624 respect to a given pledge is implementation specific. In all cases, 625 the state object communicated in the token SHOULD be integrity 626 protected, with a key that is known only to the JP, and SHOULD 627 include a freshness indicator. It is RECOMMENDED that the JP 628 operates in a stateless manner and signals the per-pledge state 629 within the CoAP token, for every request it forwards into the network 630 on behalf of unauthenticated pledges. 632 Note, however, that in some networking stack implementations, a fully 633 stateless operation of the JP may be challenging from the 634 implementation point of view. In those cases, the JP may operate as 635 a statefull proxy that stores the per-pledge state until the response 636 is received or timed out, but this comes at an increased risk of DoS 637 attacks. 639 8.2. OSCORE Security Context 641 Before the (6LBR) pledge and the JRC may start exchanging CoAP 642 messages protected with OSCORE, they need to derive the OSCORE 643 security context from the parameters provisioned out-of-band, as 644 discussed in Section 4. 646 The OSCORE security context MUST be derived as per Section 3 of 647 [I-D.ietf-core-object-security]. 649 o the Master Secret MUST be the PSK. 651 o the Master Salt MUST be the empty byte string. 653 o the ID of the pledge MUST be set to the byte string 0x00. This 654 identifier is used as the OSCORE Sender ID of the pledge in the 655 security context derivation, as the pledge initially acts as a 656 CoAP client. 658 o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" 659 in ASCII). This identifier is used as the OSCORE Recipient ID of 660 the pledge in the security context derivation, as the JRC 661 initially acts as a CoAP server. 663 o the ID Context MUST be set to the pledge identifier. 665 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 666 of-band by the same mechanism used to provision the PSK. The 667 default is AES-CCM-16-64-128. 669 o the Key Derivation Function MUST be agreed out-of-band. Default 670 is HKDF SHA-256 [RFC5869]. 672 The derivation in [I-D.ietf-core-object-security] results in traffic 673 keys and a common IV for each side of the conversation. Nonces are 674 constructed by XOR'ing the common IV with the current sequence number 675 and sender identifier. For details on nonce construction, refer to 676 [I-D.ietf-core-object-security]. 678 Implementations MUST ensure that multiple CoAP requests to different 679 JRCs are properly incrementing the sequence numbers in the OSCORE 680 security context for each message, so that the same sequence number 681 is never reused in distinct requests. The pledge typically sends 682 requests to different JRCs if it is not provisioned with the network 683 identifier and attempts to join one network at a time. A simple 684 implementation technique is to instantiate the OSCORE security 685 context with a given PSK only once and use it for all subsequent 686 requests. Failure to comply will break the security guarantees of 687 the Authenticated Encryption with Associated Data (AEAD) algorithm 688 due to the nonce reuse. 690 This OSCORE security context is used for initial joining of the 691 (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well 692 as for any later parameter updates, where the JRC acts as a CoAP 693 client and the joined node as a CoAP server, as discussed in 694 Section 9.2. The (6LBR) pledge and the JRC use the OSCORE security 695 context parameters (e.g. sender and recipient identifiers) as they 696 were used at the moment of context derivation, regardless of whether 697 they currently act as a CoAP client or a CoAP server. A (6LBR) 698 pledge is expected to have exactly one OSCORE security context with 699 the JRC. 701 8.2.1. Replay Window and Persistency 703 Both (6LBR) pledge and the JRC MUST implement a replay protection 704 mechanism. The use of the default OSCORE replay protection mechanism 705 specified in Section 3.2.2 of [I-D.ietf-core-object-security] is 706 RECOMMENDED. 708 Implementations MUST ensure that mutable OSCORE context parameters 709 (Sender Sequence Number, Replay Window) are stored in persistent 710 memory. A technique that prevents reuse of sequence numbers, 711 detailed in Section 7.5.1 of [I-D.ietf-core-object-security], MUST be 712 implemented. Each update of the OSCORE Replay Window MUST be written 713 to persistent memory. 715 This is an important security requirement in order to guarantee nonce 716 uniqueness and resistance to replay attacks across reboots and 717 rejoins. Traffic between the (6LBR) pledge and the JRC is rare, 718 making security outweigh the cost of writing to persistent memory. 720 9. Constrained Join Protocol (CoJP) 722 Constrained Join Protocol (CoJP) is a lightweight protocol over CoAP 723 [RFC7252] and a secure channel provided by OSCORE 724 [I-D.ietf-core-object-security]. CoJP allows the (6LBR) pledge to 725 request admission into a network managed by the JRC, and for the JRC 726 to configure the pledge with the parameters necessary for joining the 727 network, or advertising it in the case of 6LBR pledge. The JRC may 728 update the parameters at any time, by reaching out to the joined node 729 that formerly acted as a (6LBR) pledge. For example, network-wide 730 rekeying can be implemented by updating the keying material on each 731 node. 733 This section specifies how the CoJP messages are mapped to CoAP and 734 OSCORE, CBOR data structures carrying different parameters, 735 transported within CoAP payload, and the parameter semantics and 736 processing rules. 738 CoJP relies on the security properties provided by OSCORE. This 739 includes end-to-end confidentiality, data authenticity, replay 740 protection, and a secure binding of responses to requests. 742 +-----------------------------------+ 743 | Constrained Join Protocol (CoJP) | 744 +-----------------------------------+ 745 +-----------------------------------+ \ 746 | Requests / Responses | | 747 |-----------------------------------| | 748 | OSCORE | | CoAP 749 |-----------------------------------| | 750 | Messaging Layer | | 751 +-----------------------------------+ / 752 +-----------------------------------+ 753 | UDP | 754 +-----------------------------------+ 756 Figure 2: Abstract layering of CoJP. 758 When a (6LBR) pledge requests admission to a given network, it 759 undergoes the CoJP join exchange that consists of: 761 o the Join Request message, sent by the (6LBR) pledge to the JRC, 762 potentially proxied by the JP. The Join Request message and its 763 mapping to CoAP is specified in Section 9.1.1. 765 o the Join Response message, sent by the JRC to the (6LBR) pledge if 766 the JRC successfully processes the Join Request using OSCORE and 767 it determines through a mechanism that is out of scope of this 768 specification that the (6LBR) pledge is authorized to join the 769 network. The Join Response message is potentially proxied by the 770 JP. The Join Response message and its mapping to CoAP is 771 specified in Section 9.1.2. 773 When the JRC needs to update the parameters of a joined node that 774 formerly acted as a (6LBR) pledge, it executes the CoJP parameter 775 update exchange that consists of: 777 o the Parameter Update message, sent by the JRC to the joined node 778 that formerly acted as a (6LBR) pledge. The Parameter Update 779 message and its mapping to CoAP is specified in Section 9.2.1. 781 o the Parameter Update Response message, sent by the joined node to 782 the JRC in response to the Parameter Update message to signal 783 successful reception of the updated parameters. The Parameter 784 Update Response message and its mapping to CoAP is specified in 785 Section 9.2.2. 787 The payload of CoJP messages is encoded with CBOR [RFC7049]. The 788 CBOR data structures that may appear as the payload of different CoJP 789 messages are specified in Section 9.4. 791 9.1. Join Exchange 793 This section specifies the messages exchanged when the (6LBR) pledge 794 requests admission and configuration parameters from the JRC. 796 9.1.1. Join Request Message 798 The Join Request message SHALL be mapped to a CoAP request: 800 o The request method is POST. 802 o The type is Non-confirmable (NON). 804 o The Proxy-Scheme option is set to "coap". 806 o The Uri-Host option is set to "6tisch.arpa". This is an anycast 807 type of identifier of the JRC that is resolved to its IPv6 address 808 by the JP or the 6LBR pledge. 810 o The Uri-Path option is set to "j". 812 o The Object-Security option SHALL be set according to 813 [I-D.ietf-core-object-security]. The OSCORE security context used 814 is the one derived in Section 8.2. The OSCORE kid context allows 815 the JRC to retrieve the security context for a given pledge. 817 o The payload is a Join_Request CBOR object, as defined in 818 Section 9.4.1. 820 9.1.2. Join Response Message 822 The Join Response message that the JRC sends SHALL be mapped to a 823 CoAP response: 825 o The response Code is 2.04 (Changed). 827 o The payload is a Configuration CBOR object, as defined in 828 Section 9.4.2. 830 9.2. Parameter Update Exchange 832 During the network lifetime, parameters returned as part of the Join 833 Response may need to be updated. One typical example is the update 834 of link-layer keying material for the network, a process known as 835 rekeying. This section specifies a generic mechanism when this 836 parameter update is initiated by the JRC. 838 At the time of the join, the (6LBR) pledge acts as a CoAP client and 839 requests the network parameters through a representation of the "/j" 840 resource, exposed by the JRC. In order for the update of these 841 parameters to happen, the JRC needs to asynchronously contact the 842 joined node. The use of the CoAP Observe option for this purpose is 843 not feasible due to the change in the IPv6 address when the pledge 844 becomes the joined node and obtains a global address. 846 Instead, once the (6LBR) pledge receives and successfully validates 847 the Join Response and so becomes a joined node, it becomes a CoAP 848 server. The joined node exposes the "/j" resource that is used by 849 the JRC to update the parameters. Consequently, the JRC operates as 850 a CoAP client when updating the parameters. The request/response 851 exchange between the JRC and the (6LBR) pledge happens over the 852 already-established OSCORE secure channel. 854 9.2.1. Parameter Update Message 856 The Parameter Update message that the JRC sends to the joined node 857 SHALL be mapped to a CoAP request: 859 o The request method is POST. 861 o The type is Confirmable (CON). 863 o The Uri-Path option is set to "j". 865 o The Object-Security option SHALL be set according to 866 [I-D.ietf-core-object-security]. The OSCORE security context used 867 is the one derived in Section 8.2. When a joined node receives a 868 request with the Sender ID set to 0x4a5243 (ID of the JRC), it is 869 able to correctly retrieve the security context with the JRC. 871 o The payload is a Configuration CBOR object, as defined in 872 Section 9.4.2. 874 The JRC has implicit knowledge on the global IPv6 address of the 875 joined node, as it knows the pledge identifier that the joined node 876 used when it acted as a pledge, and the IPv6 network prefix. The JRC 877 uses this implicitly derived IPv6 address of the joined node to 878 directly address CoAP messages to it. 880 In case the JRC does not receive a response to a Parameter Update 881 message, it will attempt multiple retransmissions, as configured by 882 the underlying CoAP retransmission mechanism triggered for 883 confirmable messages. Finally, if the CoAP implementation declares 884 that the destination is unreachable, the JRC may consider this as a 885 hint that the joined node is no longer in the network. How JRC 886 decides when to stop managing a given joined node is out of scope of 887 this specification but security considerations on the reuse of 888 assigned resources apply, as discussed in Section 10. 890 9.2.2. Parameter Update Response Message 892 The Parameter Update Response message that the joined node sends to 893 the JRC SHALL be mapped to a CoAP response: 895 o The response Code is 2.04 (Changed). 897 o The payload is empty. 899 9.3. Error Handling 901 9.3.1. OSCORE Error Handling and Retransmission 903 This section describes handling of errors raised by the underlying 904 OSCORE. 906 Since the Join Request is mapped to a Non-confirmable CoAP message, 907 OSCORE processing at the JRC will silently drop the request in case 908 of a failure. This may happen for a number of reasons, including 909 failed lookup of an appropriate security context (e.g. the pledge 910 attempting to join a wrong network), failed decryption, positive 911 replay window lookup, formatting errors (possibly due to malicious 912 alterations in transit). Silently dropping the Join Request at the 913 JRC prevents a DoS attack where an attacker could force the pledge to 914 attempt joining one network at a time, until all networks have been 915 tried. 917 Using a Non-confirmable CoAP message to transport the Join Request 918 also helps minimize the required CoAP state at the pledge and the 919 Join Proxy, keeping it to a minimum typically needed to perform CoAP 920 congestion control. It does, however, introduce some complexity as 921 the pledge needs to implement a retransmission mechanism. 923 The following binary exponential back-off algorithm is inspired by 924 the one described in [RFC7252]. For each Join Request the pledge 925 sends while waiting for a Join Response, the pledge MUST keep track 926 of a timeout and a retransmission counter. For a new Join Request, 927 the timeout is set to a random value between TIMEOUT_BASE and 928 (TIMEOUT_BASE * TIMEOUT_RANDOM_FACTOR). The retransmission counter 929 is set to 0. When the timeout is triggered and the retransmission 930 counter is less than MAX_RETRANSMIT, the Join Request is 931 retransmitted, the retransmission counter is incremented, and the 932 timeout is doubled. Note that the retransmitted Join Request passes 933 new OSCORE processing, such that the sequence number in the OSCORE 934 context is properly incremented. If the retransmission counter 935 reaches MAX_RETRANSMIT on a timeout, the pledge SHOULD attempt to 936 join the next advertised 6TiSCH network. If the pledge receives a 937 Join Response that successfully passes OSCORE processing, it cancels 938 the pending timeout and processes the response. The pledge MUST 939 silently discard any response not protected with OSCORE, including 940 error codes. For default values of retransmission parameters, see 941 Section 9.5. 943 If all join attempts to advertised networks have failed, the pledge 944 SHOULD signal to the user the presence of an error condition, through 945 some out-of-band mechanism. 947 9.3.2. CoJP CBOR Object Processing 949 This section describes error handling when processing CoJP CBOR 950 objects that are transported within the payload of different CoJP 951 messages. See Section 9.3.1 for the handling of errors that may be 952 raised by the underlying OSCORE implementation. 954 CoJP CBOR objects are transported both within CoAP requests and 955 responses. When an error is detected while processing CoJP objects 956 in a CoAP request (Join Request message, Parameter Update message), 957 Error Response message MUST be returned. Error Response message maps 958 to a CoAP response and is specified in Section 9.3.3. 960 When an error is detected while processing a CoJP object in a CoAP 961 response (Join Response message), a (6LBR) pledge SHOULD reattempt to 962 join. In this case, the (6LBR) pledge SHOULD enclose an Error CBOR 963 object within the Join Request object in the following Join Request 964 message. A (6LBR) pledge MUST NOT attempt more than MAX_RETRANSMIT 965 number of attempts to join if the processing of the Join Response 966 message fails. If MAX_RETRANSMIT number of attempts is reached 967 without success, the (6LBR) pledge SHOULD signal to the user the 968 presence of an error condition, through some out-of-band mechanism. 970 9.3.3. Error Response Message 972 The Error Response Message is returned for any CoJP request when the 973 processing of the payload failed. Note that the Error Response 974 message is protected by OSCORE as any other CoJP protocol message. 976 The Error Response message SHALL be mapped to a CoAP response: 978 o The response Code is 4.00 (Bad Request). 980 o The payload is an Error CBOR object, as defined in Section 9.4.5, 981 containing the error code that triggered the sending of this 982 message. 984 9.3.4. Failure Handling 986 The Parameter Update exchange may be triggered at any time during the 987 network lifetime that may span several years. During this period, it 988 may occur that a joined node or the JRC experience unexpected events 989 such as reboots or complete failures. 991 This document mandates that the mutable parameters in the security 992 context are written to persistent memory (see Section 8.2.1) by both 993 the JRC and pledges (joined nodes). In case of a reboot on either 994 side, the retrieval of mutable security context parameters is 995 feasible from the persistent memory such that there is no risk of 996 AEAD nonce reuse due to a reinitialized Sender Sequence number, or of 997 a replay attack due to the reinitialized replay window. 999 In the case of a complete failure, where the mutable security context 1000 parameters cannot be retrieved, it is expected that a failed joined 1001 node is replaced with a new physical device, using a new pledge 1002 identifier and a PSK. When such an event occurs at the JRC, it is 1003 likely that the information about joined nodes, their assigned short 1004 identifiers and mutable security context parameters is lost. If this 1005 is the case, during the process of JRC replacement, the network 1006 administrator MUST force all the networks managed by the failed JRC 1007 to rejoin, through e.g. the reinitialization of the 6LBR nodes. 1008 Since the joined nodes kept track of their mutable security context 1009 parameters, they will use these during the (re)join exchange without 1010 a risk of AEAD nonce reuse. However, even after all the nodes 1011 rejoined, an AEAD nonce reuse risk exists during the first Parameter 1012 Update exchange, as the new JRC does not possess the last Sender 1013 Sequence number used, and can only initialize it to zero. Since the 1014 loss of security properties including confidentiality for this 1015 message is likely the JRC MUST limit the information that may be 1016 exposed within. 1018 When such a message arrives at the joined node, the OSCORE 1019 implementation rejects it due to the Partial IV being largely below 1020 the acceptable replay window state. When this is detected, the 1021 joined node MUST send an Error Response message with error code set 1022 to "Invalid parameter: OSCORE partial IV" from Table 4 and Additional 1023 information set to the next Partial IV it will expect. When 1024 protecting this error response by OSCORE, the joined node MUST use 1025 the value of its Sender Sequence number to generate the Partial IV 1026 and include it in the CoAP OSCORE option, as specified by 1027 [I-D.ietf-core-object-security]. Upon successful OSCORE verification 1028 of the received CoJP message, the JRC processes the error response 1029 and configures the Sender Sequence number to the one indicated in the 1030 Additional information field. The next Parameter Update exchange 1031 triggered by the JRC will therefore use the proper Sender Sequence 1032 number and will be accepted by the joined node. 1034 9.4. CoJP Objects 1036 This section specifies the structure of CoJP CBOR objects that may be 1037 carried as the payload of CoJP messages. Some of these objects may 1038 be received both as part of the CoJP join exchange when the device 1039 operates as a (CoJP) pledge, or the parameter update exchange, when 1040 the device operates as a joined (6LBR) node. 1042 9.4.1. Join Request Object 1044 The Join_Request structure is built on a CBOR map object. 1046 The set of parameters that can appear in a Join_Request object is 1047 summarized below. The labels can be found in "CoJP Parameters" 1048 registry Section 12.1, initially populated with the values from 1049 Table 2. 1051 o role: The identifier of the role that the pledge requests to play 1052 in the network once it joins, encoded as an unsigned integer. 1054 Possible values are specified in Table 1. This parameter MAY be 1055 included. In case the parameter is omitted, the default value of 1056 0, i.e. the role "6TiSCH Node", MUST be assumed. 1058 o network identifier: The identifier of the network, as discussed in 1059 Section 3, encoded as a CBOR byte string. This parameter may 1060 appear both in the Join_Request and in the Configuration objects. 1061 When present in the Join_Request, it hints to the JRC the network 1062 that the pledge is requesting to join, enabling the JRC to manage 1063 multiple networks. The pledge obtains the value of the network 1064 identifier from the received EB frames. This parameter MUST be 1065 included in a Join_Request object if the role parameter is set to 1066 "6TiSCH Node". This parameter MAY be included if the role 1067 parameter is set to "6LBR". The inclusion of this parameter by 1068 the 6LBR pledge depends on whether the parameter was exchanged 1069 during the one-touch process, which in turn depends on the 1070 operational constraints. 1072 o response processing error: The identifier of the error from the 1073 previous join attempt, encoded as an Error object described in 1074 Section 9.4.5. This parameter MAY be included. If a (6LBR) 1075 pledge previously attempted to join and received a valid Join 1076 Response message over OSCORE but failed to process its payload 1077 (Configuration object), it SHOULD include this parameter to 1078 facilitate the debugging process. 1080 The CDDL fragment that represents the text above for the Join_Request 1081 follows. 1083 Join_Request = { 1084 ? 1 : uint, ; role 1085 ? 5 : bstr, ; network identifier 1086 ? 7 : Error, ; response processing error 1087 } 1089 +--------+-------+-------------------------------------+------------+ 1090 | Name | Value | Description | Reference | 1091 +--------+-------+-------------------------------------+------------+ 1092 | 6TiSCH | 0 | The pledge requests to play the | [[this | 1093 | Node | | role of a regular 6TiSCH node, i.e. | document]] | 1094 | | | non-6LBR node. | | 1095 | | | | | 1096 | 6LBR | 1 | The pledge requests to play the | [[this | 1097 | | | role of 6LoWPAN Border Router | document]] | 1098 | | | (6LBR). | | 1099 +--------+-------+-------------------------------------+------------+ 1101 Table 1: Role values. 1103 9.4.2. Configuration Object 1105 The Configuration structure is built on a CBOR map object. The set 1106 of parameters that can appear in a Configuration object is summarized 1107 below. The labels can be found in "CoJP Parameters" registry 1108 Section 12.1, initially populated with the values from Table 2. 1110 o link-layer key set: An array encompassing a set of cryptographic 1111 keys and their identifiers that are currently in use in the 1112 network, or that are scheduled to be used in the future. The 1113 encoding of individual keys is described in Section 9.4.3. The 1114 link-layer key set parameter MAY be included in a Configuration 1115 object. When present, the link-layer key set parameter MUST 1116 contain at least one key. How the keys are installed and used 1117 differs for the 6LBR and other nodes. When 6LBR receives this 1118 parameter, it MUST remove any old keys it has installed from the 1119 previous key set and immediately install and start using the new 1120 keys for all outgoing and incoming traffic. When a non-6LBR node 1121 receives this parameter, it MUST install the keys, use them for 1122 any incoming traffic matching the key identifier, but keep using 1123 the old keys for all outgoing traffic. A non-6LBR node accepts 1124 any frames for which it has keys: both old and new keys. Upon 1125 reception and successful security processing of a link-layer frame 1126 secured with a key from the new key set, a non-6LBR node MUST 1127 remove any old keys it has installed from the previous key set. 1128 From that moment on, a non-6LBR node MUST use the keys from the 1129 new key set for all outgoing traffic. In the case when the pledge 1130 is joining for the first time, before sending the first outgoing 1131 frame secured with a received key, the pledge needs to 1132 successfully complete the security processing of an incoming 1133 frame. To do so, the pledge can wait to receive a new frame or it 1134 can also store an EB frame that it used to find the JP and use it 1135 for immediate security processing upon reception of the key set. 1136 The described mechanism permits the JRC to provision the new key 1137 set to all the nodes while the network continues to use the 1138 existing keys. When the JRC is certain that all (or enough) nodes 1139 have been provisioned with the new keys, then the JRC updates the 1140 6LBR. In the special case when the JRC is co-located with the 1141 6LBR, it can simply trigger the sending of a new broadcast frame 1142 (e.g. EB), secured with a key from the new key set. The frame 1143 goes out with the new key, and upon reception and successful 1144 security processing of the new frame all receiving nodes will 1145 switch to the new active keys. Outgoing traffic from those nodes 1146 will then use the new key, which causes an update of additional 1147 peers, and the network will switch over in a flood-fill fashion. 1149 o short identifier: a compact identifier assigned to the pledge. 1150 The short identifier structure is described in Section 9.4.4. The 1151 short identifier parameter MAY be included in a Configuration 1152 object. 1154 o JRC address: the IPv6 address of the JRC, encoded as a byte 1155 string, with the length of 16 bytes. If the length of the byte 1156 string is different than 16, the parameter MUST be discarded. If 1157 the JRC is not co-located with the 6LBR and has a different IPv6 1158 address than the 6LBR, this parameter MUST be included. In the 1159 special case where the JRC is co-located with the 6LBR and has the 1160 same IPv6 address as the 6LBR, this parameter MAY be included. If 1161 the JRC address parameter is not present in the Configuration 1162 object, this indicates that the JRC has the same IPv6 address as 1163 the 6LBR. The joined node can then discover the IPv6 address of 1164 the JRC through network control traffic. See Section 7. 1166 o network identifier: the identifier of the network, as discussed in 1167 Section 3, encoded as a byte string. When present in the 1168 Configuration object, this parameter is only valid when received 1169 by the 6LBR pledge. The parameter indicates to the 6LBR the value 1170 of the network identifier it should advertise at the link layer. 1171 This parameter MUST NOT be included in the Configuration object if 1172 the role parameter from the corresponding Join_Request object 1173 indicated 0, i.e. the role "6TiSCH Node". In the case where the 1174 corresponding Join_Request object does not contain the network 1175 identifier parameter, this parameter MUST be included. When the 1176 corresponding Join_Request object does contain the network 1177 identifier parameter, this parameter MAY be included in the 1178 Configuration object. This may happen if the JRC decides to 1179 overwrite the network identifier provisioned during the one-touch 1180 process. The value of the network identifier parameter from the 1181 Configuration object SHOULD take precedence over the value 1182 provisioned during the one-touch process. 1184 o network prefix: the IPv6 network prefix, encoded as a byte string. 1185 The length of the byte string determines the prefix length. This 1186 parameter is only valid when received by the 6LBR pledge. The 1187 parameter indicates to the 6LBR the value of the IPv6 network 1188 prefix. This parameter MAY be included in the Configuration 1189 object if the role parameter from the corresponding Join_Request 1190 object indicated 1, i.e. the role "6LBR". This parameter MUST NOT 1191 be included in the Configuration object if the role parameter from 1192 the corresponding Join_Request object indicated 0, i.e. the role 1193 "6TiSCH Node". 1195 The CDDL fragment that represents the text above for the 1196 Configuration follows. Structures Link_Layer_Key and 1197 Short_Identifier are specified in Section 9.4.3 and Section 9.4.4. 1199 Configuration = { 1200 ? 2 : [ +Link_Layer_Key ], ; link-layer key set 1201 ? 3 : Short_Identifier, ; short identifier 1202 ? 4 : bstr ; JRC address 1203 ? 5 : bstr ; network identifier 1204 ? 6 : bstr ; network prefix 1205 } 1207 +------------+-------+----------+----------------------+------------+ 1208 | Name | Label | CBOR | Description | Reference | 1209 | | | type | | | 1210 +------------+-------+----------+----------------------+------------+ 1211 | role | 1 | unsigned | Identifies the role | [[this | 1212 | | | integer | parameter. | document]] | 1213 | | | | | | 1214 | link-layer | 2 | array | Identifies the array | [[this | 1215 | key set | | | carrying one or more | document]] | 1216 | | | | link-level | | 1217 | | | | cryptographic keys. | | 1218 | | | | | | 1219 | short | 3 | array | Identifies the | [[this | 1220 | identifier | | | assigned short | document]] | 1221 | | | | identifier | | 1222 | | | | | | 1223 | JRC | 4 | byte | Identifies the IPv6 | [[this | 1224 | address | | string | address of the JRC | document]] | 1225 | | | | | | 1226 | network | 5 | byte | Identifies the | [[this | 1227 | identifier | | string | network identifier | document]] | 1228 | | | | parameter | | 1229 | | | | | | 1230 | network | 6 | byte | Identifies the IPv6 | [[this | 1231 | prefix | | string | prefix of the | document]] | 1232 | | | | network | | 1233 | | | | | | 1234 | error | 7 | array | Identifies the error | [[this | 1235 | | | | parameter | document]] | 1236 +------------+-------+----------+----------------------+------------+ 1238 Table 2: CoJP parameters map labels. 1240 9.4.3. Link-Layer Key 1242 The Link_Layer_Key structure encompasses the parameters needed to 1243 configure the link-layer security module: the key identifier; the 1244 value of the cryptographic key; the link-layer algorithm identifier 1245 and the security level and the frame types that it should be used 1246 with, both for outgoing and incoming security operations; and any 1247 additional information that may be needed to configure the key. 1249 For encoding compactness, Link_Layer_Key object is not enclosed in a 1250 top-level CBOR object. Rather, it is transported as a sequence of 1251 CBOR elements, with some being optional. 1253 The set of parameters that can appear in a Link_Layer_Key object is 1254 summarized below, in order: 1256 o key_id: The identifier of the key, encoded as a CBOR unsigned 1257 integer. This parameter MUST be included. If the decoded CBOR 1258 unsigned integer value is larger than the maximum link-layer key 1259 identifier, the key is considered invalid. In case the key is 1260 considered invalid, the implementation MUST discard the key and 1261 attempt to decode the next key in the array. 1263 o key_usage: The identifier of the link-layer algorithm, security 1264 level and link-layer frame types that can be used with the key, 1265 encoded as a CBOR unsigned or negative integer. This parameter 1266 MAY be included. Possible values and the corresponding link-layer 1267 settings are specified in IANA "CoJP Key Usage" registry 1268 (Section 12.2). In case the parameter is omitted, the default 1269 value of 0 from Table 3 MUST be assumed. 1271 o key_value: The value of the cryptographic key, encoded as a byte 1272 string. This parameter MUST be included. If the length of the 1273 byte string is different than the corresponding key length for a 1274 given algorithm specified by the key_usage parameter, the key MUST 1275 be discarded and the decoder should attempt to decode the next key 1276 in the array. 1278 o key_addinfo: Additional information needed to configure the link- 1279 layer key, encoded as a byte string. This parameter MAY be 1280 included. The processing of this parameter is dependent on the 1281 link-layer technology in use and a particular keying mode. 1283 To be able to decode the keys that are present in the link-layer key 1284 set, and to identify individual parameters of a single Link_Layer_Key 1285 object, the CBOR decoder needs to differentiate between elements 1286 based on the CBOR type. For example, a uint that follows a byte 1287 string signals to the decoder that a new Link_Layer_Key object is 1288 being processed. 1290 The CDDL fragment that represents the text above for the 1291 Link_Layer_Key follows. 1293 Link_Layer_Key = ( 1294 key_id : uint, 1295 ? key_usage : uint / nint, 1296 key_value : bstr, 1297 ? key_addinfo : bstr, 1298 ) 1300 +-----------------+-----+------------------+-------------+----------+ 1301 | Name | Val | Algorithm | Description | Referenc | 1302 | | ue | | | e | 1303 +-----------------+-----+------------------+-------------+----------+ 1304 | 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | 1305 | -ENC-MIC32 | | CCM-128 | for EBs, | ocument] | 1306 | | | | ENC-MIC-32 | ] | 1307 | | | | for DATA | | 1308 | | | | and ACKNOWL | | 1309 | | | | EDGMENT. | | 1310 | | | | | | 1311 | 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | 1312 | -ENC-MIC64 | | CCM-128 | for EBs, | ocument] | 1313 | | | | ENC-MIC-64 | ] | 1314 | | | | for DATA | | 1315 | | | | and ACKNOWL | | 1316 | | | | EDGMENT. | | 1317 | | | | | | 1318 | 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | 1319 | -ENC-MIC128 | | CCM-128 | for EBs, | ocument] | 1320 | | | | ENC-MIC-128 | ] | 1321 | | | | for DATA | | 1322 | | | | and ACKNOWL | | 1323 | | | | EDGMENT. | | 1324 | | | | | | 1325 | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | 1326 | K1K2-MIC32 | | CCM-128 | for EBs, | ocument] | 1327 | | | | DATA and AC | ] | 1328 | | | | KNOWLEDGMEN | | 1329 | | | | T. | | 1330 | | | | | | 1331 | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | 1332 | K1K2-MIC64 | | CCM-128 | for EBs, | ocument] | 1333 | | | | DATA and AC | ] | 1334 | | | | KNOWLEDGMEN | | 1335 | | | | T. | | 1336 | | | | | | 1337 | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | 1338 | K1K2-MIC128 | | CCM-128 | for EBs, | ocument] | 1339 | | | | DATA and AC | ] | 1340 | | | | KNOWLEDGMEN | | 1341 | | | | T. | | 1342 | | | | | | 1343 | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | 1344 | | | CCM-128 | for EBs. | ocument] | 1345 | | | | | ] | 1346 | | | | | | 1347 | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | 1348 | | | CCM-128 | for EBs. | ocument] | 1349 | | | | | ] | 1350 | | | | | | 1351 | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | 1352 | 8 | | CCM-128 | for EBs. | ocument] | 1353 | | | | | ] | 1354 | | | | | | 1355 | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | 1356 | | | CCM-128 | for DATA | ocument] | 1357 | | | | and ACKNOWL | ] | 1358 | | | | EDGMENT. | | 1359 | | | | | | 1360 | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | 1361 | | | CCM-128 | for DATA | ocument] | 1362 | | | | and ACKNOWL | ] | 1363 | | | | EDGMENT. | | 1364 | | | | | | 1365 | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | 1366 | 8 | | CCM-128 | for DATA | ocument] | 1367 | | | | and ACKNOWL | ] | 1368 | | | | EDGMENT. | | 1369 | | | | | | 1370 | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | 1371 | MIC32 | | CCM-128 | MIC-32 for | ocument] | 1372 | | | | DATA and AC | ] | 1373 | | | | KNOWLEDGMEN | | 1374 | | | | T. | | 1375 | | | | | | 1376 | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | 1377 | MIC64 | | CCM-128 | MIC-64 for | ocument] | 1378 | | | | DATA and AC | ] | 1379 | | | | KNOWLEDGMEN | | 1380 | | | | T. | | 1381 | | | | | | 1382 | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | 1383 | MIC128 | | CCM-128 | MIC-128 for | ocument] | 1384 | | | | DATA and AC | ] | 1385 | | | | KNOWLEDGMEN | | 1386 | | | | T. | | 1387 +-----------------+-----+------------------+-------------+----------+ 1388 Table 3: Key Usage values. 1390 9.4.3.1. Use in IEEE Std 802.15.4 1392 When Link_Layer_Key is used in the context of [IEEE802.15.4], 1393 following considerations apply. 1395 Signaling of different keying modes of [IEEE802.15.4] is done based 1396 on the parameter values present in a Link_Layer_Key object. 1398 o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be 1399 set to 0. key_addinfo parameter MUST be present. key_addinfo 1400 parameter MUST be set to the link-layer address(es) of a single 1401 peer with whom the key should be used. Depending on the 1402 configuration of the network, key_addinfo may carry the peer's 1403 long link-layer address (i.e. pledge identifier), short link-layer 1404 address, or their concatenation with the long address being 1405 encoded first. Which address is carried is determined from the 1406 length of the byte string. 1408 o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a 1409 value different than 0. key_addinfo parameter MUST NOT be 1410 present. 1412 o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter 1413 MUST be set to a value different than 0. key_addinfo parameter 1414 MUST be present. key_addinfo parameter MUST be set to a byte 1415 string, exactly 4 bytes long. key_addinfo parameter carries the 1416 Key Source parameter used to configure [IEEE802.15.4]. 1418 o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter 1419 MUST be set to a value different than 0. key_addinfo parameter 1420 MUST be present. key_addinfo parameter MUST be set to a byte 1421 string, exactly 8 bytes long. key_addinfo parameter carries the 1422 Key Source parameter used to configure [IEEE802.15.4]. 1424 In all cases, key_usage parameter determines how a particular key 1425 should be used in respect to incoming and outgoing security policies. 1427 For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" 1428 parameter of {{IEEE802.15.4} that is signaled in all outgoing frames 1429 secured with a given key. The maximum value key_id can have is 254. 1430 The value of 255 is reserved in {{IEEE802.15.4} and is therefore 1431 considered invalid. 1433 Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a 1434 trusted third party and assign pairwise keys between nodes in the 1435 network. How JRC learns about the network topology is out of scope 1436 of this specification, but could be done through 6LBR - JRC signaling 1437 for example. Pairwise keys could also be derived through a key 1438 agreement protocol executed between the peers directly, where the 1439 authentication is based on the symmetric cryptographic material 1440 provided to both peers by the JRC. Such a protocol is out of scope 1441 of this specification. 1443 9.4.4. Short Identifier 1445 The Short_Identifier object represents an identifier assigned to the 1446 pledge. It is encoded as a CBOR array object, containing, in order: 1448 o identifier: The short identifier assigned to the pledge, encoded 1449 as a byte string. This parameter MUST be included. The 1450 identifier MUST be unique in the set of all identifiers assigned 1451 in a network that is managed by a JRC. In case the identifier is 1452 invalid, the decoder MUST silently ignore the Short_Identifier 1453 object. 1455 o lease_time: The validity of the identifier in hours after the 1456 reception of the CBOR object, encoded as a CBOR unsigned integer. 1457 This parameter MAY be included. The node MUST stop using the 1458 assigned short identifier after the expiry of the lease_time 1459 interval. It is up to the JRC to renew the lease before the 1460 expiry of the previous interval. The JRC updates the lease by 1461 executing the Parameter Update exchange with the node and 1462 including the Short_Identifier in the Configuration object, as 1463 described in Section 9.2. In case the lease expires, the node 1464 SHOULD initiate a new join exchange, as described in Section 9.1. 1465 In case this parameter is omitted, the value of positive infinity 1466 MUST be assumed, meaning that the identifier is valid for as long 1467 as the node participates in the network. 1469 The CDDL fragment that represents the text above for the 1470 Short_Identifier follows. 1472 Short_Identifier = [ 1473 identifier : bstr, 1474 ? lease_time : uint 1475 ] 1477 9.4.4.1. Use in IEEE Std 802.15.4 1479 When Short_Identifier is used in the context of [IEEE802.15.4], 1480 following considerations apply. 1482 The identifier MUST be used to set the short address of IEEE Std 1483 802.15.4 module. When operating in TSCH mode, the identifier MUST be 1484 unique in the set of all identifiers assigned in multiple networks 1485 that share link-layer key(s). If the length of the byte string 1486 corresponding to the identifier parameter is different than 2, the 1487 identifier is considered invalid. The values 0xfffe and 0xffff are 1488 reserved by [IEEE802.15.4] and their use is considered invalid. 1490 The security properties offered by the [IEEE802.15.4] link-layer in 1491 TSCH mode are conditioned on the uniqueness requirement of the short 1492 identifier (i.e. short address). The short address is one of the 1493 inputs in the construction of the nonce, which is used to protect 1494 link-layer frames. If a misconfiguration occurs, and the same short 1495 address is assigned twice under the same link-layer key, the loss of 1496 security properties is eminent. For this reason, practices where the 1497 pledge generates the short identifier locally are not safe and are 1498 likely to result in the loss of link-layer security properties. 1500 The JRC MUST ensure that at any given time there are never two same 1501 short identifiers being used under the same link-layer key. If the 1502 lease_time parameter of a given Short_Identifier object is set to 1503 positive infinity, care needs to be taken that the corresponding 1504 identifier is not assigned to another node until the JRC is certain 1505 that it is no longer in use, potentially through out-of-band 1506 signaling. If the lease_time parameter expires for any reason, the 1507 JRC should take into consideration potential ongoing transmissions by 1508 the joined node, which may be hanging in the queues, before assigning 1509 the same identifier to another node. 1511 9.4.5. Error Object 1513 The Error object is encoded as a CBOR array object, containing in 1514 order: 1516 o error_code: Error code for the first encountered error while 1517 processing a CoJP object, encoded as an unsigned integer. This 1518 parameter MUST be included. This parameter MUST be set to the 1519 "Value" column of the "CoJP Error Registry" (Section 12.3). 1521 o error_addinfo: Additional information relevant to the error. This 1522 parameter MUST be included. This parameter MUST be set as 1523 described by the "Additional info" column of the "CoJP Error 1524 Registry" (Section 12.3). 1526 o error_description: Human-readable description of the error, 1527 encoded as a text string. This parameter MAY be included. The 1528 RECOMMENDED setting of this parameter is the "Description" column 1529 of the "CoJP Error Registry" Section 12.3). 1531 The CDDL fragment that represents the text above for the Error object 1532 follows. 1534 Error = [ 1535 error_code : int, 1536 error_addinfo : int / bstr / tstr / nil, 1537 ? error_description : tstr, 1538 ] 1540 +-----------------+-------+---------------+------------+------------+ 1541 | Description | Value | Additional | Additional | Reference | 1542 | | | info | info type | | 1543 +-----------------+-------+---------------+------------+------------+ 1544 | Invalid | 0 | None | nil | [[this | 1545 | Join_Request | | | | document]] | 1546 | object | | | | | 1547 | | | | | | 1548 | Invalid | 1 | None | nil | [[this | 1549 | Configuration | | | | document]] | 1550 | object | | | | | 1551 | | | | | | 1552 | Invalid | 2 | None | nil | [[this | 1553 | parameter: role | | | | document]] | 1554 | | | | | | 1555 | Invalid | 3 | None | nil | [[this | 1556 | parameter: | | | | document]] | 1557 | network | | | | | 1558 | identifier | | | | | 1559 | | | | | | 1560 | Invalid | 4 | None | nil | [[this | 1561 | parameter: | | | | document]] | 1562 | link-layer key | | | | | 1563 | set | | | | | 1564 | | | | | | 1565 | Invalid | 5 | Index of the | uint | [[this | 1566 | parameter: | | invalid key | | document]] | 1567 | link-layer key | | | | | 1568 | | | | | | 1569 | Invalid | 6 | None | nil | [[this | 1570 | paramater: | | | | document]] | 1571 | short | | | | | 1572 | identifier | | | | | 1573 | | | | | | 1574 | Invalid | 7 | None | nil | [[this | 1575 | parameter: JRC | | | | document]] | 1576 | address | | | | | 1577 | | | | | | 1578 | Invalid | 8 | None | nil | [[this | 1579 | parameter: | | | | document]] | 1580 | network prefix | | | | | 1581 | | | | | | 1582 | Invalid | 9 | Next | bstr | [[this | 1583 | parameter: | | acceptable | | document]] | 1584 | OSCORE partial | | OSCORE | | | 1585 | IV | | partial IV | | | 1586 +-----------------+-------+---------------+------------+------------+ 1588 Table 4: CoJP error codes. 1590 9.5. Parameters 1592 CoJP uses the following parameters: 1594 +-----------------------+----------------+ 1595 | Name | Default Value | 1596 +-----------------------+----------------+ 1597 | TIMEOUT_BASE | 10 s | 1598 +-----------------------+----------------+ 1599 | TIMEOUT_RANDOM_FACTOR | 1.5 | 1600 +-----------------------+----------------+ 1601 | MAX_RETRANSMIT | 4 | 1602 +----------------------------------------+ 1604 The values of TIMEOUT_BASE, TIMEOUT_RANDOM_FACTOR, MAX_RETRANSMIT may 1605 be configured to values specific to the deployment. The default 1606 values have been chosen to accommodate a wide range of deployments, 1607 taking into account dense networks. 1609 9.6. Mandatory to Implement Algorithms 1611 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 1612 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 1613 securing IEEE Std 802.15.4 frames, and hardware acceleration for it 1614 is present in virtually all compliant radio chips. With this choice, 1615 CoAP messages are protected with an 8-byte CCM authentication tag, 1616 and the algorithm uses 13-byte long nonces. 1618 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. 1620 The mandatory to implement key derivation function is HKDF [RFC5869], 1621 instantiated with a SHA-256 hash. 1623 10. Security Considerations 1625 Since this document uses the pledge identifier to set the ID Context 1626 parameter of OSCORE, an important security requirement is that the 1627 pledge identifier is unique in the set of all pledge identifiers 1628 managed by a JRC. The uniqueness of the pledge identifier ensures 1629 unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also 1630 allows the JRC to retrieve the correct security context, upon the 1631 reception of a Join Request message. The management of pledge 1632 identifiers is simplified if the globally unique EUI-64 is used, but 1633 this comes with privacy risks, as discussed in Section 11. 1635 This document further mandates that the (6LBR) pledge and the JRC are 1636 provisioned with unique PSKs. The PSK is used to set the OSCORE 1637 Master Secret during security context derivation and is important for 1638 mutual authentication of the (6LBR) pledge and the JRC. Should an 1639 attacker come to know the PSK, then a man-in-the-middle attack is 1640 possible. 1642 Many vendors are known to use unsafe practices when generating and 1643 provisioning PSKs. The use of a single PSK shared among a group of 1644 devices is a common pitfall that results in poor security. In this 1645 case, the compromise of a single device is likely to lead to a 1646 compromise of the whole batch, with the attacker having the ability 1647 to impersonate a legitimate device and join the network, generate 1648 bogus data and disturb the network operation. As a reminder, recall 1649 the well-known problem with Bluetooth headsets with a "0000" pin. 1650 Additionally, some vendors use methods such as scrambling or hashing 1651 of device serial numbers or their EUI-64 to generate "unique" PSKs. 1652 Without any secret information involved, the effort that the attacker 1653 needs to invest into breaking these unsafe derivation methods is 1654 quite low, resulting in the possible impersonation of any device from 1655 the batch, without even needing to compromise a single device. The 1656 use of cryptographically secure random number generators to generate 1657 the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms 1658 using deterministic methods. 1660 The JP forwards the unauthenticated join traffic into the network. A 1661 simple bandwidth cap on the JP prevents it from forwarding more 1662 traffic than the network can handle. This forces attackers to use 1663 more than one Join Proxy if they wish to overwhelm the network. 1664 Marking the join traffic packets with a non-zero DSCP allows the 1665 network to carry the traffic if it has capacity, but encourages the 1666 network to drop the extra traffic rather than add bandwidth due to 1667 that traffic. 1669 The shared nature of the "minimal" cell used for the join traffic 1670 makes the network prone to DoS attacks by congesting the JP with 1671 bogus traffic. Such an attacker is limited by its maximum transmit 1672 power. The redundancy in the number of deployed JPs alleviates the 1673 issue and also gives the pledge a possibility to use the best 1674 available link for joining. How a network node decides to become a 1675 JP is out of scope of this specification. 1677 At the beginning of the join process, the pledge has no means of 1678 verifying the content in the EB, and has to accept it at "face 1679 value". In case the pledge tries to join an attacker's network, the 1680 Join Response message will either fail the security check or time 1681 out. The pledge may implement a temporary blacklist in order to 1682 filter out undesired EBs and try to join using the next seemingly 1683 valid EB. This blacklist alleviates the issue, but is effectively 1684 limited by the node's available memory. Bogus beacons prolong the 1685 join time of the pledge, and so the time spent in "minimal" [RFC8180] 1686 duty cycle mode. 1688 11. Privacy Considerations 1690 The join solution specified in this document relies on the uniqueness 1691 of the pledge identifier in the set of all pledge identifiers managed 1692 by a JRC. This identifier is transferred in clear as an OSCORE kid 1693 context. The use of the globally unique EUI-64 as pledge identifier 1694 simplifies the management but comes with certain privacy risks. The 1695 implications are thoroughly discussed in [RFC7721] and comprise 1696 correlation of activities over time, location tracking, address 1697 scanning and device-specific vulnerability exploitation. Since the 1698 join process occurs rarely compared to the network lifetime, long- 1699 term threats that arise from using EUI-64 as the pledge identifier 1700 are minimal. In addition, the Join Response message contains a short 1701 address which is assigned by the JRC to the (6LBR) pledge. The 1702 assigned short address SHOULD be uncorrelated with the long-term 1703 pledge identifier. The short address is encrypted in the response. 1704 Once the join process completes, the new node uses the short 1705 addresses for all further layer 2 (and layer-3) operations. This 1706 reduces the aforementioned privacy risks as the short layer-2 address 1707 (visible even when the network is encrypted) is not traceable between 1708 locations and does not disclose the manufacturer, as is the case of 1709 EUI-64. However, an eavesdropper with access to the radio medium 1710 during the join process may be able to correlate the assigned short 1711 address with the extended address based on timing information with a 1712 non-negligible probability. This probability decreases with an 1713 increasing number of pledges joining concurrently. 1715 12. IANA Considerations 1717 Note to RFC Editor: Please replace all occurrences of "[[this 1718 document]]" with the RFC number of this specification. 1720 This document allocates a well-known name under the .arpa name space 1721 according to the rules given in [RFC3172]. The name "6tisch.arpa" is 1722 requested. No subdomains are expected. No A, AAAA or PTR record is 1723 requested. 1725 12.1. CoJP Parameters Registry 1727 This section defines a sub-registries within the "IPv6 over the TSCH 1728 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1729 "Constrained Join Protocol Parameters Registry". 1731 The columns of the registry are: 1733 Name: This is a descriptive name that enables an easier reference to 1734 the item. It is not used in the encoding. 1736 Label: The value to be used to identify this parameter. The label is 1737 an unsigned integer. 1739 CBOR type: This field contains the CBOR type for the field. 1741 Description: This field contains a brief description for the field. 1743 Reference: This field contains a pointer to the public specification 1744 for the field, if one exists. 1746 This registry is to be populated with the values in Table 2. 1748 The amending formula for this sub-registry is: Different ranges of 1749 values use different registration policies [RFC8126]. Integer values 1750 from -256 to 255 are designated as Standards Action. Integer values 1751 from -65536 to -257 and from 256 to 65535 are designated as 1752 Specification Required. Integer values greater than 65535 are 1753 designated as Expert Review. Integer values less than -65536 are 1754 marked as Private Use. 1756 12.2. CoJP Key Usage Registry 1758 This section defines a sub-registries within the "IPv6 over the TSCH 1759 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1760 "Constrained Join Protocol Key Usage Registry". 1762 The columns of this registry are: 1764 Name: This is a descriptive name that enables easier reference to the 1765 item. The name MUST be unique. It is not used in the encoding. 1767 Value: This is the value used to identify the key usage setting. 1768 These values MUST be unique. The value is an integer. 1770 Algorithm: This is a descriptive name of the link-layer algorithm in 1771 use and uniquely determines the key length. The name is not used in 1772 the encoding. 1774 Description: This field contains a description of the key usage 1775 setting. The field should describe in enough detail how the key is 1776 to be used with different frame types, specific for the link-layer 1777 technology in question. 1779 Reference: This contains a pointer to the public specification for 1780 the field, if one exists. 1782 This registry is to be populated with the values in Table 3. 1784 The amending formula for this sub-registry is: Different ranges of 1785 values use different registration policies [RFC8126]. Integer values 1786 from -256 to 255 are designated as Standards Action. Integer values 1787 from -65536 to -257 and from 256 to 65535 are designated as 1788 Specification Required. Integer values greater than 65535 are 1789 designated as Expert Review. Integer values less than -65536 are 1790 marked as Private Use. 1792 12.3. CoJP Error Registry 1794 This section defines a sub-registries within the "IPv6 over the TSCH 1795 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1796 "Constrained Join Protocol Error Registry". 1798 The columns of this registry are: 1800 Description: This is a descriptive human-readble name. The 1801 description MUST be unique. It is not used in the encoding. 1803 Value: This is the value used to identify the error. These values 1804 MUST be unique. The value is an integer. 1806 Additional information: This is a descriptive name of additional 1807 information that is meaningful for the error. The name is not used 1808 in the encoding. 1810 Additional information type: A CBOR type of the additional 1811 information field. 1813 Reference: This contains a pointer to the public specification for 1814 the field, if one exists. 1816 This registry is to be populated with the values in Table 4. 1818 The amending formula for this sub-registry is: Different ranges of 1819 values use different registration policies [RFC8126]. Integer values 1820 from -256 to 255 are designated as Standards Action. Integer values 1821 from -65536 to -257 and from 256 to 65535 are designated as 1822 Specification Required. Integer values greater than 65535 are 1823 designated as Expert Review. Integer values less than -65536 are 1824 marked as Private Use. 1826 13. Acknowledgments 1828 The work on this document has been partially supported by the 1829 European Union's H2020 Programme for research, technological 1830 development and demonstration under grant agreement No 644852, 1831 project ARMOUR. 1833 The following individuals provided input to this document (in 1834 alphabetic order): Tengfei Chang, Klaus Hartke, Tero Kivinen, Jim 1835 Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal Thubert, William 1836 Vignat, Xavier Vilajosana, Thomas Watteyne. 1838 14. References 1840 14.1. Normative References 1842 [I-D.ietf-core-object-security] 1843 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1844 "Object Security for Constrained RESTful Environments 1845 (OSCORE)", draft-ietf-core-object-security-15 (work in 1846 progress), August 2018. 1848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1849 Requirement Levels", BCP 14, RFC 2119, 1850 DOI 10.17487/RFC2119, March 1997, 1851 . 1853 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1854 "Assured Forwarding PHB Group", RFC 2597, 1855 DOI 10.17487/RFC2597, June 1999, 1856 . 1858 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1859 Requirements for the Address and Routing Parameter Area 1860 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1861 September 2001, . 1863 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1864 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1865 October 2013, . 1867 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1868 Application Protocol (CoAP)", RFC 7252, 1869 DOI 10.17487/RFC7252, June 2014, 1870 . 1872 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1873 Writing an IANA Considerations Section in RFCs", BCP 26, 1874 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1875 . 1877 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1878 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1879 . 1881 14.2. Informative References 1883 [I-D.hartke-core-stateless] 1884 Hartke, K., "Extended Tokens and Stateless Clients in the 1885 Constrained Application Protocol (CoAP)", draft-hartke- 1886 core-stateless-02 (work in progress), October 2018. 1888 [I-D.ietf-6tisch-6top-protocol] 1889 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 1890 Operation Sublayer Protocol (6P)", draft-ietf-6tisch-6top- 1891 protocol-12 (work in progress), June 2018. 1893 [I-D.ietf-6tisch-architecture] 1894 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1895 of IEEE 802.15.4", draft-ietf-6tisch-architecture-15 (work 1896 in progress), October 2018. 1898 [I-D.ietf-6tisch-terminology] 1899 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1900 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 1901 draft-ietf-6tisch-terminology-10 (work in progress), March 1902 2018. 1904 [I-D.ietf-cbor-cddl] 1905 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 1906 definition language (CDDL): a notational convention to 1907 express CBOR and JSON data structures", draft-ietf-cbor- 1908 cddl-05 (work in progress), August 2018. 1910 [IEEE802.15.4] 1911 IEEE standard for Information Technology, ., "IEEE Std 1912 802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 1914 [NIST800-90A] 1915 NIST Special Publication 800-90A, Revision 1, ., Barker, 1916 E., and J. Kelsey, "Recommendation for Random Number 1917 Generation Using Deterministic Random Bit Generators", 1918 2015. 1920 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1921 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1922 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1923 . 1925 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1926 "Transmission of IPv6 Packets over IEEE 802.15.4 1927 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1928 . 1930 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1931 Key Derivation Function (HKDF)", RFC 5869, 1932 DOI 10.17487/RFC5869, May 2010, 1933 . 1935 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1936 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1937 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1938 Low-Power and Lossy Networks", RFC 6550, 1939 DOI 10.17487/RFC6550, March 2012, 1940 . 1942 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1943 Bormann, "Neighbor Discovery Optimization for IPv6 over 1944 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1945 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1946 . 1948 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1949 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1950 Internet of Things (IoT): Problem Statement", RFC 7554, 1951 DOI 10.17487/RFC7554, May 2015, 1952 . 1954 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1955 Considerations for IPv6 Address Generation Mechanisms", 1956 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1957 . 1959 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 1960 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 1961 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 1962 May 2017, . 1964 Appendix A. Example 1966 Figure 3 illustrates a successful join protocol exchange. The pledge 1967 instantiates the OSCORE context and derives the AEAD keys and nonces 1968 from the PSK. It uses the instantiated context to protect the Join 1969 Request addressed with a Proxy-Scheme option, the well-known host 1970 name of the JRC in the Uri-Host option, and its EUI-64 as pledge 1971 identifier and OSCORE kid context. Triggered by the presence of a 1972 Proxy-Scheme option, the JP forwards the request to the JRC and sets 1973 the CoAP token to the internally needed state. The JP has learned 1974 the IPv6 address of the JRC when it acted as a pledge and joined the 1975 network. Once the JRC receives the request, it looks up the correct 1976 context based on the kid context parameter. OSCORE data authenticity 1977 verification ensures that the request has not been modified in 1978 transit. In addition, replay protection is ensured through 1979 persistent handling of mutable context parameters. 1981 Once the JP receives the Join Response, it authenticates the state 1982 within the CoAP token before deciding where to forward. The JP sets 1983 its internal state to that found in the token, and forwards the Join 1984 Response to the correct pledge. Note that the JP does not possess 1985 the key to decrypt the CBOR object (configuration) present in the 1986 payload. The Join Response is matched to the Join Request and 1987 verified for replay protection at the pledge using OSCORE processing 1988 rules. In this example, the Join Response does not contain the IPv6 1989 address of the JRC, the pledge hence understands the JRC is co- 1990 located with the 6LBR. 1992 <---E2E OSCORE--> 1993 Client Proxy Server 1994 Pledge JP JRC 1995 | | | 1996 | Join | | Code: { 0.02 } (POST) 1997 | Request | | Token: 0x8c 1998 +--------->| | Proxy-Scheme: [ coap ] 1999 | POST | | Uri-Host: [ 6tisch.arpa ] 2000 | | | Object-Security: [ kid: 0 ] 2001 | | | Payload: kid_context: EUI-64 2002 | | | [ Partial IV: 1, 2003 | | | { Uri-Path:"j", 2004 | | | join_request }, 2005 | | | ] 2006 | | | 2007 | | Join | Code: { 0.01 } (GET) 2008 | | Request | Token: opaque state 2009 | +--------->| Uri-Host: [ 6tisch.arpa ] 2010 | | POST | Object-Security: [ kid: 0 ] 2011 | | | Payload: kid_context: EUI-64 2012 | | | [ Partial IV: 1, 2013 | | | { Uri-Path:"j", 2014 | | | join_request }, 2015 | | | ] 2016 | | | 2017 | | Join | Code: { 2.05 } (Content) 2018 | | Response | Token: 0x7b 2019 | |<---------+ Object-Security: - 2020 | | 2.04 | Payload: [ { configuration }, ] 2021 | | | 2022 | Join | | Code: { 2.05 } (Content) 2023 | Response | | Token: 0x8c 2024 |<---------+ | Object-Security: - 2025 | 2.04 | | Payload: [ { configuration }, ] 2026 | | | 2028 Figure 3: Example of a successful join protocol exchange. { ... } 2029 denotes encryption and authentication, [ ... ] denotes 2030 authentication. 2032 Where the join_request object is: 2034 join_request: 2035 { 2036 5 : h'cafe' / PAN ID of the network pledge is attempting to join / 2037 } 2038 Since the role parameter is not present, the default role of "6TiSCH 2039 Node" is implied. 2041 The join_request object encodes to h'a10542cafe' with a size of 5 2042 bytes. 2044 And the configuration object is: 2046 configuration: 2047 { 2048 2 : [ / link-layer key set / 2049 1, / key_id / 2050 h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / 2051 ], 2052 3 : [ / short identifier / 2053 h'af93' / assigned short address / 2054 ] 2055 } 2057 Since the key_usage parameter is not present in the link-layer key 2058 set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. 2059 Since key_addinfo parameter is not present and key_id is different 2060 than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since 2061 the lease_time parameter is not present in the short identifier 2062 object, the default value of positive infinity is implied. 2064 The configuration object encodes to 2066 h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size 2067 of 26 bytes. 2069 Authors' Addresses 2071 Malisa Vucinic (editor) 2072 University of Montenegro 2073 Dzordza Vasingtona bb 2074 Podgorica 81000 2075 Montenegro 2077 Email: malisav@ac.me 2078 Jonathan Simon 2079 Analog Devices 2080 32990 Alvarado-Niles Road, Suite 910 2081 Union City, CA 94587 2082 USA 2084 Email: jonathan.simon@analog.com 2086 Kris Pister 2087 University of California Berkeley 2088 512 Cory Hall 2089 Berkeley, CA 94720 2090 USA 2092 Email: pister@eecs.berkeley.edu 2094 Michael Richardson 2095 Sandelman Software Works 2096 470 Dawson Avenue 2097 Ottawa, ON K1Z5V7 2098 Canada 2100 Email: mcr+ietf@sandelman.ca