idnits 2.17.1 draft-ietf-6tisch-minimal-security-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 28, 2019) is 1641 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) ** 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-27 == Outdated reference: A later version (-08) exists of draft-ietf-core-stateless-02 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 Inria 4 Intended status: Standards Track J. Simon 5 Expires: April 30, 2020 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 October 28, 2019 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-13 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 30, 2020. 50 Copyright Notice 52 Copyright (c) 2019 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. Provisioning Phase . . . . . . . . . . . . . . . . . . . . . 5 70 4. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 72 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 73 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 74 4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 75 5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 76 5.1. Distribution of Time . . . . . . . . . . . . . . . . . . 11 77 6. Network-layer Configuration . . . . . . . . . . . . . . . . . 11 78 6.1. Identification of Unauthenticated Traffic . . . . . . . . 12 79 7. Application-level Configuration . . . . . . . . . . . . . . . 14 80 7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 14 81 7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 15 82 7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 18 84 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 20 85 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 21 86 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 22 87 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24 88 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 37 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 90 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 92 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 40 93 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 41 94 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 42 95 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 97 13.1. Normative References . . . . . . . . . . . . . . . . . . 43 98 13.2. Informative References . . . . . . . . . . . . . . . . . 44 99 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 45 100 Appendix B. Lightweight Implementation Option . . . . . . . . . 48 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 103 1. Introduction 105 This document defines a "secure join" solution for a new device, 106 called "pledge", to securely join a 6TiSCH network. The term "secure 107 join" refers to network access authentication, authorization and 108 parameter distribution, as defined in [I-D.ietf-6tisch-architecture]. 109 The Constrained Join Protocol (CoJP) defined in this document handles 110 parameter distribution needed for a pledge to become a joined node. 111 Authorization mechanisms are considered out of scope. Mutual 112 authentication during network access is achieved through the use of a 113 secure channel, as configured by this document. This document also 114 specifies a configuration of different layers of the 6TiSCH protocol 115 stack that reduces the Denial of Service (DoS) attack surface during 116 the join process. 118 This document presumes a 6TiSCH network as described by [RFC7554] and 119 [RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their 120 radio turned off most of the time, to conserve energy. As a 121 consequence, the link used by a new device for joining the network 122 has limited bandwidth [RFC8180]. The secure join solution defined in 123 this document therefore keeps the number of over-the-air exchanges to 124 a minimum. 126 The micro-controllers at the heart of 6TiSCH nodes have a small 127 amount of code memory. It is therefore paramount to reuse existing 128 protocols available as part of the 6TiSCH stack. At the application 129 layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web 130 transfer, and on OSCORE [RFC8613] for its end-to-end security. The 131 secure join solution defined in this document therefore reuses those 132 two protocols as its building blocks. 134 CoJP is a generic protocol that can be used as-is in all modes of 135 IEEE Std 802.15.4, including the Time-Slotted Channel Hopping (TSCH) 136 mode 6TiSCH is based on. CoJP may as well be used in other (low- 137 power) networking technologies where efficiency in terms of 138 communication overhead and code footprint is important. In such a 139 case, it may be necessary to define configuration parameters specific 140 to the technology in question, through companion documents. The 141 overall process described in Section 4 and the configuration of the 142 stack is specific to 6TiSCH. 144 CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a 145 central entity. The configuration defined in this document assumes 146 that the pledge and the JRC share a secret cryptographic key, called 147 PSK (pre-shared key). The PSK is used to configure OSCORE to provide 148 a secure channel to CoJP. How the PSK is installed is out of scope 149 of this document: this may happen during the provisioning phase or by 150 a key exchange protocol that may precede the execution of CoJP. 152 When the pledge seeks admission to a 6TiSCH network, it first 153 synchronizes to it, by initiating the passive scan defined in 154 [IEEE802.15.4]. The pledge then exchanges CoJP messages with the 155 JRC; these messages can be forwarded by nodes already part of the 156 6TiSCH network, called Join Proxies. The messages exchanged allow 157 the JRC and the pledge to mutually authenticate, based on the 158 properties provided by OSCORE. They also allow the JRC to configure 159 the pledge with link-layer keying material, short identifier and 160 other parameters. After this secure join process successfully 161 completes, the joined node can interact with its neighbors to request 162 additional bandwidth using the 6top Protocol [RFC8480] and start 163 sending application traffic. 165 2. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in 170 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 The reader is expected to be familiar with the terms and concepts 174 defined in [I-D.ietf-6tisch-architecture], [RFC7252], [RFC8613], and 175 [RFC8152]. 177 The specification also includes a set of informative specifications 178 using the Concise data definition language (CDDL) 179 [I-D.ietf-cbor-cddl]. 181 The following terms defined in [I-D.ietf-6tisch-architecture] are 182 used extensively throughout this document: 184 o pledge 186 o joined node 188 o join proxy (JP) 190 o join registrar/coordinator (JRC) 191 o enhanced beacon (EB) 193 o join protocol 195 o join process 197 The following terms defined in [RFC8505] are also used throughout 198 this document: 200 o 6LoWPAN Border Router (6LBR) 202 o 6LoWPAN Node (6LN) 204 The term "6LBR" is used interchangeably with the term "DODAG root" 205 defined in [RFC6550], assuming the two entities are co-located, as 206 recommended by [I-D.ietf-6tisch-architecture]. 208 The term "pledge", as used throughout the document, explicitly 209 denotes non-6LBR devices attempting to join the network using their 210 IEEE Std 802.15.4 network interface. The device that attempts to 211 join as the 6LBR of the network and does so over another network 212 interface is explicitly denoted as the "6LBR pledge". When the text 213 equally applies to the pledge and the 6LBR pledge, the "(6LBR) 214 pledge" form is used. 216 In addition, we use generic terms "pledge identifier" and "network 217 identifier". See Section 3. 219 The terms "secret key" and "symmetric key" are used interchangeably. 221 3. Provisioning Phase 223 The (6LBR) pledge is provisioned with certain parameters before 224 attempting to join the network, and the same parameters are 225 provisioned to the JRC. There are many ways by which this 226 provisioning can be done. Physically, the parameters can be written 227 into the (6LBR) pledge using a number of mechanisms, such as a JTAG 228 interface, a serial (craft) console interface, pushing buttons 229 simultaneously on different devices, over-the-air configuration in a 230 Faraday cage, etc. The provisioning can be done by the vendor, the 231 manufacturer, the integrator, etc. 233 Details of how this provisioning is done is out of scope of this 234 document. What is assumed is that there can be a secure, private 235 conversation between the JRC and the (6LBR) pledge, and that the two 236 devices can exchange the parameters. 238 Parameters that are provisioned to the (6LBR) pledge include: 240 o pledge identifier. The pledge identifier identifies the (6LBR) 241 pledge. The pledge identifier MUST be unique in the set of all 242 pledge identifiers managed by a JRC. The pledge identifier 243 uniqueness is an important security requirement, as discussed in 244 Section 9. The pledge identifier is typically the globally unique 245 64-bit Extended Unique Identifier (EUI-64) of the IEEE Std 246 802.15.4 device, in which case it is provisioned by the hardware 247 manufacturer. The pledge identifier is used to generate the IPv6 248 addresses of the (6LBR) pledge and to identify it during the 249 execution of the join protocol. For privacy reasons (see 250 Section 10), it is possible to use a pledge identifier different 251 from the EUI-64. For example, a pledge identifier may be a random 252 byte string, but care needs to be taken that such a string meets 253 the uniqueness requirement. 255 o Pre-Shared Key (PSK). A secret cryptographic key shared between 256 the (6LBR) pledge and the JRC. The JRC additionally needs to 257 store the pledge identifier bound to the given PSK. Each (6LBR) 258 pledge MUST be provisioned with a unique PSK. The PSK SHOULD be a 259 cryptographically strong key, at least 128 bits in length, 260 indistinguishable by feasible computation from a random uniform 261 string of the same length. How the PSK is generated and/or 262 provisioned is out of scope of this specification. This could be 263 done during a provisioning step or companion documents can specify 264 the use of a key agreement protocol. Common pitfalls when 265 generating PSKs are discussed in Section 9. In case of device re- 266 commissioning to a new owner, the PSK MUST be changed. 268 o Optionally, a network identifier. The network identifier 269 identifies the 6TiSCH network. The network identifier MUST be 270 carried within Enhanced Beacon (EB) frames. Typically, the 16-bit 271 Personal Area Network Identifier (PAN ID) defined in 272 [IEEE802.15.4] is used as the network identifier. However, PAN ID 273 is not considered a stable network identifier as it may change 274 during network lifetime if a collision with another network is 275 detected. Companion documents can specify the use of a different 276 network identifier for join purposes, but this is out of scope of 277 this specification. Provisioning the network identifier is 278 RECOMMENDED. However, due to operational constraints, the network 279 identifier may not be known at the time when the provisioning is 280 done. In case this parameter is not provisioned to the pledge, 281 the pledge attempts to join one advertised network at a time, 282 which significantly prolongs the join process. This parameter 283 MUST be provisioned to the 6LBR pledge. 285 o Optionally, any non-default algorithms. The default algorithms 286 are specified in Section 7.3.3. When algorithm identifiers are 287 not exchanged, the use of these default algorithms is implied. 289 Additionally, the 6LBR pledge that is not co-located with the JRC 290 needs to be provisioned with: 292 o Global IPv6 address of the JRC. This address is used by the 6LBR 293 pledge to address the JRC during the join process. The 6LBR 294 pledge may also obtain the IPv6 address of the JRC through other 295 available mechanisms, such as DHCPv6, GRASP, mDNS, the use of 296 which is out of scope of this document. Pledges do not need to be 297 provisioned with this address as they discover it dynamically 298 through CoJP. 300 4. Join Process Overview 302 This section describes the steps taken by a pledge in a 6TiSCH 303 network. When a pledge seeks admission to a 6TiSCH network, the 304 following exchange occurs: 306 1. The pledge listens for an Enhanced Beacon (EB) frame 307 [IEEE802.15.4]. This frame provides network synchronization 308 information, and tells the device when it can send a frame to the 309 node sending the beacons, which acts as a Join Proxy (JP) for the 310 pledge, and when it can expect to receive a frame. The Enhanced 311 Beacon provides the L2 address of the JP and it may also provide 312 its link-local IPv6 address. 314 2. The pledge configures its link-local IPv6 address and advertises 315 it to the JP using Neighbor Discovery. This step may be omitted 316 if the link-local address has been derived from a known unique 317 interface identifier, such as an EUI-64 address. 319 3. The pledge sends a Join Request to the JP in order to securely 320 identify itself to the network. The Join Request is forwarded to 321 the JRC. 323 4. In case of successful processing of the request, the pledge 324 receives a Join Response from the JRC (via the JP). The Join 325 Response contains configuration parameters necessary for the 326 pledge to join the network. 328 From the pledge's perspective, joining is a local phenomenon - the 329 pledge only interacts with the JP, and it needs not know how far it 330 is from the 6LBR, or how to route to the JRC. Only after 331 establishing one or more link-layer keys does it need to know about 332 the particulars of a 6TiSCH network. 334 The join process is shown as a transaction diagram in Figure 1: 336 +--------+ +-------+ +--------+ 337 | pledge | | JP | | JRC | 338 | | | | | | 339 +--------+ +-------+ +--------+ 340 | | | 341 |<---Enhanced Beacon (1)---| | 342 | | | 343 |<-Neighbor Discovery (2)->| | 344 | | | 345 |-----Join Request (3a)----|----Join Request (3a)---->| \ 346 | | | | CoJP 347 |<----Join Response (3b)---|----Join Response (3b)----| / 348 | | | 350 Figure 1: Overview of a successful join process. 352 As other nodes in the network, the 6LBR node may act as the JP. The 353 6LBR may in addition be co-located with the JRC. 355 The details of each step are described in the following sections. 357 4.1. Step 1 - Enhanced Beacon 359 The pledge synchronizes to the network by listening for, and 360 receiving, an Enhanced Beacon (EB) sent by a node already in the 361 network. This process is entirely defined by [IEEE802.15.4], and 362 described in [RFC7554]. 364 Once the pledge hears an EB, it synchronizes to the joining schedule 365 using the cells contained in the EB. The pledge can hear multiple 366 EBs; the selection of which EB to use is out of the scope for this 367 document, and is discussed in [RFC7554]. Implementers should make 368 use of information such as: what network identifier the EB contains, 369 the value of the Join Metric field within EBs, whether the source 370 link-layer address of the EB has been tried before, what signal 371 strength the different EBs were received at, etc. In addition, the 372 pledge may be pre-configured to search for EBs with a specific 373 network identifier. 375 If the pledge is not provisioned with the network identifier, it 376 attempts to join one network at a time, as described in 377 Section 8.1.1. 379 Once the pledge selects the EB, it synchronizes to it and transitions 380 into a low-power mode. It follows the schedule information contained 381 in the EB which indicates the slots that the pledge may use for the 382 join process. During the remainder of the join process, the node 383 that has sent the EB to the pledge acts as the JP. 385 At this point, the pledge may proceed to step 2, or continue to 386 listen for additional EBs. 388 4.2. Step 2 - Neighbor Discovery 390 The pledge forms its link-local IPv6 address based on the interface 391 identifier, as per [RFC4944]. The pledge MAY perform the Neighbor 392 Solicitation / Neighbor Advertisement exchange with the JP, as per 393 Section 5.6 of [RFC8505]. The pledge and the JP use their link-local 394 IPv6 addresses for all subsequent communication during the join 395 process. 397 Note that Neighbor Discovery exchanges at this point are not 398 protected with link-layer security as the pledge is not in possession 399 of the keys. How JP accepts these unprotected frames is discussed in 400 Section 5. 402 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution 404 The pledge triggers the join exchange of the Constrained Join 405 Protocol (CoJP). The join exchange consists of two messages: the 406 Join Request message (Step 3a), and the Join Response message 407 conditioned on the successful security processing of the request 408 (Step 3b). 410 All CoJP messages are exchanged over a secure end-to-end channel that 411 provides confidentiality, data authenticity and replay protection. 412 Frames carrying CoJP messages are not protected with link-layer 413 security when exchanged between the pledge and the JP as the pledge 414 is not in possession of the link-layer keys in use. How JP and 415 pledge accept these unprotected frames is discussed in Section 5. 416 When frames carrying CoJP messages are exchanged between nodes that 417 have already joined the network, the link-layer security is applied 418 according to the security configuration used in the network. 420 4.3.1. Step 3a - Join Request 422 The Join Request is a message sent from the pledge to the JP, and 423 which the JP forwards to the JRC. The pledge indicates in the Join 424 Request the role it requests to play in the network, as well as the 425 identifier of the network it requests to join. The JP forwards the 426 Join Request to the JRC on the existing links. How exactly this 427 happens is out of scope of this document; some networks may wish to 428 dedicate specific link layer resources for this join traffic. 430 4.3.2. Step 3b - Join Response 432 The Join Response is sent by the JRC to the pledge, and is forwarded 433 through the JP. The packet containing the Join Response travels from 434 the JRC to the JP using the operating routes in the network. The JP 435 delivers it to the pledge. The JP operates as the application-layer 436 proxy. 438 The Join Response contains different parameters needed by the pledge 439 to become a fully operational network node. These parameters include 440 the link-layer key(s) currently in use in the network, the short 441 address assigned to the pledge, the IPv6 address of the JRC needed by 442 the pledge to operate as the JP, among others. 444 4.4. The Special Case of the 6LBR Pledge Joining 446 The 6LBR pledge performs Section 4.3 of the join process described 447 above, just as any other pledge, albeit over a different network 448 interface. There is no JP intermediating the communication between 449 the 6LBR pledge and the JRC, as described in Section 6. The other 450 steps of the described join process do not apply to the 6LBR pledge. 451 How the 6LBR pledge obtains an IPv6 address and triggers the 452 execution of the CoJP protocol is out of scope of this document. 454 5. Link-layer Configuration 456 In an operational 6TiSCH network, all frames MUST use link-layer 457 frame security [RFC8180]. The IEEE Std 802.15.4 security attributes 458 MUST include frame authenticity, and MAY include frame 459 confidentiality (i.e. encryption). 461 The pledge does not initially do any authenticity check of the EB 462 frames, as it does not possess the link-layer key(s) in use. The 463 pledge is still able to parse the contents of the received EBs and 464 synchronize to the network, as EBs are not encrypted [RFC8180]. 466 When sending frames during the join process, the pledge sends 467 unencrypted and unauthenticated frames. The JP accepts these 468 unsecured frames for the duration of the join process. This behavior 469 may be implemented by setting the "secExempt" attribute in the IEEE 470 Std 802.15.4 security configuration tables. How the JP learns 471 whether the join process is ongoing is out of scope of this 472 specification. 474 When the pledge initially synchronizes to the network, it has no 475 means of verifying the authenticity of EB frames. As an attacker can 476 craft a frame that looks like a legitimate EB frame, this opens up a 477 DoS vector, as discussed in Section 9. 479 5.1. Distribution of Time 481 Nodes in a 6TiSCH network keep a global notion of time known as the 482 absolute slot number. Absolute slot number is used in the 483 construction of the link-layer nonce, as defined in [IEEE802.15.4]. 484 The pledge initially synchronizes to the EB frame sent by the JP, and 485 uses the value of the absolute slot number found in the TSCH 486 Synchronization Information Element. At the time of the 487 synchronization, the EB frame can neither be authenticated nor its 488 freshness verified. During the join process, the pledge sends frames 489 that are unprotected at the link-layer and protected end-to-end 490 instead. The pledge does not obtain the time information as the 491 output of the join process as this information is local to the 492 network and may not be known at the JRC. 494 This enables an attack on the pledge where the attacker replays to 495 the pledge legitimate EB frames obtained from the network and acts as 496 a man-in-the-middle between the pledge and the JP. The EB frames 497 will make the pledge believe that the replayed absolute slot number 498 value is the current notion of time in the network. By forwarding 499 the join traffic to the legitimate JP, the attacker enables the 500 pledge to join the network. Under different conditions relating to 501 the reuse of the pledge's short address by the JRC or its attempt to 502 rejoin the network, this may cause the pledge to reuse the link-layer 503 nonce in the first frame it sends protected after the join process is 504 completed. 506 For this reason, all frames originated at the JP and destined to the 507 pledge during the join process MUST be authenticated at the link- 508 layer using the key that is normally in use in the network. Link- 509 layer security processing at the pledge for these frames will fail as 510 the pledge is not yet in possession of the key. The pledge 511 acknowledges these frames without link-layer security, and JP accepts 512 the unsecured acknowledgment due to the secExempt attribute set for 513 the pledge. The frames should be passed to the upper layer for 514 processing using the promiscuous mode of [IEEE802.15.4] or another 515 appropriate mechanism. When the upper layer processing is completed 516 and the link-layer keys are configured, the upper layer MUST trigger 517 the security processing of the corresponding frame. Once the 518 security processing of the frame carrying the Join Response message 519 is successful, the current absolute slot number kept locally at the 520 pledge SHALL be declared as valid. 522 6. Network-layer Configuration 524 The pledge and the JP SHOULD keep a separate neighbor cache for 525 untrusted entries and use it to store each other's information during 526 the join process. Mixing neighbor entries belonging to pledges and 527 nodes that are part of the network opens up the JP to a DoS attack, 528 as the attacker may fill JP's neighbor table and prevent the 529 discovery of legitimate neighbors. 531 Once the pledge obtains link-layer keys and becomes a joined node, it 532 is able to securely communicate with its neighbors, obtain the 533 network IPv6 prefix and form its global IPv6 address. The joined 534 node then undergoes an independent process to bootstrap its neighbor 535 cache entries, possibly with a node that formerly acted as a JP, 536 following [RFC8505]. From the point of view of the JP, there is no 537 relationship between the neighbor cache entry belonging to a pledge 538 and the joined node that formerly acted as a pledge. 540 The pledge does not communicate with the JRC at the network layer. 541 This allows the pledge to join without knowing the IPv6 address of 542 the JRC. Instead, the pledge communicates with the JP at the network 543 layer using link-local addressing, and with the JRC at the 544 application layer, as specified in Section 7. 546 The JP communicates with the JRC over global IPv6 addresses. The JP 547 discovers the network IPv6 prefix and configures its global IPv6 548 address upon successful completion of the join process and the 549 obtention of link-layer keys. The pledge learns the IPv6 address of 550 the JRC from the Join Response, as specified in Section 8.1.2; it 551 uses it once joined in order to operate as a JP. 553 As a special case, the 6LBR pledge is expected to have an additional 554 network interface that it uses in order to obtain the configuration 555 parameters from the JRC and start advertising the 6TiSCH network. 556 This additional interface needs to be configured with a global IPv6 557 address, by a mechanism that is out of scope of this document. The 558 6LBR pledge uses this interface to directly communicate with the JRC 559 using global IPv6 addressing. 561 The JRC can be co-located on the 6LBR. In this special case, the 562 IPv6 address of the JRC can be omitted from the Join Response message 563 for space optimization. The 6LBR then MUST set the DODAGID field in 564 the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the 565 address of the JRC once joined and upon the reception of the first 566 RPL DIO message, and uses it to operate as a JP. 568 6.1. Identification of Unauthenticated Traffic 570 The traffic that is proxied by the Join Proxy (JP) comes from 571 unauthenticated pledges, and there may be an arbitrary amount of it. 572 In particular, an attacker may send fraudulent traffic in an attempt 573 to overwhelm the network. 575 When operating as part of a [RFC8180] 6TiSCH minimal network using 576 distributed scheduling algorithms, the traffic from unauthenticated 577 pledges may cause intermediate nodes to request additional bandwidth. 578 An attacker could use this property to cause the network to 579 overcommit bandwidth (and energy) to the join process. 581 The Join Proxy is aware of what traffic originates from 582 unauthenticated pledges, and so can avoid allocating additional 583 bandwidth itself. The Join Proxy implements a data cap on outgoing 584 join traffic through CoAP's congestion control mechanism. This cap 585 will not protect intermediate nodes as they can not tell join traffic 586 from regular traffic. Despite the data cap implemented separately on 587 each Join Proxy, the aggregate join traffic from many Join Proxies 588 may cause intermediate nodes to decide to allocate additional cells. 589 It is undesirable to do so in response to the traffic originated at 590 unauthenticated pledges. In order to permit the intermediate nodes 591 to avoid this, the traffic needs to be tagged. [RFC2597] defines a 592 set of per-hop behaviors that may be encoded into the Diffserv Code 593 Points (DSCPs). Based on the DSCP, intermediate nodes can decide 594 whether to act on a given packet. 596 6.1.1. Traffic from JP to JRC 598 The Join Proxy SHOULD set the DSCP of packets that it produces as 599 part of the forwarding process to AF43 code point (See Section 6 of 600 [RFC2597]). A Join Proxy that does not set the DSCP on traffic 601 forwarded should set it to zero so that it is compressed out. 603 A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT 604 allocate additional cells as a result of traffic with code point 605 AF43. Companion SF documents SHOULD specify how this recommended 606 behavior is achieved. 608 6.1.2. Traffic from JRC to JP 610 The JRC SHOULD set the DSCP of join response packets addressed to the 611 Join Proxy to AF42 code point. AF42 has lower drop probability than 612 AF43, giving this traffic priority in buffers over the traffic going 613 towards the JRC. 615 Due to the convergecast nature of the DODAG, the 6LBR links are often 616 the most congested, and from that point down there is progressively 617 less (or equal) congestion. If the 6LBR paces itself when sending 618 join response traffic then it ought to never exceed the bandwidth 619 allocated to the best effort traffic cells. If the 6LBR has the 620 capacity (if it is not constrained) then it should provide some 621 buffers in order to satisfy the Assured Forwarding behavior. 623 Companion SF documents SHOULD specify how traffic with code point 624 AF42 is handled with respect to cell allocation. In case the 625 recommended behavior described in this section is not followed, the 626 network may become prone to the attack discussed in Section 6.1. 628 7. Application-level Configuration 630 The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and 631 the secure channel provided by OSCORE [RFC8613]. The (6LBR) pledge 632 acts as a CoAP client; the JRC acts as a CoAP server. The JP 633 implements CoAP forward proxy functionality [RFC7252]. Because the 634 JP can also be a constrained device, it cannot implement a cache. 636 The pledge designates a JP as a proxy by including the Proxy-Scheme 637 option in CoAP requests it sends to the JP. The pledge also includes 638 in the requests the Uri-Host option with its value set to the well- 639 known JRC's alias, as specified in Section 8.1.1. 641 The JP resolves the alias to the IPv6 address of the JRC that it 642 learned when it acted as a pledge, and joined the network. This 643 allows the JP to reach the JRC at the network layer and forward the 644 requests on behalf of the pledge. 646 7.1. Statelessness of the JP 648 The CoAP proxy defined in [RFC7252] keeps per-client state 649 information in order to forward the response towards the originator 650 of the request. This state information includes at least the CoAP 651 token, the IPv6 address of the client, and the UDP source port 652 number. Since the JP can be a constrained device that acts as a CoAP 653 proxy, memory limitations make it prone to a Denial-of-Service (DoS) 654 attack. 656 This DoS vector on the JP can be mitigated by making the JP act as a 657 stateless CoAP proxy, where "state" encompasses the information 658 related individual pledges. The JP can wrap the state it needs to 659 keep for a given pledge throughout the network stack in a "state 660 object" and include it as a CoAP token in the forwarded request to 661 the JRC. The JP may use the CoAP token as defined in [RFC7252], if 662 the size of the serialized state object permits, or use the extended 663 CoAP token defined in [I-D.ietf-core-stateless], to transport the 664 state object. The JRC MUST support extended token lengths, as 665 defined in [I-D.ietf-core-stateless]. Since the CoAP token is echoed 666 back in the response, the JP is able to decode the state object and 667 configure the state needed to forward the response to the pledge. 668 The information that the JP needs to encode in the state object to 669 operate in a fully stateless manner with respect to a given pledge is 670 implementation specific. 672 It is RECOMMENDED that the JP operates in a stateless manner and 673 signals the per-pledge state within the CoAP token, for every request 674 it forwards into the network on behalf of unauthenticated pledges. 675 When the JP is operating in a stateless manner, the security 676 considerations from [I-D.ietf-core-stateless] apply and the type of 677 the CoAP message that the JP forwards on behalf of the pledge MUST be 678 non-confirmable (NON), regardless of the message type received from 679 the pledge. The use of a non-confirmable message by the JP 680 alleviates the JP from keeping CoAP message exchange state. The 681 retransmission burden is then entirely shifted to the pledge. A JP 682 that operates in a stateless manner still needs to keep congestion 683 control state with the JRC, see Section 9. Recommended values of 684 CoAP settings for use during the join process, both by the pledge and 685 the JP, are given in Section 7.2. 687 Note that in some networking stack implementations, a fully (per- 688 pledge) stateless operation of the JP may be challenging from the 689 implementation's point of view. In those cases, the JP may operate 690 as a statefull proxy that stores the per-pledge state until the 691 response is received or timed out, but this comes at a price of a DoS 692 vector. 694 7.2. Recommended Settings 696 This section gives RECOMMENDED values of CoAP settings during the 697 join process. 699 +-------------------+-----------------------+-------------------+ 700 | Name | Default Value: Pledge | Default Value: JP | 701 +-------------------+-----------------------+-------------------+ 702 | ACK_TIMEOUT | 10 seconds | (10 seconds) | 703 | | | | 704 | ACK_RANDOM_FACTOR | 1.5 | (1.5) | 705 | | | | 706 | MAX_RETRANSMIT | 4 | (4) | 707 +-------------------+-----------------------+-------------------+ 709 Recommended CoAP settings. Values enclosed in () have no effect when 710 JP operates in a stateless manner. 712 These values may be configured to values specific to the deployment. 713 The default values have been chosen to accommodate a wide range of 714 deployments, taking into account dense networks. 716 The PROBING_RATE value at the JP is controlled by the join rate 717 parameter, see Section 8.4.2. Following [RFC7252], the average data 718 rate in sending to the JRC must not exceed PROBING_RATE. For 719 security reasons, the average data rate SHOULD be measured over a 720 rather short window, e.g. ACK_TIMEOUT, see Section 9. 722 7.3. OSCORE 724 Before the (6LBR) pledge and the JRC start exchanging CoAP messages 725 protected with OSCORE, they need to derive the OSCORE security 726 context from the provisioned parameters, as discussed in Section 3. 728 The OSCORE security context MUST be derived as per Section 3 of 729 [RFC8613]. 731 o the Master Secret MUST be the PSK. 733 o the Master Salt MUST be the empty byte string. 735 o the ID Context MUST be set to the pledge identifier. 737 o the ID of the pledge MUST be set to the empty byte string. This 738 identifier is used as the OSCORE Sender ID of the pledge in the 739 security context derivation, since the pledge initially acts as a 740 CoAP client. 742 o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" 743 in ASCII). This identifier is used as the OSCORE Recipient ID of 744 the pledge in the security context derivation, as the JRC 745 initially acts as a CoAP server. 747 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 748 of-band by the same mechanism used to provision the PSK. The 749 default is AES-CCM-16-64-128. 751 o the Key Derivation Function MUST be agreed out-of-band by the same 752 mechanism used to provision the PSK. Default is HKDF SHA-256 753 [RFC5869]. 755 Since the pledge's OSCORE Sender ID is the empty byte string, when 756 constructing the OSCORE option, the pledge sets the k bit in the 757 OSCORE flag byte, but indicates a 0-length kid. The pledge 758 transports its pledge identifier within the kid context field of the 759 OSCORE option. The derivation in [RFC8613] results in OSCORE keys 760 and a common IV for each side of the conversation. Nonces are 761 constructed by XOR'ing the common IV with the current sequence 762 number. For details on nonce and OSCORE option construction, refer 763 to [RFC8613]. 765 Implementations MUST ensure that multiple CoAP requests, including to 766 different JRCs, are properly incrementing the sequence numbers, so 767 that the same sequence number is never reused in distinct requests. 768 The pledge typically sends requests to different JRCs if it is not 769 provisioned with the network identifier and attempts to join one 770 network at a time. Failure to comply will break the security 771 guarantees of the Authenticated Encryption with Associated Data 772 (AEAD) algorithm because of nonce reuse. 774 This OSCORE security context is used for initial joining of the 775 (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well 776 as for any later parameter updates, where the JRC acts as a CoAP 777 client and the joined node as a CoAP server, as discussed in 778 Section 8.2. Note that when the (6LBR) pledge and the JRC change 779 roles between CoAP client and CoAP server, the same OSCORE security 780 context as initially derived remains in use and the derived 781 parameters are unchanged, for example Sender ID when sending and 782 Recipient ID when receiving (see Section 3.1 of [RFC8613]). A (6LBR) 783 pledge is expected to have exactly one OSCORE security context with 784 the JRC. 786 7.3.1. Replay Window and Persistency 788 Both (6LBR) pledge and the JRC MUST implement a replay protection 789 mechanism. The use of the default OSCORE replay protection mechanism 790 specified in Section 3.2.2 of [RFC8613] is RECOMMENDED. 792 Implementations MUST ensure that mutable OSCORE context parameters 793 (Sender Sequence Number, Replay Window) are stored in persistent 794 memory. A technique that prevents reuse of sequence numbers, 795 detailed in Appendix B.1.1 of [RFC8613], MUST be implemented. Each 796 update of the OSCORE Replay Window MUST be written to persistent 797 memory. 799 This is an important security requirement in order to guarantee nonce 800 uniqueness and resistance to replay attacks across reboots and 801 rejoins. Traffic between the (6LBR) pledge and the JRC is rare, 802 making security outweigh the cost of writing to persistent memory. 804 7.3.2. OSCORE Error Handling 806 Errors raised by OSCORE during the join process MUST be silently 807 dropped, with no error response being signaled. The pledge MUST 808 silently discard any response not protected with OSCORE, including 809 error codes. 811 Such errors may happen for a number of reasons, including failed 812 lookup of an appropriate security context (e.g. the pledge attempting 813 to join a wrong network), failed decryption, positive replay window 814 lookup, formatting errors (possibly due to malicious alterations in 815 transit). Silently dropping OSCORE messages prevents a DoS attack on 816 the pledge where the attacker could send bogus error responses, 817 forcing the pledge to attempt joining one network at a time, until 818 all networks have been tried. 820 7.3.3. Mandatory to Implement Algorithms 822 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 823 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 824 securing IEEE Std 802.15.4 frames, and hardware acceleration for it 825 is present in virtually all compliant radio chips. With this choice, 826 CoAP messages are protected with an 8-byte CCM authentication tag, 827 and the algorithm uses 13-byte long nonces. 829 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The 830 mandatory to implement key derivation function is HKDF [RFC5869], 831 instantiated with a SHA-256 hash. See Appendix B for implementation 832 guidance when code footprint is important. 834 8. Constrained Join Protocol (CoJP) 836 The Constrained Join Protocol (CoJP) is a lightweight protocol over 837 CoAP [RFC7252] and a secure channel provided by OSCORE [RFC8613]. 838 CoJP allows the (6LBR) pledge to request admission into a network 839 managed by the JRC, and for the JRC to configure the pledge with the 840 parameters necessary for joining the network, or advertising it in 841 the case of 6LBR pledge. The JRC may update the parameters at any 842 time, by reaching out to the joined node that formerly acted as a 843 (6LBR) pledge. For example, network-wide rekeying can be implemented 844 by updating the keying material on each node. 846 This section specifies how the CoJP messages are mapped to CoAP and 847 OSCORE, CBOR data structures carrying different parameters, 848 transported within CoAP payload, and the parameter semantics and 849 processing rules. 851 CoJP relies on the security properties provided by OSCORE. This 852 includes end-to-end confidentiality, data authenticity, replay 853 protection, and a secure binding of responses to requests. 855 +-----------------------------------+ 856 | Constrained Join Protocol (CoJP) | 857 +-----------------------------------+ 858 +-----------------------------------+ \ 859 | Requests / Responses | | 860 |-----------------------------------| | 861 | OSCORE | | CoAP 862 |-----------------------------------| | 863 | Messaging Layer | | 864 +-----------------------------------+ / 865 +-----------------------------------+ 866 | UDP | 867 +-----------------------------------+ 869 Figure 2: Abstract layering of CoJP. 871 When a (6LBR) pledge requests admission to a given network, it 872 undergoes the CoJP join exchange that consists of: 874 o the Join Request message, sent by the (6LBR) pledge to the JRC, 875 potentially proxied by the JP. The Join Request message and its 876 mapping to CoAP is specified in Section 8.1.1. 878 o the Join Response message, sent by the JRC to the (6LBR) pledge, 879 if the JRC successfully processes the Join Request using OSCORE 880 and it determines through a mechanism that is out of scope of this 881 specification that the (6LBR) pledge is authorized to join the 882 network. The Join Response message is potentially proxied by the 883 JP. The Join Response message and its mapping to CoAP is 884 specified in Section 8.1.2. 886 When the JRC needs to update the parameters of a joined node that 887 formerly acted as a (6LBR) pledge, it executes the CoJP parameter 888 update exchange that consists of: 890 o the Parameter Update message, sent by the JRC to the joined node 891 that formerly acted as a (6LBR) pledge. The Parameter Update 892 message and its mapping to CoAP is specified in Section 8.2.1. 894 o the Parameter Update Response message, sent by the joined node to 895 the JRC in response to the Parameter Update message to signal 896 successful reception of the updated parameters. The Parameter 897 Update Response message and its mapping to CoAP is specified in 898 Section 8.2.2. 900 The payload of CoJP messages is encoded with CBOR [RFC7049]. The 901 CBOR data structures that may appear as the payload of different CoJP 902 messages are specified in Section 8.4. 904 8.1. Join Exchange 906 This section specifies the messages exchanged when the (6LBR) pledge 907 requests admission and configuration parameters from the JRC. 909 8.1.1. Join Request Message 911 The Join Request message that the (6LBR) pledge sends SHALL be mapped 912 to a CoAP request: 914 o The request method is POST. 916 o The type is Confirmable (CON). 918 o The Proxy-Scheme option is set to "coap". 920 o The Uri-Host option is set to "6tisch.arpa". This is an anycast 921 type of identifier of the JRC that is resolved to its IPv6 address 922 by the JP or the 6LBR pledge. 924 o The Uri-Path option is set to "j". 926 o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE 927 security context used is the one derived in Section 7.3. The 928 OSCORE kid context allows the JRC to retrieve the security context 929 for a given pledge. 931 o The payload is a Join_Request CBOR object, as defined in 932 Section 8.4.1. 934 Since the Join Request is a confirmable message, the transmission at 935 (6LBR) pledge will be controlled by CoAP's retransmission mechanism. 936 The JP, when operating in a stateless manner, forwards this Join 937 Request as a non-confirmable (NON) CoAP message, as specified in 938 Section 7. If the CoAP at (6LBR) pledge declares the message 939 transmission as failure, the (6LBR) pledge SHOULD attempt to join the 940 next advertised 6TiSCH network. See Section 7.2 for recommended 941 values of CoAP settings to use during the join exchange. 943 If all join attempts to advertised networks have failed, the (6LBR) 944 pledge SHOULD signal the presence of an error condition, through some 945 out-of-band mechanism. 947 8.1.2. Join Response Message 949 The Join Response message that the JRC sends SHALL be mapped to a 950 CoAP response: 952 o The response Code is 2.04 (Changed). 954 o The payload is a Configuration CBOR object, as defined in 955 Section 8.4.2. 957 8.2. Parameter Update Exchange 959 During the network lifetime, parameters returned as part of the Join 960 Response may need to be updated. One typical example is the update 961 of link-layer keying material for the network, a process known as 962 rekeying. This section specifies a generic mechanism when this 963 parameter update is initiated by the JRC. 965 At the time of the join, the (6LBR) pledge acts as a CoAP client and 966 requests the network parameters through a representation of the "/j" 967 resource, exposed by the JRC. In order for the update of these 968 parameters to happen, the JRC needs to asynchronously contact the 969 joined node. The use of the CoAP Observe option for this purpose is 970 not feasible due to the change in the IPv6 address when the pledge 971 becomes the joined node and obtains a global address. 973 Instead, once the (6LBR) pledge receives and successfully validates 974 the Join Response and so becomes a joined node, it becomes a CoAP 975 server. The joined node exposes the "/j" resource that is used by 976 the JRC to update the parameters. Consequently, the JRC operates as 977 a CoAP client when updating the parameters. The request/response 978 exchange between the JRC and the (6LBR) pledge happens over the 979 already-established OSCORE secure channel. 981 8.2.1. Parameter Update Message 983 The Parameter Update message that the JRC sends to the joined node 984 SHALL be mapped to a CoAP request: 986 o The request method is POST. 988 o The type is Confirmable (CON). 990 o The Uri-Path option is set to "j". 992 o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE 993 security context used is the one derived in Section 7.3. When a 994 joined node receives a request with the Sender ID set to 0x4a5243 995 (ID of the JRC), it is able to correctly retrieve the security 996 context with the JRC. 998 o The payload is a Configuration CBOR object, as defined in 999 Section 8.4.2. 1001 The JRC has implicit knowledge on the global IPv6 address of the 1002 joined node, as it knows the pledge identifier that the joined node 1003 used when it acted as a pledge, and the IPv6 network prefix. The JRC 1004 uses this implicitly derived IPv6 address of the joined node to 1005 directly address CoAP messages to it. 1007 In case the JRC does not receive a response to a Parameter Update 1008 message, it attempts multiple retransmissions, as configured by the 1009 underlying CoAP retransmission mechanism triggered for confirmable 1010 messages. Finally, if the CoAP implementation declares the 1011 transmission as failure, the JRC may consider this as a hint that the 1012 joined node is no longer in the network. How the JRC decides when to 1013 stop attempting to contact a previously joined node is out of scope 1014 of this specification but security considerations on the reuse of 1015 assigned resources apply, as discussed in Section 9. 1017 8.2.2. Parameter Update Response Message 1019 The Parameter Update Response message that the joined node sends to 1020 the JRC SHALL be mapped to a CoAP response: 1022 o The response Code is 2.04 (Changed). 1024 o The payload is empty. 1026 8.3. Error Handling 1028 8.3.1. CoJP CBOR Object Processing 1030 CoJP CBOR objects are transported within both CoAP requests and 1031 responses. This section describes handling in case certain CoJP CBOR 1032 object parameters are not supported by the implementation or their 1033 processing fails. See Section 7.3.2 for the handling of errors that 1034 may be raised by the underlying OSCORE implementation. 1036 When such a parameter is detected in a CoAP request (Join Request 1037 message, Parameter Update message), a Diagnostic Response message 1038 MUST be returned. A Diagnostic Response message maps to a CoAP 1039 response and is specified in Section 8.3.2. 1041 When a parameter that cannot be acted upon is encountered while 1042 processing a CoJP object in a CoAP response (Join Response message), 1043 a (6LBR) pledge SHOULD reattempt to join. In this case, the (6LBR) 1044 pledge SHOULD include the Unsupported Configuration CBOR object 1045 within the Join Request object in the following Join Request message. 1046 The Unsupported Configuration CBOR object is self-contained and 1047 enables the (6LBR) pledge to signal any parameters that the 1048 implementation of the networking stack may not support. A (6LBR) 1049 pledge MUST NOT attempt more than MAX_RETRANSMIT number of attempts 1050 to join if the processing of the Join Response message fails each 1051 time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached 1052 without success, the (6LBR) pledge SHOULD signal the presence of an 1053 error condition, through some out-of-band mechanism. 1055 8.3.2. Diagnostic Response Message 1057 The Diagnostic Response message is returned for any CoJP request when 1058 the processing of the payload failed. The Diagnostic Response 1059 message is protected by OSCORE as any other CoJP protocol message. 1061 The Diagnostic Response message SHALL be mapped to a CoAP response: 1063 o The response Code is 4.00 (Bad Request). 1065 o The payload is an Unsupported Configuration CBOR object, as 1066 defined in Section 8.4.5, containing more information about the 1067 parameter that triggered the sending of this message. 1069 8.3.3. Failure Handling 1071 The Parameter Update exchange may be triggered at any time during the 1072 network lifetime, which may span several years. During this period, 1073 it may occur that a joined node or the JRC experience unexpected 1074 events such as reboots or complete failures. 1076 This document mandates that the mutable parameters in the security 1077 context are written to persistent memory (see Section 7.3.1) by both 1078 the JRC and pledges (joined nodes). As the joined node (pledge) is 1079 typically a constrained device that handles the write operations to 1080 persistent memory in a predictable manner, the retrieval of mutable 1081 security context parameters is feasible across reboots such that 1082 there is no risk of AEAD nonce reuse due to reinitialized Sender 1083 Sequence numbers, or of a replay attack due to the reinitialized 1084 replay window. JRC may be hosted on a generic machine where the 1085 write operation to persistent memory may lead to unpredictable delays 1086 due to caching. In case of a reboot event at JRC occurring before 1087 the cached data is written to persistent memory, the loss of mutable 1088 security context parameters is likely which consequently poses the 1089 risk of AEAD nonce reuse. 1091 In the event of a complete device failure, where the mutable security 1092 context parameters cannot be retrieved, it is expected that a failed 1093 joined node is replaced with a new physical device, using a new 1094 pledge identifier and a PSK. When such a failure event occurs at the 1095 JRC, it is possible that the static information on provisioned 1096 pledges, like PSKs and pledge identifiers, can be retrieved through 1097 available backups. However, it is likely that the information about 1098 joined nodes, their assigned short identifiers and mutable security 1099 context parameters is lost. If this is the case, during the process 1100 of JRC reinitialization, the network administrator MUST force through 1101 out-of-band means all the networks managed by the failed JRC to 1102 rejoin, through e.g. the reinitialization of the 6LBR nodes and 1103 freshly generated dynamic cryptographic keys and other parameters 1104 that have influence on the security properties of the network. 1106 In order to recover from such a failure event, the reinitialized JRC 1107 can trigger the renegotiation of the OSCORE security context through 1108 the procedure described in Appendix B.2 of [RFC8613]. Aware of the 1109 failure event, the reinitialized JRC responds to the first join 1110 request of each pledge it is managing with a 4.01 Unauthorized error 1111 and a random nonce. The pledge verifies the error response and then 1112 initiates the CoJP join exchange using a new OSCORE security context 1113 derived from an ID Context consisting of the concatenation of two 1114 nonces, one that it received from the JRC and the other that the 1115 pledge generates locally. After verifying the join request with the 1116 new ID Context and the derived OSCORE security context, the JRC 1117 should consequently take action in mapping the new ID Context with 1118 the previously used pledge identifier. How JRC handles this mapping 1119 is implementation specific. 1121 The described procedure is specified in Appendix B.2 of [RFC8613] and 1122 is RECOMMENDED in order to handle the failure events or any other 1123 event that may lead to the loss of mutable security context 1124 parameters. The length of nonces exchanged using this procedure 1125 SHOULD be at least 8 bytes. 1127 The procedure does require both the pledge and the JRC to have good 1128 sources of randomness. While this is typically not an issue at the 1129 JRC side, the constrained device hosting the pledge may pose 1130 limitations in this regard. If the procedure outlined in 1131 Appendix B.2 of [RFC8613] is not supported by the pledge, the network 1132 administrator MUST take action in reprovisioning the concerned 1133 devices with freshly generated parameters, through out-of-band means. 1135 8.4. CoJP Objects 1137 This section specifies the structure of CoJP CBOR objects that may be 1138 carried as the payload of CoJP messages. Some of these objects may 1139 be received both as part of the CoJP join exchange when the device 1140 operates as a (CoJP) pledge, or the parameter update exchange, when 1141 the device operates as a joined (6LBR) node. 1143 8.4.1. Join Request Object 1145 The Join_Request structure is built on a CBOR map object. 1147 The set of parameters that can appear in a Join_Request object is 1148 summarized below. The labels can be found in the "CoJP Parameters" 1149 registry Section 11.1. 1151 o role: The identifier of the role that the pledge requests to play 1152 in the network once it joins, encoded as an unsigned integer. 1153 Possible values are specified in Table 1. This parameter MAY be 1154 included. In case the parameter is omitted, the default value of 1155 0, i.e. the role "6TiSCH Node", MUST be assumed. 1157 o network identifier: The identifier of the network, as discussed in 1158 Section 3, encoded as a CBOR byte string. When present in the 1159 Join_Request, it hints to the JRC the network that the pledge is 1160 requesting to join, enabling the JRC to manage multiple networks. 1161 The pledge obtains the value of the network identifier from the 1162 received EB frames. This parameter MUST be included in a 1163 Join_Request object regardless of the role parameter value. 1165 o unsupported configuration: The identifier of the parameters that 1166 are not supported by the implementation, encoded as an 1167 Unsupported_Configuration object described in Section 8.4.5. This 1168 parameter MAY be included. If a (6LBR) pledge previously 1169 attempted to join and received a valid Join Response message over 1170 OSCORE, but failed to act on its payload (Configuration object), 1171 it SHOULD include this parameter to facilitate the recovery and 1172 debugging. 1174 The CDDL fragment that represents the text above for the Join_Request 1175 follows. 1177 Join_Request = { 1178 ? 1 : uint, ; role 1179 ? 5 : bstr, ; network identifier 1180 ? 8 : Unsupported_Configuration ; unsupported configuration 1181 } 1182 +--------+-------+-------------------------------------+------------+ 1183 | Name | Value | Description | Reference | 1184 +--------+-------+-------------------------------------+------------+ 1185 | 6TiSCH | 0 | The pledge requests to play the | [[this | 1186 | Node | | role of a regular 6TiSCH node, i.e. | document]] | 1187 | | | non-6LBR node. | | 1188 | | | | | 1189 | 6LBR | 1 | The pledge requests to play the | [[this | 1190 | | | role of 6LoWPAN Border Router | document]] | 1191 | | | (6LBR). | | 1192 +--------+-------+-------------------------------------+------------+ 1194 Table 1: Role values. 1196 8.4.2. Configuration Object 1198 The Configuration structure is built on a CBOR map object. The set 1199 of parameters that can appear in a Configuration object is summarized 1200 below. The labels can be found in "CoJP Parameters" registry 1201 Section 11.1. 1203 o link-layer key set: An array encompassing a set of cryptographic 1204 keys and their identifiers that are currently in use in the 1205 network, or that are scheduled to be used in the future. The 1206 encoding of individual keys is described in Section 8.4.3. The 1207 link-layer key set parameter MAY be included in a Configuration 1208 object. When present, the link-layer key set parameter MUST 1209 contain at least one key. When a pledge is joining for the first 1210 time and receives this parameter, before sending the first 1211 outgoing frame secured with a received key, the pledge needs to 1212 successfully complete the security processing of an incoming 1213 frame. To do so, the pledge can wait to receive a new frame, or 1214 it can store an EB frame that it used to find the JP and use it 1215 for immediate security processing upon reception of the key set. 1216 This parameter is also used to implement rekeying in the network. 1217 How the keys are installed and used differs for the 6LBR and other 1218 (regular) nodes, and this is explained in Section 8.4.3.1 and 1219 Section 8.4.3.2. 1221 o short identifier: a compact identifier assigned to the pledge. 1222 The short identifier structure is described in Section 8.4.4. The 1223 short identifier parameter MAY be included in a Configuration 1224 object. 1226 o JRC address: the IPv6 address of the JRC, encoded as a byte 1227 string, with the length of 16 bytes. If the length of the byte 1228 string is different from 16, the parameter MUST be discarded. If 1229 the JRC is not co-located with the 6LBR and has a different IPv6 1230 address than the 6LBR, this parameter MUST be included. In the 1231 special case where the JRC is co-located with the 6LBR and has the 1232 same IPv6 address as the 6LBR, this parameter MAY be included. If 1233 the JRC address parameter is not present in the Configuration 1234 object, this indicates that the JRC has the same IPv6 address as 1235 the 6LBR. The joined node can then discover the IPv6 address of 1236 the JRC through network control traffic. See Section 6. 1238 o blacklist: An array encompassing a list of pledge identifiers that 1239 are blacklisted by the JRC, with each pledge identifier encoded as 1240 a byte string. The blacklist parameter MAY be included in a 1241 Configuration object. When present, the array MUST contain zero 1242 or more byte strings encoding pledge identifiers. The joined node 1243 MUST silently drop any link-layer frames originating from the 1244 pledge identifiers enclosed in the blacklist parameter. When this 1245 parameter is received, its value MUST overwrite any previously set 1246 values. This parameter allows the JRC to configure the node 1247 acting as a JP to filter out traffic from misconfigured or 1248 malicious pledges before their traffic is forwarded into the 1249 network. If the JRC decides to remove a given pledge identifier 1250 from a blacklist, it omits the pledge identifier in the blacklist 1251 parameter value it sends next. 1253 o join rate: Average data rate of join traffic forwarded into the 1254 network that should not be exceeded when a joined node operates as 1255 a JP, encoded as an unsigned integer in bytes per second. The 1256 join rate parameter MAY be included in a Configuration object. 1257 This parameter allows the JRC to configure different nodes in the 1258 network to operate as JP, and act in case of an attack by 1259 throttling the rate at which JP forwards unauthenticated traffic 1260 into the network. When this parameter is present in a 1261 Configuration object, the value MUST be used to set the 1262 PROBING_RATE of CoAP at the joined node for communication with the 1263 JRC. In case this parameter is set to zero, a joined node MUST 1264 silently drop any join traffic coming from unauthenticated 1265 pledges. In case this parameter is omitted, the value of positive 1266 infinity SHOULD be assumed. Node operating as a JP MAY use 1267 another mechanism that is out of scope of this specification to 1268 configure PROBING_RATE of CoAP in the absence of join rate 1269 parameter from the Configuration object. 1271 The CDDL fragment that represents the text above for the 1272 Configuration follows. Structures Link_Layer_Key and 1273 Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. 1275 Configuration = { 1276 ? 2 : [ +Link_Layer_Key ], ; link-layer key set 1277 ? 3 : Short_Identifier, ; short identifier 1278 ? 4 : bstr, ; JRC address 1279 ? 6 : [ *bstr ], ; blacklist 1280 ? 7 : uint ; join rate 1281 } 1282 +---------------+-------+----------+-------------------+------------+ 1283 | Name | Label | CBOR | Description | Reference | 1284 | | | type | | | 1285 +---------------+-------+----------+-------------------+------------+ 1286 | role | 1 | unsigned | Identifies the | [[this | 1287 | | | integer | role parameter | document]] | 1288 | | | | | | 1289 | link-layer | 2 | array | Identifies the | [[this | 1290 | key set | | | array carrying | document]] | 1291 | | | | one or more link- | | 1292 | | | | level | | 1293 | | | | cryptographic | | 1294 | | | | keys | | 1295 | | | | | | 1296 | short | 3 | array | Identifies the | [[this | 1297 | identifier | | | assigned short | document]] | 1298 | | | | identifier | | 1299 | | | | | | 1300 | JRC address | 4 | byte | Identifies the | [[this | 1301 | | | string | IPv6 address of | document]] | 1302 | | | | the JRC | | 1303 | | | | | | 1304 | network | 5 | byte | Identifies the | [[this | 1305 | identifier | | string | network | document]] | 1306 | | | | identifier | | 1307 | | | | parameter | | 1308 | | | | | | 1309 | blacklist | 6 | array | Identifies the | [[this | 1310 | | | | blacklist | document]] | 1311 | | | | parameter | | 1312 | | | | | | 1313 | join rate | 7 | unsigned | Identifier the | [[this | 1314 | | | integer | join rate | document]] | 1315 | | | | parameter | | 1316 | | | | | | 1317 | unsupported | 8 | array | Identifies the | [[this | 1318 | configuration | | | unsupported | document]] | 1319 | | | | configuration | | 1320 | | | | parameter | | 1321 +---------------+-------+----------+-------------------+------------+ 1323 Table 2: CoJP parameters map labels. 1325 8.4.3. Link-Layer Key 1327 The Link_Layer_Key structure encompasses the parameters needed to 1328 configure the link-layer security module: the key identifier; the 1329 value of the cryptographic key; the link-layer algorithm identifier 1330 and the security level and the frame types that it should be used 1331 with, both for outgoing and incoming security operations; and any 1332 additional information that may be needed to configure the key. 1334 For encoding compactness, the Link_Layer_Key object is not enclosed 1335 in a top-level CBOR object. Rather, it is transported as a sequence 1336 of CBOR elements, some being optional. 1338 The set of parameters that can appear in a Link_Layer_Key object is 1339 summarized below, in order: 1341 o key_id: The identifier of the key, encoded as a CBOR unsigned 1342 integer. This parameter MUST be included. If the decoded CBOR 1343 unsigned integer value is larger than the maximum link-layer key 1344 identifier, the key is considered invalid. In case the key is 1345 considered invalid, the key MUST be discarded and the 1346 implementation MUST signal the error as specified in 1347 Section 8.3.1. 1349 o key_usage: The identifier of the link-layer algorithm, security 1350 level and link-layer frame types that can be used with the key, 1351 encoded as an integer. This parameter MAY be included. Possible 1352 values and the corresponding link-layer settings are specified in 1353 IANA "CoJP Key Usage" registry (Section 11.2). In case the 1354 parameter is omitted, the default value of 0 from Table 3 MUST be 1355 assumed. 1357 o key_value: The value of the cryptographic key, encoded as a byte 1358 string. This parameter MUST be included. If the length of the 1359 byte string is different than the corresponding key length for a 1360 given algorithm specified by the key_usage parameter, the key MUST 1361 be discarded and the implementation MUST signal the error as 1362 specified in Section 8.3.1. 1364 o key_addinfo: Additional information needed to configure the link- 1365 layer key, encoded as a byte string. This parameter MAY be 1366 included. The processing of this parameter is dependent on the 1367 link-layer technology in use and a particular keying mode. 1369 To be able to decode the keys that are present in the link-layer key 1370 set, and to identify individual parameters of a single Link_Layer_Key 1371 object, the CBOR decoder needs to differentiate between elements 1372 based on the CBOR type. For example, a uint that follows a byte 1373 string signals to the decoder that a new Link_Layer_Key object is 1374 being processed. 1376 The CDDL fragment that represents the text above for the 1377 Link_Layer_Key follows. 1379 Link_Layer_Key = ( 1380 key_id : uint, 1381 ? key_usage : int, 1382 key_value : bstr, 1383 ? key_addinfo : bstr, 1384 ) 1386 +-----------------+-----+------------------+-------------+----------+ 1387 | Name | Val | Algorithm | Description | Referenc | 1388 | | ue | | | e | 1389 +-----------------+-----+------------------+-------------+----------+ 1390 | 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | 1391 | -ENC-MIC32 | | CCM-128 | for EBs, | ocument] | 1392 | | | | ENC-MIC-32 | ] | 1393 | | | | for DATA | | 1394 | | | | and ACKNOWL | | 1395 | | | | EDGMENT. | | 1396 | | | | | | 1397 | 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | 1398 | -ENC-MIC64 | | CCM-128 | for EBs, | ocument] | 1399 | | | | ENC-MIC-64 | ] | 1400 | | | | for DATA | | 1401 | | | | and ACKNOWL | | 1402 | | | | EDGMENT. | | 1403 | | | | | | 1404 | 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | 1405 | -ENC-MIC128 | | CCM-128 | for EBs, | ocument] | 1406 | | | | ENC-MIC-128 | ] | 1407 | | | | for DATA | | 1408 | | | | and ACKNOWL | | 1409 | | | | EDGMENT. | | 1410 | | | | | | 1411 | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | 1412 | K1K2-MIC32 | | CCM-128 | for EBs, | ocument] | 1413 | | | | DATA and AC | ] | 1414 | | | | KNOWLEDGMEN | | 1415 | | | | T. | | 1416 | | | | | | 1417 | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | 1418 | K1K2-MIC64 | | CCM-128 | for EBs, | ocument] | 1419 | | | | DATA and AC | ] | 1420 | | | | KNOWLEDGMEN | | 1421 | | | | T. | | 1422 | | | | | | 1423 | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | 1424 | K1K2-MIC128 | | CCM-128 | for EBs, | ocument] | 1425 | | | | DATA and AC | ] | 1426 | | | | KNOWLEDGMEN | | 1427 | | | | T. | | 1428 | | | | | | 1429 | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | 1430 | | | CCM-128 | for EBs. | ocument] | 1431 | | | | | ] | 1432 | | | | | | 1433 | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | 1434 | | | CCM-128 | for EBs. | ocument] | 1435 | | | | | ] | 1436 | | | | | | 1437 | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | 1438 | 8 | | CCM-128 | for EBs. | ocument] | 1439 | | | | | ] | 1440 | | | | | | 1441 | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | 1442 | | | CCM-128 | for DATA | ocument] | 1443 | | | | and ACKNOWL | ] | 1444 | | | | EDGMENT. | | 1445 | | | | | | 1446 | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | 1447 | | | CCM-128 | for DATA | ocument] | 1448 | | | | and ACKNOWL | ] | 1449 | | | | EDGMENT. | | 1450 | | | | | | 1451 | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | 1452 | 8 | | CCM-128 | for DATA | ocument] | 1453 | | | | and ACKNOWL | ] | 1454 | | | | EDGMENT. | | 1455 | | | | | | 1456 | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | 1457 | MIC32 | | CCM-128 | MIC-32 for | ocument] | 1458 | | | | DATA and AC | ] | 1459 | | | | KNOWLEDGMEN | | 1460 | | | | T. | | 1461 | | | | | | 1462 | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | 1463 | MIC64 | | CCM-128 | MIC-64 for | ocument] | 1464 | | | | DATA and AC | ] | 1465 | | | | KNOWLEDGMEN | | 1466 | | | | T. | | 1467 | | | | | | 1468 | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | 1469 | MIC128 | | CCM-128 | MIC-128 for | ocument] | 1470 | | | | DATA and AC | ] | 1471 | | | | KNOWLEDGMEN | | 1472 | | | | T. | | 1473 +-----------------+-----+------------------+-------------+----------+ 1474 Table 3: Key Usage values. 1476 8.4.3.1. Rekeying of (6LoWPAN) Border Routers (6LBR) 1478 When the 6LoWPAN Border Router (6LBR) receives the Configuration 1479 object containing a link-layer key set, it MUST immediately install 1480 and start using the new keys for all outgoing traffic, and remove any 1481 old keys it has installed from the previous key set after a delay of 1482 COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the 1483 JRC to force the 6LBR to start sending traffic with the new key. The 1484 decision is taken by the JRC when it has determined that the new key 1485 has been made available to all (or some overwhelming majority) of 1486 nodes. Any node that the JRC has not yet reached at that point is 1487 either non-functional or in extended sleep such that it will not be 1488 reached. To get the key update, such node needs to go through the 1489 join process anew. 1491 8.4.3.2. Rekeying of regular (6LoWPAN) Nodes (6LN) 1493 When a regular 6LN node receives the Configuration object with a 1494 link-layer key set, it MUST install the new keys. The 6LN will use 1495 both the old and the new keys to decrypt and authenticate any 1496 incoming traffic that arrives based upon the key identifier in the 1497 packet. It MUST continue to use the old keys for all outgoing 1498 traffic until it has detected that the network has switched to the 1499 new key set. 1501 The detection of network switch is based upon the receipt of traffic 1502 secured with the new keys. Upon reception and successful security 1503 processing of a link-layer frame secured with a key from the new key 1504 set, a 6LN node MUST then switch to sending outgoing traffic using 1505 the keys from the new set for all outgoing traffic. The 6LN node 1506 MUST remove any old keys it has installed from the previous key set 1507 after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts 1508 using the new key set. 1510 Sending of traffic with the new keys signals to other downstream 1511 nodes to switch to their new key, and the affect is that there is a 1512 ripple of key updates in outward concentric circles around each 6LBR. 1514 8.4.3.3. Use in IEEE Std 802.15.4 1516 When Link_Layer_Key is used in the context of [IEEE802.15.4], the 1517 following considerations apply. 1519 Signaling of different keying modes of [IEEE802.15.4] is done based 1520 on the parameter values present in a Link_Layer_Key object. 1522 o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be 1523 set to 0. key_addinfo parameter MUST be present. key_addinfo 1524 parameter MUST be set to the link-layer address(es) of a single 1525 peer with whom the key should be used. Depending on the 1526 configuration of the network, key_addinfo may carry the peer's 1527 long link-layer address (i.e. pledge identifier), short link-layer 1528 address, or their concatenation with the long address being 1529 encoded first. Which address is carried is determined from the 1530 length of the byte string. 1532 o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a 1533 value different than 0. key_addinfo parameter MUST NOT be 1534 present. 1536 o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter 1537 MUST be set to a value different than 0. key_addinfo parameter 1538 MUST be present. key_addinfo parameter MUST be set to a byte 1539 string, exactly 4 bytes long. key_addinfo parameter carries the 1540 Key Source parameter used to configure [IEEE802.15.4]. 1542 o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter 1543 MUST be set to a value different than 0. key_addinfo parameter 1544 MUST be present. key_addinfo parameter MUST be set to a byte 1545 string, exactly 8 bytes long. key_addinfo parameter carries the 1546 Key Source parameter used to configure [IEEE802.15.4]. 1548 In all cases, key_usage parameter determines how a particular key 1549 should be used in respect to incoming and outgoing security policies. 1551 For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" 1552 parameter of [IEEE802.15.4] that is signaled in all outgoing frames 1553 secured with a given key. The maximum value key_id can have is 254. 1554 The value of 255 is reserved in [IEEE802.15.4] and is therefore 1555 considered invalid. 1557 Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a 1558 trusted third party and assign pairwise keys between nodes in the 1559 network. How JRC learns about the network topology is out of scope 1560 of this specification, but could be done through 6LBR - JRC signaling 1561 for example. Pairwise keys could also be derived through a key 1562 agreement protocol executed between the peers directly, where the 1563 authentication is based on the symmetric cryptographic material 1564 provided to both peers by the JRC. Such a protocol is out of scope 1565 of this specification. 1567 Implementations MUST use different link-layer keys when using 1568 different authentication tag (MIC) lengths, as using the same key 1569 with different authentication tag lengths might be unsafe. For 1570 example, this prohibits the usage of the same key for both MIC-32 and 1571 MIC-64 levels. See Annex B.4.3 of [IEEE802.15.4] for more 1572 information. 1574 8.4.4. Short Identifier 1576 The Short_Identifier object represents an identifier assigned to the 1577 pledge. It is encoded as a CBOR array object, containing, in order: 1579 o identifier: The short identifier assigned to the pledge, encoded 1580 as a byte string. This parameter MUST be included. The 1581 identifier MUST be unique in the set of all identifiers assigned 1582 in a network that is managed by a JRC. In case the identifier is 1583 invalid, the decoder MUST silently ignore the Short_Identifier 1584 object. 1586 o lease_time: The validity of the identifier in hours after the 1587 reception of the CBOR object, encoded as a CBOR unsigned integer. 1588 This parameter MAY be included. The node MUST stop using the 1589 assigned short identifier after the expiry of the lease_time 1590 interval. It is up to the JRC to renew the lease before the 1591 expiry of the previous interval. The JRC updates the lease by 1592 executing the Parameter Update exchange with the node and 1593 including the Short_Identifier in the Configuration object, as 1594 described in Section 8.2. In case the lease expires, the node 1595 SHOULD initiate a new join exchange, as described in Section 8.1. 1596 In case this parameter is omitted, the value of positive infinity 1597 MUST be assumed, meaning that the identifier is valid for as long 1598 as the node participates in the network. 1600 The CDDL fragment that represents the text above for the 1601 Short_Identifier follows. 1603 Short_Identifier = [ 1604 identifier : bstr, 1605 ? lease_time : uint 1606 ] 1608 8.4.4.1. Use in IEEE Std 802.15.4 1610 When Short_Identifier is used in the context of [IEEE802.15.4], the 1611 following considerations apply. 1613 The identifier MUST be used to set the short address of IEEE Std 1614 802.15.4 module. When operating in TSCH mode, the identifier MUST be 1615 unique in the set of all identifiers assigned in multiple networks 1616 that share link-layer key(s). If the length of the byte string 1617 corresponding to the identifier parameter is different than 2, the 1618 identifier is considered invalid. The values 0xfffe and 0xffff are 1619 reserved by [IEEE802.15.4] and their use is considered invalid. 1621 The security properties offered by the [IEEE802.15.4] link-layer in 1622 TSCH mode are conditioned on the uniqueness requirement of the short 1623 identifier (i.e. short address). The short address is one of the 1624 inputs in the construction of the nonce, which is used to protect 1625 link-layer frames. If a misconfiguration occurs, and the same short 1626 address is assigned twice under the same link-layer key, the loss of 1627 security properties is imminent. For this reason, practices where 1628 the pledge generates the short identifier locally are not safe and 1629 are likely to result in the loss of link-layer security properties. 1631 The JRC MUST ensure that at any given time there are never two same 1632 short identifiers being used under the same link-layer key. If the 1633 lease_time parameter of a given Short_Identifier object is set to 1634 positive infinity, care needs to be taken that the corresponding 1635 identifier is not assigned to another node until the JRC is certain 1636 that it is no longer in use, potentially through out-of-band 1637 signaling. If the lease_time parameter expires for any reason, the 1638 JRC should take into consideration potential ongoing transmissions by 1639 the joined node, which may be hanging in the queues, before assigning 1640 the same identifier to another node. 1642 8.4.5. Unsupported Configuration Object 1644 The Unsupported_Configuration object is encoded as a CBOR array, 1645 containing at least one Unsupported_Parameter object. Each 1646 Unsupported_Parameter object is a sequence of CBOR elements without 1647 an enclosing top-level CBOR object for compactness. The set of 1648 parameters that appear in an Unsupported_Parameter object is 1649 summarized below, in order: 1651 o code: Indicates the capability of acting on the parameter signaled 1652 by parameter_label, encoded as an integer. This parameter MUST be 1653 included. Possible values of this parameter are specified in the 1654 IANA "CoJP Unsupported Configuration Code Registry" 1655 (Section 11.3). 1657 o parameter_label: Indicates the parameter. This parameter MUST be 1658 included. Possible values of this parameter are specified in the 1659 label column of the IANA "CoJP Parameters" registry 1660 (Section 11.1). 1662 o parameter_addinfo: Additional information about the parameter that 1663 cannot be acted upon. This parameter MUST be included. In case 1664 the code is set to "Unsupported", parameter_addinfo gives 1665 additional information to the JRC. If the parameter indicated by 1666 parameter_label cannot be acted upon regardless of its value, 1667 parameter_addinfo MUST be set to null, signaling to the JRC that 1668 it SHOULD NOT attempt to configure the parameter again. If the 1669 pledge can act on the parameter, but cannot configure the setting 1670 indicated by the parameter value, the pledge can hint this to the 1671 JRC. In this case, parameter_addinfo MUST be set to the value of 1672 the parameter that cannot be acted upon following the normative 1673 parameter structure specified in this document. For example, it 1674 is possible to include only a subset of the link-layer key set 1675 object, signaling the keys that cannot be acted upon, or the 1676 entire key set that was received. In case the code is set to 1677 "Malformed", parameter_addinfo MUST be set to null, signaling to 1678 the JRC that it SHOULD NOT attempt to configure the parameter 1679 again. 1681 The CDDL fragment that represents the text above for 1682 Unsupported_Configuration and Unsupported_Parameter objects follows. 1684 Unsupported_Configuration = [ 1685 + parameter : Unsupported_Parameter 1686 ] 1688 Unsupported_Parameter = ( 1689 code : int, 1690 parameter_label : int, 1691 parameter_addinfo : nil / any 1692 ) 1694 +-------------+-------+--------------------------------+------------+ 1695 | Name | Value | Description | Reference | 1696 +-------------+-------+--------------------------------+------------+ 1697 | Unsupported | 0 | The indicated setting is not | [[this | 1698 | | | supported by the networking | document]] | 1699 | | | stack implementation. | | 1700 | | | | | 1701 | Malformed | 1 | The indicated parameter value | [[this | 1702 | | | is malformed. | document]] | 1703 +-------------+-------+--------------------------------+------------+ 1705 Table 4: Unsupported Configuration code values. 1707 8.5. Recommended Settings 1709 This section gives RECOMMENDED values of CoJP settings. 1711 +--------------------------+---------------+ 1712 | Name | Default Value | 1713 +--------------------------+---------------+ 1714 | COJP_MAX_JOIN_ATTEMPTS | 4 | 1715 | | | 1716 | COJP_REKEYING_GUARD_TIME | 12 seconds | 1717 +--------------------------+---------------+ 1719 Recommended CoJP settings. 1721 The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible 1722 retransmissions at the link layer due to imperfect wireless links. 1724 9. Security Considerations 1726 Since this document uses the pledge identifier to set the ID Context 1727 parameter of OSCORE, an important security requirement is that the 1728 pledge identifier is unique in the set of all pledge identifiers 1729 managed by a JRC. The uniqueness of the pledge identifier ensures 1730 unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also 1731 allows the JRC to retrieve the correct security context, upon the 1732 reception of a Join Request message. The management of pledge 1733 identifiers is simplified if the globally unique EUI-64 is used, but 1734 this comes with privacy risks, as discussed in Section 10. 1736 This document further mandates that the (6LBR) pledge and the JRC are 1737 provisioned with unique PSKs. The PSK is used to set the OSCORE 1738 Master Secret during security context derivation. This derivation 1739 process results in OSCORE keys that are important for mutual 1740 authentication of the (6LBR) pledge and the JRC. Should an attacker 1741 come to know the PSK, then a man-in-the-middle attack is possible. 1743 Many vendors are known to use unsafe practices when generating and 1744 provisioning PSKs. The use of a single PSK shared among a group of 1745 devices is a common pitfall that results in poor security. In this 1746 case, the compromise of a single device is likely to lead to a 1747 compromise of the entire batch, with the attacker having the ability 1748 to impersonate a legitimate device and join the network, generate 1749 bogus data and disturb the network operation. Additionally, some 1750 vendors use methods such as scrambling or hashing of device serial 1751 numbers or their EUI-64 to generate "unique" PSKs. Without any 1752 secret information involved, the effort that the attacker needs to 1753 invest into breaking these unsafe derivation methods is quite low, 1754 resulting in the possible impersonation of any device from the batch, 1755 without even needing to compromise a single device. The use of 1756 cryptographically secure random number generators to generate the PSK 1757 is RECOMMENDED, see [NIST800-90A] for different mechanisms using 1758 deterministic methods. 1760 The JP forwards the unauthenticated join traffic into the network. A 1761 data cap on the JP prevents it from forwarding more traffic than the 1762 network can handle and enables throttling in case of an attack. The 1763 data cap can be configured by the JRC by including a join rate 1764 parameter in the Join Response and it is implemented through the 1765 CoAP's PROBING_RATE setting. The use of a data cap at a JP forces 1766 attackers to use more than one JP if they wish to overwhelm the 1767 network. Marking the join traffic packets with a non-zero DSCP 1768 allows the network to carry the traffic if it has capacity, but 1769 encourages the network to drop the extra traffic rather than add 1770 bandwidth due to that traffic. 1772 The shared nature of the "minimal" cell used for the join traffic 1773 makes the network prone to a DoS attack by congesting the JP with 1774 bogus traffic. Such an attacker is limited by its maximum transmit 1775 power. The redundancy in the number of deployed JPs alleviates the 1776 issue and also gives the pledge a possibility to use the best 1777 available link for joining. How a network node decides to become a 1778 JP is out of scope of this specification. 1780 At the beginning of the join process, the pledge has no means of 1781 verifying the content in the EB, and has to accept it at "face 1782 value". In case the pledge tries to join an attacker's network, the 1783 Join Response message will either fail the security check or time 1784 out. The pledge may implement a temporary blacklist in order to 1785 filter out undesired EBs and try to join using the next seemingly 1786 valid EB. This blacklist alleviates the issue, but is effectively 1787 limited by the node's available memory. Note that this temporary 1788 blacklist is different from the one communicated as part of the CoJP 1789 Configuration object as it helps pledge fight a DoS attack. These 1790 bogus beacons prolong the join time of the pledge, and so the time 1791 spent in "minimal" [RFC8180] duty cycle mode. The blacklist 1792 communicated as part of the CoJP Configuration object helps JP fight 1793 a DoS attack by a malicious pledge. 1795 10. Privacy Considerations 1797 The join solution specified in this document relies on the uniqueness 1798 of the pledge identifier in the set of all pledge identifiers managed 1799 by a JRC. This identifier is transferred in clear as an OSCORE kid 1800 context. The use of the globally unique EUI-64 as pledge identifier 1801 simplifies the management but comes with certain privacy risks. The 1802 implications are thoroughly discussed in [RFC7721] and comprise 1803 correlation of activities over time, location tracking, address 1804 scanning and device-specific vulnerability exploitation. Since the 1805 join process occurs rarely compared to the network lifetime, long- 1806 term threats that arise from using EUI-64 as the pledge identifier 1807 are minimal. In addition, the Join Response message contains a short 1808 address which is assigned by the JRC to the (6LBR) pledge. The 1809 assigned short address SHOULD be uncorrelated with the long-term 1810 pledge identifier. The short address is encrypted in the response. 1811 Once the join process completes, the new node uses the short 1812 addresses for all further layer 2 (and layer-3) operations. This 1813 reduces the aforementioned privacy risks as the short layer-2 address 1814 (visible even when the network is encrypted) is not traceable between 1815 locations and does not disclose the manufacturer, as is the case of 1816 EUI-64. However, an eavesdropper with access to the radio medium 1817 during the join process may be able to correlate the assigned short 1818 address with the extended address based on timing information with a 1819 non-negligible probability. This probability decreases with an 1820 increasing number of pledges joining concurrently. 1822 11. IANA Considerations 1824 Note to RFC Editor: Please replace all occurrences of "[[this 1825 document]]" with the RFC number of this specification. 1827 This document allocates a well-known name under the .arpa name space 1828 according to the rules given in [RFC3172]. The name "6tisch.arpa" is 1829 requested. No subdomains are expected. No A, AAAA or PTR record is 1830 requested. 1832 11.1. CoJP Parameters Registry 1834 This section defines a sub-registry within the "IPv6 over the TSCH 1835 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1836 "Constrained Join Protocol Parameters Registry". 1838 The columns of the registry are: 1840 Name: This is a descriptive name that enables an easier reference to 1841 the item. It is not used in the encoding. 1843 Label: The value to be used to identify this parameter. The label is 1844 an integer. 1846 CBOR type: This field contains the CBOR type for the field. 1848 Description: This field contains a brief description for the field. 1850 Reference: This field contains a pointer to the public specification 1851 for the field, if one exists. 1853 This registry is to be populated with the values in Table 2. 1855 The amending formula for this sub-registry is: Different ranges of 1856 values use different registration policies [RFC8126]. Integer values 1857 from -256 to 255 are designated as Standards Action. Integer values 1858 from -65536 to -257 and from 256 to 65535 are designated as 1859 Specification Required. Integer values greater than 65535 are 1860 designated as Expert Review. Integer values less than -65536 are 1861 marked as Private Use. 1863 11.2. CoJP Key Usage Registry 1865 This section defines a sub-registry within the "IPv6 over the TSCH 1866 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1867 "Constrained Join Protocol Key Usage Registry". 1869 The columns of this registry are: 1871 Name: This is a descriptive name that enables easier reference to the 1872 item. The name MUST be unique. It is not used in the encoding. 1874 Value: This is the value used to identify the key usage setting. 1875 These values MUST be unique. The value is an integer. 1877 Algorithm: This is a descriptive name of the link-layer algorithm in 1878 use and uniquely determines the key length. The name is not used in 1879 the encoding. 1881 Description: This field contains a description of the key usage 1882 setting. The field should describe in enough detail how the key is 1883 to be used with different frame types, specific for the link-layer 1884 technology in question. 1886 Reference: This contains a pointer to the public specification for 1887 the field, if one exists. 1889 This registry is to be populated with the values in Table 3. 1891 The amending formula for this sub-registry is: Different ranges of 1892 values use different registration policies [RFC8126]. Integer values 1893 from -256 to 255 are designated as Standards Action. Integer values 1894 from -65536 to -257 and from 256 to 65535 are designated as 1895 Specification Required. Integer values greater than 65535 are 1896 designated as Expert Review. Integer values less than -65536 are 1897 marked as Private Use. 1899 11.3. CoJP Unsupported Configuration Code Registry 1901 This section defines a sub-registry within the "IPv6 over the TSCH 1902 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1903 "Constrained Join Protocol Unsupported Configuration Code Registry". 1905 The columns of this registry are: 1907 Name: This is a descriptive name that enables easier reference to the 1908 item. The name MUST be unique. It is not used in the encoding. 1910 Value: This is the value used to identify the diagnostic code. These 1911 values MUST be unique. The value is an integer. 1913 Description: This is a descriptive human-readable name. The 1914 description MUST be unique. It is not used in the encoding. 1916 Reference: This contains a pointer to the public specification for 1917 the field, if one exists. 1919 This registry is to be populated with the values in Table 4. 1921 The amending formula for this sub-registry is: Different ranges of 1922 values use different registration policies [RFC8126]. Integer values 1923 from -256 to 255 are designated as Standards Action. Integer values 1924 from -65536 to -257 and from 256 to 65535 are designated as 1925 Specification Required. Integer values greater than 65535 are 1926 designated as Expert Review. Integer values less than -65536 are 1927 marked as Private Use. 1929 12. Acknowledgments 1931 The work on this document has been partially supported by the 1932 European Union's H2020 Programme for research, technological 1933 development and demonstration under grant agreements: No 644852, 1934 project ARMOUR; No 687884, project F-Interop and open-call project 1935 SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA. 1937 The following individuals provided input to this document (in 1938 alphabetic order): Christian Amsuss, Tengfei Chang, Klaus Hartke, 1939 Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal 1940 Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne. 1942 13. References 1943 13.1. Normative References 1945 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1946 Requirement Levels", BCP 14, RFC 2119, 1947 DOI 10.17487/RFC2119, March 1997, 1948 . 1950 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1951 "Assured Forwarding PHB Group", RFC 2597, 1952 DOI 10.17487/RFC2597, June 1999, 1953 . 1955 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1956 Requirements for the Address and Routing Parameter Area 1957 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1958 September 2001, . 1960 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1961 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1962 October 2013, . 1964 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1965 Application Protocol (CoAP)", RFC 7252, 1966 DOI 10.17487/RFC7252, June 2014, 1967 . 1969 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1970 Writing an IANA Considerations Section in RFCs", BCP 26, 1971 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1972 . 1974 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1975 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1976 . 1978 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1979 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1980 May 2017, . 1982 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1983 "Object Security for Constrained RESTful Environments 1984 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1985 . 1987 13.2. Informative References 1989 [I-D.ietf-6tisch-architecture] 1990 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1991 of IEEE 802.15.4", draft-ietf-6tisch-architecture-27 (work 1992 in progress), October 2019. 1994 [I-D.ietf-cbor-cddl] 1995 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 1996 definition language (CDDL): a notational convention to 1997 express CBOR and JSON data structures", draft-ietf-cbor- 1998 cddl-08 (work in progress), March 2019. 2000 [I-D.ietf-core-stateless] 2001 Hartke, K., "Extended Tokens and Stateless Clients in the 2002 Constrained Application Protocol (CoAP)", draft-ietf-core- 2003 stateless-02 (work in progress), October 2019. 2005 [IEEE802.15.4] 2006 IEEE standard for Information Technology, ., "IEEE Std 2007 802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 2009 [NIST800-90A] 2010 NIST Special Publication 800-90A, Revision 1, ., Barker, 2011 E., and J. Kelsey, "Recommendation for Random Number 2012 Generation Using Deterministic Random Bit Generators", 2013 2015. 2015 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 2016 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 2017 RFC 4231, DOI 10.17487/RFC4231, December 2005, 2018 . 2020 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2021 "Transmission of IPv6 Packets over IEEE 802.15.4 2022 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2023 . 2025 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2026 Key Derivation Function (HKDF)", RFC 5869, 2027 DOI 10.17487/RFC5869, May 2010, 2028 . 2030 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2031 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2032 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2033 Low-Power and Lossy Networks", RFC 6550, 2034 DOI 10.17487/RFC6550, March 2012, 2035 . 2037 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 2038 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 2039 Internet of Things (IoT): Problem Statement", RFC 7554, 2040 DOI 10.17487/RFC7554, May 2015, 2041 . 2043 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2044 Considerations for IPv6 Address Generation Mechanisms", 2045 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2046 . 2048 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2049 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2050 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2051 May 2017, . 2053 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 2054 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 2055 DOI 10.17487/RFC8480, November 2018, 2056 . 2058 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2059 Perkins, "Registration Extensions for IPv6 over Low-Power 2060 Wireless Personal Area Network (6LoWPAN) Neighbor 2061 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2062 . 2064 Appendix A. Example 2066 Figure 3 illustrates a successful join protocol exchange. The pledge 2067 instantiates the OSCORE context and derives the OSCORE keys and 2068 nonces from the PSK. It uses the instantiated context to protect the 2069 Join Request addressed with a Proxy-Scheme option, the well-known 2070 host name of the JRC in the Uri-Host option, and its EUI-64 as pledge 2071 identifier and OSCORE kid context. Triggered by the presence of a 2072 Proxy-Scheme option, the JP forwards the request to the JRC and sets 2073 the CoAP token to the internally needed state. The JP has learned 2074 the IPv6 address of the JRC when it acted as a pledge and joined the 2075 network. Once the JRC receives the request, it looks up the correct 2076 context based on the kid context parameter. The OSCORE data 2077 authenticity verification ensures that the request has not been 2078 modified in transit. In addition, replay protection is ensured 2079 through persistent handling of mutable context parameters. 2081 Once the JP receives the Join Response, it authenticates the state 2082 within the CoAP token before deciding where to forward. The JP sets 2083 its internal state to that found in the token, and forwards the Join 2084 Response to the correct pledge. Note that the JP does not possess 2085 the key to decrypt the CBOR object (configuration) present in the 2086 payload. The Join Response is matched to the Join Request and 2087 verified for replay protection at the pledge using OSCORE processing 2088 rules. In this example, the Join Response does not contain the IPv6 2089 address of the JRC, the pledge hence understands the JRC is co- 2090 located with the 6LBR. 2092 <---E2E OSCORE--> 2093 Client Proxy Server 2094 Pledge JP JRC 2095 | | | 2096 | Join | | Code: 0.02 (POST) 2097 | Request | | Token: - 2098 +--------->| | Proxy-Scheme: coap 2099 | | | Uri-Host: 6tisch.arpa 2100 | | | OSCORE: kid: -, 2101 | | | kid_context: EUI-64, 2102 | | | Partial IV: 1 2103 | | | Payload: { Code: 0.02 (POST), 2104 | | | Uri-Path: "j", 2105 | | | join_request, } 2106 | | | 2107 | | Join | Code: 0.02 (POST) 2108 | | Request | Token: opaque state 2109 | +--------->| OSCORE: kid: -, 2110 | | | kid_context: EUI-64, 2111 | | | Partial IV: 1 2112 | | | Payload: { Code: 0.02 (POST), 2113 | | | Uri-Path: "j", 2114 | | | join_request, } 2115 | | | 2116 | | | 2117 | | Join | Code: 2.04 (Changed) 2118 | | Response | Token: opaque state 2119 | |<---------+ OSCORE: - 2120 | | | Payload: { Code: 2.04 (Changed), 2121 | | | configuration, } 2122 | | | 2123 | | | 2124 | Join | | Code: 2.04 (Changed) 2125 | Response | | Token: - 2126 |<---------+ | OSCORE: - 2127 | | | Payload: { Code: 2.04 (Changed), 2128 | | | configuration, } 2129 | | | 2131 Figure 3: Example of a successful join protocol exchange. { ... } 2132 denotes authenticated encryption, denotes the authentication 2133 tag. 2135 Where the join_request object is: 2137 join_request: 2138 { 2139 5 : h'cafe' / PAN ID of the network pledge is attempting to join / 2140 } 2142 Since the role parameter is not present, the default role of "6TiSCH 2143 Node" is implied. 2145 The join_request object encodes to h'a10542cafe' with a size of 5 2146 bytes. 2148 And the configuration object is: 2150 configuration: 2151 { 2152 2 : [ / link-layer key set / 2153 1, / key_id / 2154 h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / 2155 ], 2156 3 : [ / short identifier / 2157 h'af93' / assigned short address / 2158 ] 2159 } 2161 Since the key_usage parameter is not present in the link-layer key 2162 set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. 2163 Since key_addinfo parameter is not present and key_id is different 2164 than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since 2165 the lease_time parameter is not present in the short identifier 2166 object, the default value of positive infinity is implied. 2168 The configuration object encodes to 2170 h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size 2171 of 26 bytes. 2173 Appendix B. Lightweight Implementation Option 2175 In environments where optimizing the implementation footprint is 2176 important, it is possible to implement this specification without 2177 having the implementations of HKDF [RFC5869] and SHA [RFC4231] on 2178 constrained devices. HKDF and SHA are used during the OSCORE 2179 security context derivation phase. This derivation can also be done 2180 by the JRC or a provisioning device, on behalf of the (6LBR) pledge 2181 during the provisioning phase. In that case, the derived OSCORE 2182 security context parameters are written directly into the (6LBR) 2183 pledge, without requiring the PSK be provisioned to the (6LBR) 2184 pledge. 2186 The use of HKDF to derive OSCORE security context parameters ensures 2187 that the resulting OSCORE keys have good security properties, and are 2188 unique as long as the input for different pledges varies. This 2189 specification ensures the uniqueness by mandating unique pledge 2190 identifiers and a unique PSK for each (6LBR) pledge. From the AEAD 2191 nonce reuse viewpoint, having a unique pledge identifier is a 2192 sufficient condition. However, as discussed in Section 9, the use of 2193 a single PSK shared among many devices is a common security pitfall. 2194 The compromise of this shared PSK on a single device would lead to 2195 the compromise of the entire batch. When using the implementation/ 2196 deployment scheme outlined above, the PSK does not need to be written 2197 to individual pledges. As a consequence, even if a shared PSK is 2198 used, the scheme offers the same level of security as in the scenario 2199 where each pledge is provisioned with a unique PSK. 2201 Authors' Addresses 2203 Malisa Vucinic (editor) 2204 Inria 2205 2 Rue Simone Iff 2206 Paris 75012 2207 France 2209 Email: malisa.vucinic@inria.fr 2211 Jonathan Simon 2212 Analog Devices 2213 32990 Alvarado-Niles Road, Suite 910 2214 Union City, CA 94587 2215 USA 2217 Email: jonathan.simon@analog.com 2219 Kris Pister 2220 University of California Berkeley 2221 512 Cory Hall 2222 Berkeley, CA 94720 2223 USA 2225 Email: pister@eecs.berkeley.edu 2226 Michael Richardson 2227 Sandelman Software Works 2228 470 Dawson Avenue 2229 Ottawa, ON K1Z5V7 2230 Canada 2232 Email: mcr+ietf@sandelman.ca