idnits 2.17.1 draft-ietf-6tisch-minimal-security-12.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 (July 29, 2019) is 1730 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-24 == Outdated reference: A later version (-08) exists of draft-ietf-core-stateless-01 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: January 30, 2020 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 July 29, 2019 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-12 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 January 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-terminology]. 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 [I-D.ietf-core-object-security] for its end- 131 to-end security. The secure join solution defined in this document 132 therefore reuses those 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-terminology], [RFC7252], 175 [I-D.ietf-core-object-security], and [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-terminology] are used 182 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. 267 o Optionally, a network identifier. The network identifier 268 identifies the 6TiSCH network. The network identifier MUST be 269 carried within Enhanced Beacon (EB) frames. Typically, the 16-bit 270 Personal Area Network Identifier (PAN ID) defined in 271 [IEEE802.15.4] is used as the network identifier. However, PAN ID 272 is not considered a stable network identifier as it may change 273 during network lifetime if a collision with another network is 274 detected. Companion documents can specify the use of a different 275 network identifier for join purposes, but this is out of scope of 276 this specification. Provisioning the network identifier is 277 RECOMMENDED. However, due to operational constraints, the network 278 identifier may not be known at the time when the provisioning is 279 done. In case this parameter is not provisioned to the pledge, 280 the pledge attempts to join one advertised network at a time, 281 which significantly prolongs the join process. This parameter 282 MUST be provisioned to the 6LBR pledge. 284 o Optionally, any non-default algorithms. The default algorithms 285 are specified in Section 7.3.3. When algorithm identifiers are 286 not exchanged, the use of these default algorithms is implied. 288 Additionally, the 6LBR pledge that is not co-located with the JRC 289 needs to be provisioned with: 291 o Global IPv6 address of the JRC. This address is used by the 6LBR 292 pledge to address the JRC during the join process. The 6LBR 293 pledge may also obtain the IPv6 address of the JRC through other 294 available mechanisms, such as DHCPv6, GRASP, mDNS, the use of 295 which is out of scope of this document. Pledges do not need to be 296 provisioned with this address as they discover it dynamically 297 through CoJP. 299 4. Join Process Overview 301 This section describes the steps taken by a pledge in a 6TiSCH 302 network. When a pledge seeks admission to a 6TiSCH network, the 303 following exchange occurs: 305 1. The pledge listens for an Enhanced Beacon (EB) frame 306 [IEEE802.15.4]. This frame provides network synchronization 307 information, and tells the device when it can send a frame to the 308 node sending the beacons, which acts as a Join Proxy (JP) for the 309 pledge, and when it can expect to receive a frame. The Enhanced 310 Beacon provides the L2 address of the JP and it may also provide 311 its link-local IPv6 address. 313 2. The pledge configures its link-local IPv6 address and advertises 314 it to the JP using Neighbor Discovery. This step may be omitted 315 if the link-local address has been derived from a known unique 316 interface identifier, such as an EUI-64 address. 318 3. The pledge sends a Join Request to the JP in order to securely 319 identify itself to the network. The Join Request is forwarded to 320 the JRC. 322 4. In case of successful processing of the request, the pledge 323 receives a Join Response from the JRC (via the JP). The Join 324 Response contains configuration parameters necessary for the 325 pledge to join the network. 327 From the pledge's perspective, joining is a local phenomenon - the 328 pledge only interacts with the JP, and it needs not know how far it 329 is from the 6LBR, or how to route to the JRC. Only after 330 establishing one or more link-layer keys does it need to know about 331 the particulars of a 6TiSCH network. 333 The join process is shown as a transaction diagram in Figure 1: 335 +--------+ +-------+ +--------+ 336 | pledge | | JP | | JRC | 337 | | | | | | 338 +--------+ +-------+ +--------+ 339 | | | 340 |<---Enhanced Beacon (1)---| | 341 | | | 342 |<-Neighbor Discovery (2)->| | 343 | | | 344 |-----Join Request (3a)----|----Join Request (3a)---->| \ 345 | | | | CoJP 346 |<----Join Response (3b)---|----Join Response (3b)----| / 347 | | | 349 Figure 1: Overview of a successful join process. 351 As other nodes in the network, the 6LBR node may act as the JP. The 352 6LBR may in addition be co-located with the JRC. 354 The details of each step are described in the following sections. 356 4.1. Step 1 - Enhanced Beacon 358 The pledge synchronizes to the network by listening for, and 359 receiving, an Enhanced Beacon (EB) sent by a node already in the 360 network. This process is entirely defined by [IEEE802.15.4], and 361 described in [RFC7554]. 363 Once the pledge hears an EB, it synchronizes to the joining schedule 364 using the cells contained in the EB. The pledge can hear multiple 365 EBs; the selection of which EB to use is out of the scope for this 366 document, and is discussed in [RFC7554]. Implementers should make 367 use of information such as: what network identifier the EB contains, 368 the value of the Join Metric field within EBs, whether the source 369 link-layer address of the EB has been tried before, what signal 370 strength the different EBs were received at, etc. In addition, the 371 pledge may be pre-configured to search for EBs with a specific 372 network identifier. 374 If the pledge is not provisioned with the network identifier, it 375 attempts to join one network at a time, as described in 376 Section 8.1.1. 378 Once the pledge selects the EB, it synchronizes to it and transitions 379 into a low-power mode. It follows the schedule information contained 380 in the EB which indicates the slots that the pledge may use for the 381 join process. During the remainder of the join process, the node 382 that has sent the EB to the pledge acts as the JP. 384 At this point, the pledge may proceed to step 2, or continue to 385 listen for additional EBs. 387 4.2. Step 2 - Neighbor Discovery 389 The pledge forms its link-local IPv6 address based on the interface 390 identifier, as per [RFC4944]. The pledge MAY perform the Neighbor 391 Solicitation / Neighbor Advertisement exchange with the JP, as per 392 Section 5.6 of [RFC8505]. The pledge and the JP use their link-local 393 IPv6 addresses for all subsequent communication during the join 394 process. 396 Note that Neighbor Discovery exchanges at this point are not 397 protected with link-layer security as the pledge is not in possession 398 of the keys. How JP accepts these unprotected frames is discussed in 399 Section 5. 401 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution 403 The pledge triggers the join exchange of the Constrained Join 404 Protocol (CoJP). The join exchange consists of two messages: the 405 Join Request message (Step 3a), and the Join Response message 406 conditioned on the successful security processing of the request 407 (Step 3b). 409 All CoJP messages are exchanged over a secure end-to-end channel that 410 provides confidentiality, data authenticity and replay protection. 411 Frames carrying CoJP messages are not protected with link-layer 412 security when exchanged between the pledge and the JP as the pledge 413 is not in possession of the link-layer keys in use. How JP and 414 pledge accept these unprotected frames is discussed in Section 5. 415 When frames carrying CoJP messages are exchanged between nodes that 416 have already joined the network, the link-layer security is applied 417 according to the security configuration used in the network. 419 4.3.1. Step 3a - Join Request 421 The Join Request is a message sent from the pledge to the JP, and 422 which the JP forwards to the JRC. The pledge indicates in the Join 423 Request the role it requests to play in the network, as well as the 424 identifier of the network it requests to join. The JP forwards the 425 Join Request to the JRC on the existing links. How exactly this 426 happens is out of scope of this document; some networks may wish to 427 dedicate specific link layer resources for this join traffic. 429 4.3.2. Step 3b - Join Response 431 The Join Response is sent by the JRC to the pledge, and is forwarded 432 through the JP. The packet containing the Join Response travels from 433 the JRC to the JP using the operating routes in the network. The JP 434 delivers it to the pledge. The JP operates as the application-layer 435 proxy. 437 The Join Response contains different parameters needed by the pledge 438 to become a fully operational network node. These parameters include 439 the link-layer key(s) currently in use in the network, the short 440 address assigned to the pledge, the IPv6 address of the JRC needed by 441 the pledge to operate as the JP, among others. 443 4.4. The Special Case of the 6LBR Pledge Joining 445 The 6LBR pledge performs Section 4.3 of the join process described 446 above, just as any other pledge, albeit over a different network 447 interface. There is no JP intermediating the communication between 448 the 6LBR pledge and the JRC, as described in Section 6. The other 449 steps of the described join process do not apply to the 6LBR pledge. 450 How the 6LBR pledge obtains an IPv6 address and triggers the 451 execution of the CoJP protocol is out of scope of this document. 453 5. Link-layer Configuration 455 In an operational 6TiSCH network, all frames MUST use link-layer 456 frame security [RFC8180]. The IEEE Std 802.15.4 security attributes 457 MUST include frame authenticity, and MAY include frame 458 confidentiality (i.e. encryption). 460 The pledge does not initially do any authenticity check of the EB 461 frames, as it does not possess the link-layer key(s) in use. The 462 pledge is still able to parse the contents of the received EBs and 463 synchronize to the network, as EBs are not encrypted [RFC8180]. 465 When sending frames during the join process, the pledge sends 466 unencrypted and unauthenticated frames. The JP accepts these 467 unsecured frames for the duration of the join process. This behavior 468 may be implemented by setting the "secExempt" attribute in the IEEE 469 Std 802.15.4 security configuration tables. How the JP learns 470 whether the join process is ongoing is out of scope of this 471 specification. 473 When the pledge initially synchronizes to the network, it has no 474 means of verifying the authenticity of EB frames. As an attacker can 475 craft a frame that looks like a legitimate EB frame, this opens up a 476 DoS vector, as discussed in Section 9. 478 5.1. Distribution of Time 480 Nodes in a 6TiSCH network keep a global notion of time known as the 481 absolute slot number (ASN). ASN is used in the construction of the 482 link-layer nonce, as defined in [IEEE802.15.4]. The pledge initially 483 synchronizes to the EB frame sent by the JP, and uses the value of 484 the ASN found in the TSCH Synchronization Information Element. At 485 the time of the synchronization, the EB frame can neither be 486 authenticated nor its freshness verified. During the join process, 487 the pledge sends frames that are unprotected at the link-layer and 488 protected end-to-end instead. The pledge does not obtain the time 489 information as the output of the join process as this information is 490 local to the network and may not be known at the JRC. 492 This enables an attack on the pledge where the attacker replays to 493 the pledge legitimate EB frames obtained from the network and acts as 494 a man-in-the-middle between the pledge and the JP. The EB frames 495 will make the pledge believe that the replayed ASN value is the 496 current notion of time in the network. By forwarding the join 497 traffic to the legitimate JP, the attacker enables the pledge to join 498 the network. Under different conditions relating to the reuse of the 499 pledge's short address by the JRC or its attempt to rejoin the 500 network, this may cause the pledge to reuse the link-layer nonce in 501 the first frame it sends protected after the join process is 502 completed. 504 For this reason, all frames originated at the JP and destined to the 505 pledge during the join process MUST be authenticated at the link- 506 layer using the key that is normally in use in the network. Link- 507 layer security processing at the pledge for these frames will fail as 508 the pledge is not yet in possession of the key. The pledge 509 acknowledges these frames without link-layer security, and JP accepts 510 the unsecured acknowledgment due to the secExempt attribute set for 511 the pledge. The frames should be passed to the upper layer for 512 processing using the promiscuous mode of [IEEE802.15.4] or another 513 appropriate mechanism. When the upper layer processing is completed 514 and the link-layer keys are configured, the upper layer MUST trigger 515 the security processing of the corresponding frame. Once the 516 security processing of the frame carrying the Join Response message 517 is successful, the current ASN kept locally at the pledge SHALL be 518 declared as valid. 520 6. Network-layer Configuration 522 The pledge and the JP SHOULD keep a separate neighbor cache for 523 untrusted entries and use it to store each other's information during 524 the join process. Mixing neighbor entries belonging to pledges and 525 nodes that are part of the network opens up the JP to a DoS attack, 526 as the attacker may fill JP's neighbor table and prevent the 527 discovery of legitimate neighbors. 529 Once the pledge obtains link-layer keys and becomes a joined node, it 530 is able to securely communicate with its neighbors, obtain the 531 network IPv6 prefix and form its global IPv6 address. The joined 532 node then undergoes an independent process to bootstrap its neighbor 533 cache entries, possibly with a node that formerly acted as a JP, 534 following [RFC8505]. From the point of view of the JP, there is no 535 relationship between the neighbor cache entry belonging to a pledge 536 and the joined node that formerly acted as a pledge. 538 The pledge does not communicate with the JRC at the network layer. 539 This allows the pledge to join without knowing the IPv6 address of 540 the JRC. Instead, the pledge communicates with the JP at the network 541 layer using link-local addressing, and with the JRC at the 542 application layer, as specified in Section 7. 544 The JP communicates with the JRC over global IPv6 addresses. The JP 545 discovers the network IPv6 prefix and configures its global IPv6 546 address upon successful completion of the join process and the 547 obtention of link-layer keys. The pledge learns the IPv6 address of 548 the JRC from the Join Response, as specified in Section 8.1.2; it 549 uses it once joined in order to operate as a JP. 551 As a special case, the 6LBR pledge is expected to have an additional 552 network interface that it uses in order to obtain the configuration 553 parameters from the JRC and start advertising the 6TiSCH network. 554 This additional interface needs to be configured with a global IPv6 555 address, by a mechanism that is out of scope of this document. The 556 6LBR pledge uses this interface to directly communicate with the JRC 557 using global IPv6 addressing. 559 The JRC can be co-located on the 6LBR. In this special case, the 560 IPv6 address of the JRC can be omitted from the Join Response message 561 for space optimization. The 6LBR then MUST set the DODAGID field in 562 the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the 563 address of the JRC once joined and upon the reception of the first 564 RPL DIO message, and uses it to operate as a JP. 566 6.1. Identification of Unauthenticated Traffic 568 The traffic that is proxied by the Join Proxy (JP) comes from 569 unauthenticated pledges, and there may be an arbitrary amount of it. 570 In particular, an attacker may send fraudulent traffic in an attempt 571 to overwhelm the network. 573 When operating as part of a [RFC8180] 6TiSCH minimal network using 574 distributed scheduling algorithms, the traffic from unauthenticated 575 pledges may cause intermediate nodes to request additional bandwidth. 576 An attacker could use this property to cause the network to 577 overcommit bandwidth (and energy) to the join process. 579 The Join Proxy is aware of what traffic originates from 580 unauthenticated pledges, and so can avoid allocating additional 581 bandwidth itself. The Join Proxy implements a data cap on outgoing 582 join traffic through CoAP's congestion control mechanism. This cap 583 will not protect intermediate nodes as they can not tell join traffic 584 from regular traffic. Despite the data cap implemented separately on 585 each Join Proxy, the aggregate join traffic from many Join Proxies 586 may cause intermediate nodes to decide to allocate additional cells. 587 It is undesirable to do so in response to the traffic originated at 588 unauthenticated pledges. In order to permit the intermediate nodes 589 to avoid this, the traffic needs to be tagged. [RFC2597] defines a 590 set of per-hop behaviors that may be encoded into the Diffserv Code 591 Points (DSCPs). Based on the DSCP, intermediate nodes can decide 592 whether to act on a given packet. 594 6.1.1. Traffic from JP to JRC 596 The Join Proxy SHOULD set the DSCP of packets that it produces as 597 part of the forwarding process to AF43 code point (See Section 6 of 598 [RFC2597]). A Join Proxy that does not set the DSCP on traffic 599 forwarded should set it to zero so that it is compressed out. 601 A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT 602 allocate additional cells as a result of traffic with code point 603 AF43. Companion SF documents SHOULD specify how this recommended 604 behavior is achieved. 606 6.1.2. Traffic from JRC to JP 608 The JRC SHOULD set the DSCP of join response packets addressed to the 609 Join Proxy to AF42 code point. AF42 has lower drop probability than 610 AF43, giving this traffic priority in buffers over the traffic going 611 towards the JRC. 613 Due to the convergecast nature of the DODAG, the 6LBR links are often 614 the most congested, and from that point down there is progressively 615 less (or equal) congestion. If the 6LBR paces itself when sending 616 join response traffic then it ought to never exceed the bandwidth 617 allocated to the best effort traffic cells. If the 6LBR has the 618 capacity (if it is not constrained) then it should provide some 619 buffers in order to satisfy the Assured Forwarding behavior. 621 Companion SF documents SHOULD specify how traffic with code point 622 AF42 is handled with respect to cell allocation. In case the 623 recommended behavior described in this section is not followed, the 624 network may become prone to the attack discussed in Section 6.1. 626 7. Application-level Configuration 628 The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and 629 the secure channel provided by OSCORE 630 [I-D.ietf-core-object-security]. The (6LBR) pledge acts as a CoAP 631 client; the JRC acts as a CoAP server. The JP implements CoAP 632 forward proxy functionality [RFC7252]. Because the JP can also be a 633 constrained device, it cannot implement a cache. 635 The pledge designates a JP as a proxy by including the Proxy-Scheme 636 option in CoAP requests it sends to the JP. The pledge also includes 637 in the requests the Uri-Host option with its value set to the well- 638 known JRC's alias, as specified in Section 8.1.1. 640 The JP resolves the alias to the IPv6 address of the JRC that it 641 learned when it acted as a pledge, and joined the network. This 642 allows the JP to reach the JRC at the network layer and forward the 643 requests on behalf of the pledge. 645 7.1. Statelessness of the JP 647 The CoAP proxy defined in [RFC7252] keeps per-client state 648 information in order to forward the response towards the originator 649 of the request. This state information includes at least the CoAP 650 token, the IPv6 address of the client, and the UDP source port 651 number. Since the JP can be a constrained device that acts as a CoAP 652 proxy, memory limitations make it prone to a Denial-of-Service (DoS) 653 attack. 655 This DoS vector on the JP can be mitigated by making the JP act as a 656 stateless CoAP proxy, where "state" encompasses the information 657 related individual pledges. The JP can wrap the state it needs to 658 keep for a given pledge throughout the network stack in a "state 659 object" and include it as a CoAP token in the forwarded request to 660 the JRC. The JP may use the CoAP token as defined in [RFC7252], if 661 the size of the serialized state object permits, or use the extended 662 CoAP token defined in [I-D.ietf-core-stateless], to transport the 663 state object. Since the CoAP token is echoed back in the response, 664 the JP is able to decode the state object and configure the state 665 needed to forward the response to the pledge. The information that 666 the JP needs to encode in the state object to operate in a fully 667 stateless manner with respect to a given pledge is implementation 668 specific. 670 It is RECOMMENDED that the JP operates in a stateless manner and 671 signals the per-pledge state within the CoAP token, for every request 672 it forwards into the network on behalf of unauthenticated pledges. 673 When operating in a stateless manner, the security considerations 674 from [I-D.ietf-core-stateless] apply and the type of the CoAP message 675 that the JP forwards on behalf of the pledge MUST be non-confirmable 676 (NON), regardless of the message type received from the pledge. The 677 use of a non-confirmable message by the JP alleviates the JP from 678 keeping CoAP message exchange state. The retransmission burden is 679 then entirely shifted to the pledge. A JP that operates in a 680 stateless manner still needs to keep congestion control state with 681 the JRC, see Section 9. Recommended values of CoAP settings for use 682 during the join process, both by the pledge and the JP, are given in 683 Section 7.2. 685 Note that in some networking stack implementations, a fully (per- 686 pledge) stateless operation of the JP may be challenging from the 687 implementation's point of view. In those cases, the JP may operate 688 as a statefull proxy that stores the per-pledge state until the 689 response is received or timed out, but this comes at a price of a DoS 690 vector. 692 7.2. Recommended Settings 694 This section gives RECOMMENDED values of CoAP settings during the 695 join process. 697 +-------------------+-----------------------+-------------------+ 698 | Name | Default Value: Pledge | Default Value: JP | 699 +-------------------+-----------------------+-------------------+ 700 | ACK_TIMEOUT | 10 seconds | (10 seconds) | 701 | | | | 702 | ACK_RANDOM_FACTOR | 1.5 | (1.5) | 703 | | | | 704 | MAX_RETRANSMIT | 4 | (4) | 705 +-------------------+-----------------------+-------------------+ 707 Recommended CoAP settings. Values enclosed in () have no effect when 708 JP operates in a stateless manner. 710 These values may be configured to values specific to the deployment. 711 The default values have been chosen to accommodate a wide range of 712 deployments, taking into account dense networks. 714 The PROBING_RATE value at the JP is controlled by the join rate 715 parameter, see Section 8.4.2. Following [RFC7252], the average data 716 rate in sending to the JRC must not exceed PROBING_RATE. For 717 security reasons, the average data rate SHOULD be measured over a 718 rather short window, e.g. ACK_TIMEOUT, see Section 9. 720 7.3. OSCORE 722 Before the (6LBR) pledge and the JRC start exchanging CoAP messages 723 protected with OSCORE, they need to derive the OSCORE security 724 context from the provisioned parameters, as discussed in Section 3. 726 The OSCORE security context MUST be derived as per Section 3 of 727 [I-D.ietf-core-object-security]. 729 o the Master Secret MUST be the PSK. 731 o the Master Salt MUST be the empty byte string. 733 o the ID Context MUST be set to the pledge identifier. 735 o the ID of the pledge MUST be set to the empty byte string. This 736 identifier is used as the OSCORE Sender ID of the pledge in the 737 security context derivation, since the pledge initially acts as a 738 CoAP client. 740 o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" 741 in ASCII). This identifier is used as the OSCORE Recipient ID of 742 the pledge in the security context derivation, as the JRC 743 initially acts as a CoAP server. 745 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 746 of-band by the same mechanism used to provision the PSK. The 747 default is AES-CCM-16-64-128. 749 o the Key Derivation Function MUST be agreed out-of-band by the same 750 mechanism used to provision the PSK. Default is HKDF SHA-256 751 [RFC5869]. 753 Since the pledge's OSCORE Sender ID is the empty byte string, when 754 constructing the OSCORE option, the pledge sets the k bit in the 755 OSCORE flag byte, but indicates a 0-length kid. The pledge 756 transports its pledge identifier within the kid context field of the 757 OSCORE option. The derivation in [I-D.ietf-core-object-security] 758 results in OSCORE keys and a common IV for each side of the 759 conversation. Nonces are constructed by XOR'ing the common IV with 760 the current sequence number. For details on nonce and OSCORE option 761 construction, refer to [I-D.ietf-core-object-security]. 763 Implementations MUST ensure that multiple CoAP requests, including to 764 different JRCs, are properly incrementing the sequence numbers, so 765 that the same sequence number is never reused in distinct requests. 766 The pledge typically sends requests to different JRCs if it is not 767 provisioned with the network identifier and attempts to join one 768 network at a time. Failure to comply will break the security 769 guarantees of the Authenticated Encryption with Associated Data 770 (AEAD) algorithm because of nonce reuse. 772 This OSCORE security context is used for initial joining of the 773 (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well 774 as for any later parameter updates, where the JRC acts as a CoAP 775 client and the joined node as a CoAP server, as discussed in 776 Section 8.2. Note that when the (6LBR) pledge and the JRC change 777 roles between CoAP client and CoAP server, the same OSCORE security 778 context as initially derived remains in use and the derived 779 parameters are unchanged, for example Sender ID when sending and 780 Recipient ID when receiving (see Section 3.1 of 781 [I-D.ietf-core-object-security]). A (6LBR) pledge is expected to 782 have exactly one OSCORE security context with the JRC. 784 7.3.1. Replay Window and Persistency 786 Both (6LBR) pledge and the JRC MUST implement a replay protection 787 mechanism. The use of the default OSCORE replay protection mechanism 788 specified in Section 3.2.2 of [I-D.ietf-core-object-security] is 789 RECOMMENDED. 791 Implementations MUST ensure that mutable OSCORE context parameters 792 (Sender Sequence Number, Replay Window) are stored in persistent 793 memory. A technique that prevents reuse of sequence numbers, 794 detailed in Appendix B.1.1 of [I-D.ietf-core-object-security], MUST 795 be implemented. Each update of the OSCORE Replay Window MUST be 796 written to persistent memory. 798 This is an important security requirement in order to guarantee nonce 799 uniqueness and resistance to replay attacks across reboots and 800 rejoins. Traffic between the (6LBR) pledge and the JRC is rare, 801 making security outweigh the cost of writing to persistent memory. 803 7.3.2. OSCORE Error Handling 805 Errors raised by OSCORE during the join process MUST be silently 806 dropped, with no error response being signaled. The pledge MUST 807 silently discard any response not protected with OSCORE, including 808 error codes. 810 Such errors may happen for a number of reasons, including failed 811 lookup of an appropriate security context (e.g. the pledge attempting 812 to join a wrong network), failed decryption, positive replay window 813 lookup, formatting errors (possibly due to malicious alterations in 814 transit). Silently dropping OSCORE messages prevents a DoS attack on 815 the pledge where the attacker could send bogus error responses, 816 forcing the pledge to attempt joining one network at a time, until 817 all networks have been tried. 819 7.3.3. Mandatory to Implement Algorithms 821 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 822 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 823 securing IEEE Std 802.15.4 frames, and hardware acceleration for it 824 is present in virtually all compliant radio chips. With this choice, 825 CoAP messages are protected with an 8-byte CCM authentication tag, 826 and the algorithm uses 13-byte long nonces. 828 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The 829 mandatory to implement key derivation function is HKDF [RFC5869], 830 instantiated with a SHA-256 hash. See Appendix B for implementation 831 guidance when code footprint is important. 833 8. Constrained Join Protocol (CoJP) 835 The Constrained Join Protocol (CoJP) is a lightweight protocol over 836 CoAP [RFC7252] and a secure channel provided by OSCORE 837 [I-D.ietf-core-object-security]. CoJP allows the (6LBR) pledge to 838 request admission into a network managed by the JRC, and for the JRC 839 to configure the pledge with the parameters necessary for joining the 840 network, or advertising it in the case of 6LBR pledge. The JRC may 841 update the parameters at any time, by reaching out to the joined node 842 that formerly acted as a (6LBR) pledge. For example, network-wide 843 rekeying can be implemented by updating the keying material on each 844 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 927 [I-D.ietf-core-object-security]. The OSCORE security context used 928 is the one derived in Section 7.3. The OSCORE kid context allows 929 the JRC to retrieve the security context 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 to the user the presence of an error condition, 945 through some 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 993 [I-D.ietf-core-object-security]. The OSCORE security context used 994 is the one derived in Section 7.3. When a joined node receives a 995 request with the Sender ID set to 0x4a5243 (ID of the JRC), it is 996 able to correctly retrieve the security 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 to the user the 1053 presence of an 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 1109 [I-D.ietf-core-object-security]. Aware of the failure event, the 1110 reinitialized JRC responds to the first join request of each pledge 1111 it is managing with a 4.01 Unauthorized error and a random nonce. 1112 The pledge verifies the error response and then initiates the CoJP 1113 join exchange using a new OSCORE security context derived from an ID 1114 Context consisting of the concatenation of two nonces, one that it 1115 received from the JRC and the other that the pledge generates 1116 locally. After verifying the join request with the new ID Context 1117 and the derived OSCORE security context, the JRC should consequently 1118 take action in mapping the new ID Context with the previously used 1119 pledge identifier. How JRC handles this mapping is implementation 1120 specific. 1122 The described procedure is specified in Appendix B.2 of 1123 [I-D.ietf-core-object-security] and is RECOMMENDED in order to handle 1124 the failure events or any other event that may lead to the loss of 1125 mutable security context parameters. The length of nonces exchanged 1126 using this procedure SHOULD be at least 8 bytes. 1128 The procedure does require both the pledge and the JRC to have good 1129 sources of randomness. While this is typically not an issue at the 1130 JRC side, the constrained device hosting the pledge may pose 1131 limitations in this regard. If the procedure outlined in 1132 Appendix B.2 of [I-D.ietf-core-object-security] is not supported by 1133 the pledge, the network administrator MUST take action in 1134 reprovisioning the concerned devices with freshly generated 1135 parameters, through out-of-band means. 1137 8.4. CoJP Objects 1139 This section specifies the structure of CoJP CBOR objects that may be 1140 carried as the payload of CoJP messages. Some of these objects may 1141 be received both as part of the CoJP join exchange when the device 1142 operates as a (CoJP) pledge, or the parameter update exchange, when 1143 the device operates as a joined (6LBR) node. 1145 8.4.1. Join Request Object 1147 The Join_Request structure is built on a CBOR map object. 1149 The set of parameters that can appear in a Join_Request object is 1150 summarized below. The labels can be found in the "CoJP Parameters" 1151 registry Section 11.1. 1153 o role: The identifier of the role that the pledge requests to play 1154 in the network once it joins, encoded as an unsigned integer. 1155 Possible values are specified in Table 1. This parameter MAY be 1156 included. In case the parameter is omitted, the default value of 1157 0, i.e. the role "6TiSCH Node", MUST be assumed. 1159 o network identifier: The identifier of the network, as discussed in 1160 Section 3, encoded as a CBOR byte string. When present in the 1161 Join_Request, it hints to the JRC the network that the pledge is 1162 requesting to join, enabling the JRC to manage multiple networks. 1163 The pledge obtains the value of the network identifier from the 1164 received EB frames. This parameter MUST be included in a 1165 Join_Request object regardless of the role parameter value. 1167 o unsupported configuration: The identifier of the parameters that 1168 are not supported by the implementation, encoded as an 1169 Unsupported_Configuration object described in Section 8.4.5. This 1170 parameter MAY be included. If a (6LBR) pledge previously 1171 attempted to join and received a valid Join Response message over 1172 OSCORE, but failed to act on its payload (Configuration object), 1173 it SHOULD include this parameter to facilitate the recovery and 1174 debugging. 1176 The CDDL fragment that represents the text above for the Join_Request 1177 follows. 1179 Join_Request = { 1180 ? 1 : uint, ; role 1181 ? 5 : bstr, ; network identifier 1182 ? 8 : Unsupported_Configuration ; unsupported configuration 1183 } 1184 +--------+-------+-------------------------------------+------------+ 1185 | Name | Value | Description | Reference | 1186 +--------+-------+-------------------------------------+------------+ 1187 | 6TiSCH | 0 | The pledge requests to play the | [[this | 1188 | Node | | role of a regular 6TiSCH node, i.e. | document]] | 1189 | | | non-6LBR node. | | 1190 | | | | | 1191 | 6LBR | 1 | The pledge requests to play the | [[this | 1192 | | | role of 6LoWPAN Border Router | document]] | 1193 | | | (6LBR). | | 1194 +--------+-------+-------------------------------------+------------+ 1196 Table 1: Role values. 1198 8.4.2. Configuration Object 1200 The Configuration structure is built on a CBOR map object. The set 1201 of parameters that can appear in a Configuration object is summarized 1202 below. The labels can be found in "CoJP Parameters" registry 1203 Section 11.1. 1205 o link-layer key set: An array encompassing a set of cryptographic 1206 keys and their identifiers that are currently in use in the 1207 network, or that are scheduled to be used in the future. The 1208 encoding of individual keys is described in Section 8.4.3. The 1209 link-layer key set parameter MAY be included in a Configuration 1210 object. When present, the link-layer key set parameter MUST 1211 contain at least one key. When a pledge is joining for the first 1212 time and receives this parameter, before sending the first 1213 outgoing frame secured with a received key, the pledge needs to 1214 successfully complete the security processing of an incoming 1215 frame. To do so, the pledge can wait to receive a new frame, or 1216 it can store an EB frame that it used to find the JP and use it 1217 for immediate security processing upon reception of the key set. 1218 This parameter is also used to implement rekeying in the network. 1219 How the keys are installed and used differs for the 6LBR and other 1220 (regular) nodes, and this is explained in Section 8.4.3.1 and 1221 Section 8.4.3.2. 1223 o short identifier: a compact identifier assigned to the pledge. 1224 The short identifier structure is described in Section 8.4.4. The 1225 short identifier parameter MAY be included in a Configuration 1226 object. 1228 o JRC address: the IPv6 address of the JRC, encoded as a byte 1229 string, with the length of 16 bytes. If the length of the byte 1230 string is different from 16, the parameter MUST be discarded. If 1231 the JRC is not co-located with the 6LBR and has a different IPv6 1232 address than the 6LBR, this parameter MUST be included. In the 1233 special case where the JRC is co-located with the 6LBR and has the 1234 same IPv6 address as the 6LBR, this parameter MAY be included. If 1235 the JRC address parameter is not present in the Configuration 1236 object, this indicates that the JRC has the same IPv6 address as 1237 the 6LBR. The joined node can then discover the IPv6 address of 1238 the JRC through network control traffic. See Section 6. 1240 o blacklist: An array encompassing a list of pledge identifiers that 1241 are blacklisted by the JRC, with each pledge identifier encoded as 1242 a byte string. The blacklist parameter MAY be included in a 1243 Configuration object. When present, the array MUST contain zero 1244 or more byte strings encoding pledge identifiers. The joined node 1245 MUST silently drop any link-layer frames originating from the 1246 pledge identifiers enclosed in the blacklist parameter. When this 1247 parameter is received, its value MUST overwrite any previously set 1248 values. This parameter allows the JRC to configure the node 1249 acting as a JP to filter out traffic from misconfigured or 1250 malicious pledges before their traffic is forwarded into the 1251 network. If the JRC decides to remove a given pledge identifier 1252 from a blacklist, it omits the pledge identifier in the blacklist 1253 parameter value it sends next. 1255 o join rate: Average data rate of join traffic forwarded into the 1256 network that should not be exceeded when a joined node operates as 1257 a JP, encoded as an unsigned integer in bytes per second. The 1258 join rate parameter MAY be included in a Configuration object. 1259 This parameter allows the JRC to configure different nodes in the 1260 network to operate as JP, and act in case of an attack by 1261 throttling the rate at which JP forwards unauthenticated traffic 1262 into the network. When this parameter is present in a 1263 Configuration object, the value MUST be used to set the 1264 PROBING_RATE of CoAP at the joined node for communication with the 1265 JRC. In case this parameter is set to zero, a joined node MUST 1266 silently drop any join traffic coming from unauthenticated 1267 pledges. In case this parameter is omitted, the value of positive 1268 infinity SHOULD be assumed. Node operating as a JP MAY use 1269 another mechanism that is out of scope of this specification to 1270 configure PROBING_RATE of CoAP in the absence of join rate 1271 parameter from the Configuration object. 1273 The CDDL fragment that represents the text above for the 1274 Configuration follows. Structures Link_Layer_Key and 1275 Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. 1277 Configuration = { 1278 ? 2 : [ +Link_Layer_Key ], ; link-layer key set 1279 ? 3 : Short_Identifier, ; short identifier 1280 ? 4 : bstr, ; JRC address 1281 ? 6 : [ *bstr ], ; blacklist 1282 ? 7 : uint ; join rate 1283 } 1284 +---------------+-------+----------+-------------------+------------+ 1285 | Name | Label | CBOR | Description | Reference | 1286 | | | type | | | 1287 +---------------+-------+----------+-------------------+------------+ 1288 | role | 1 | unsigned | Identifies the | [[this | 1289 | | | integer | role parameter | document]] | 1290 | | | | | | 1291 | link-layer | 2 | array | Identifies the | [[this | 1292 | key set | | | array carrying | document]] | 1293 | | | | one or more link- | | 1294 | | | | level | | 1295 | | | | cryptographic | | 1296 | | | | keys | | 1297 | | | | | | 1298 | short | 3 | array | Identifies the | [[this | 1299 | identifier | | | assigned short | document]] | 1300 | | | | identifier | | 1301 | | | | | | 1302 | JRC address | 4 | byte | Identifies the | [[this | 1303 | | | string | IPv6 address of | document]] | 1304 | | | | the JRC | | 1305 | | | | | | 1306 | network | 5 | byte | Identifies the | [[this | 1307 | identifier | | string | network | document]] | 1308 | | | | identifier | | 1309 | | | | parameter | | 1310 | | | | | | 1311 | blacklist | 6 | array | Identifies the | [[this | 1312 | | | | blacklist | document]] | 1313 | | | | parameter | | 1314 | | | | | | 1315 | join rate | 7 | unsigned | Identifier the | [[this | 1316 | | | integer | join rate | document]] | 1317 | | | | parameter | | 1318 | | | | | | 1319 | unsupported | 8 | array | Identifies the | [[this | 1320 | configuration | | | unsupported | document]] | 1321 | | | | configuration | | 1322 | | | | parameter | | 1323 +---------------+-------+----------+-------------------+------------+ 1325 Table 2: CoJP parameters map labels. 1327 8.4.3. Link-Layer Key 1329 The Link_Layer_Key structure encompasses the parameters needed to 1330 configure the link-layer security module: the key identifier; the 1331 value of the cryptographic key; the link-layer algorithm identifier 1332 and the security level and the frame types that it should be used 1333 with, both for outgoing and incoming security operations; and any 1334 additional information that may be needed to configure the key. 1336 For encoding compactness, the Link_Layer_Key object is not enclosed 1337 in a top-level CBOR object. Rather, it is transported as a sequence 1338 of CBOR elements, some being optional. 1340 The set of parameters that can appear in a Link_Layer_Key object is 1341 summarized below, in order: 1343 o key_id: The identifier of the key, encoded as a CBOR unsigned 1344 integer. This parameter MUST be included. If the decoded CBOR 1345 unsigned integer value is larger than the maximum link-layer key 1346 identifier, the key is considered invalid. In case the key is 1347 considered invalid, the key MUST be discarded and the 1348 implementation MUST signal the error as specified in 1349 Section 8.3.1. 1351 o key_usage: The identifier of the link-layer algorithm, security 1352 level and link-layer frame types that can be used with the key, 1353 encoded as an integer. This parameter MAY be included. Possible 1354 values and the corresponding link-layer settings are specified in 1355 IANA "CoJP Key Usage" registry (Section 11.2). In case the 1356 parameter is omitted, the default value of 0 from Table 3 MUST be 1357 assumed. 1359 o key_value: The value of the cryptographic key, encoded as a byte 1360 string. This parameter MUST be included. If the length of the 1361 byte string is different than the corresponding key length for a 1362 given algorithm specified by the key_usage parameter, the key MUST 1363 be discarded and the implementation MUST signal the error as 1364 specified in Section 8.3.1. 1366 o key_addinfo: Additional information needed to configure the link- 1367 layer key, encoded as a byte string. This parameter MAY be 1368 included. The processing of this parameter is dependent on the 1369 link-layer technology in use and a particular keying mode. 1371 To be able to decode the keys that are present in the link-layer key 1372 set, and to identify individual parameters of a single Link_Layer_Key 1373 object, the CBOR decoder needs to differentiate between elements 1374 based on the CBOR type. For example, a uint that follows a byte 1375 string signals to the decoder that a new Link_Layer_Key object is 1376 being processed. 1378 The CDDL fragment that represents the text above for the 1379 Link_Layer_Key follows. 1381 Link_Layer_Key = ( 1382 key_id : uint, 1383 ? key_usage : int, 1384 key_value : bstr, 1385 ? key_addinfo : bstr, 1386 ) 1388 +-----------------+-----+------------------+-------------+----------+ 1389 | Name | Val | Algorithm | Description | Referenc | 1390 | | ue | | | e | 1391 +-----------------+-----+------------------+-------------+----------+ 1392 | 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | 1393 | -ENC-MIC32 | | CCM-128 | for EBs, | ocument] | 1394 | | | | ENC-MIC-32 | ] | 1395 | | | | for DATA | | 1396 | | | | and ACKNOWL | | 1397 | | | | EDGMENT. | | 1398 | | | | | | 1399 | 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | 1400 | -ENC-MIC64 | | CCM-128 | for EBs, | ocument] | 1401 | | | | ENC-MIC-64 | ] | 1402 | | | | for DATA | | 1403 | | | | and ACKNOWL | | 1404 | | | | EDGMENT. | | 1405 | | | | | | 1406 | 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | 1407 | -ENC-MIC128 | | CCM-128 | for EBs, | ocument] | 1408 | | | | ENC-MIC-128 | ] | 1409 | | | | for DATA | | 1410 | | | | and ACKNOWL | | 1411 | | | | EDGMENT. | | 1412 | | | | | | 1413 | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | 1414 | K1K2-MIC32 | | CCM-128 | for EBs, | ocument] | 1415 | | | | DATA and AC | ] | 1416 | | | | KNOWLEDGMEN | | 1417 | | | | T. | | 1418 | | | | | | 1419 | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | 1420 | K1K2-MIC64 | | CCM-128 | for EBs, | ocument] | 1421 | | | | DATA and AC | ] | 1422 | | | | KNOWLEDGMEN | | 1423 | | | | T. | | 1424 | | | | | | 1425 | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | 1426 | K1K2-MIC128 | | CCM-128 | for EBs, | ocument] | 1427 | | | | DATA and AC | ] | 1428 | | | | KNOWLEDGMEN | | 1429 | | | | T. | | 1430 | | | | | | 1431 | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | 1432 | | | CCM-128 | for EBs. | ocument] | 1433 | | | | | ] | 1434 | | | | | | 1435 | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | 1436 | | | CCM-128 | for EBs. | ocument] | 1437 | | | | | ] | 1438 | | | | | | 1439 | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | 1440 | 8 | | CCM-128 | for EBs. | ocument] | 1441 | | | | | ] | 1442 | | | | | | 1443 | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | 1444 | | | CCM-128 | for DATA | ocument] | 1445 | | | | and ACKNOWL | ] | 1446 | | | | EDGMENT. | | 1447 | | | | | | 1448 | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | 1449 | | | CCM-128 | for DATA | ocument] | 1450 | | | | and ACKNOWL | ] | 1451 | | | | EDGMENT. | | 1452 | | | | | | 1453 | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | 1454 | 8 | | CCM-128 | for DATA | ocument] | 1455 | | | | and ACKNOWL | ] | 1456 | | | | EDGMENT. | | 1457 | | | | | | 1458 | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | 1459 | MIC32 | | CCM-128 | MIC-32 for | ocument] | 1460 | | | | DATA and AC | ] | 1461 | | | | KNOWLEDGMEN | | 1462 | | | | T. | | 1463 | | | | | | 1464 | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | 1465 | MIC64 | | CCM-128 | MIC-64 for | ocument] | 1466 | | | | DATA and AC | ] | 1467 | | | | KNOWLEDGMEN | | 1468 | | | | T. | | 1469 | | | | | | 1470 | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | 1471 | MIC128 | | CCM-128 | MIC-128 for | ocument] | 1472 | | | | DATA and AC | ] | 1473 | | | | KNOWLEDGMEN | | 1474 | | | | T. | | 1475 +-----------------+-----+------------------+-------------+----------+ 1476 Table 3: Key Usage values. 1478 8.4.3.1. Rekeying of (6LoWPAN) Border Routers (6LBR) 1480 When the 6LoWPAN Border Router (6LBR) receives the Configuration 1481 object containing a link-layer key set, it MUST immediately install 1482 and start using the new keys for all outgoing traffic, and remove any 1483 old keys it has installed from the previous key set after a delay of 1484 COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the 1485 JRC to force the 6LBR to start sending traffic with the new key. The 1486 decision is taken by the JRC when it has determined that the new key 1487 has been made available to all (or some overwhelming majority) of 1488 nodes. Any node that the JRC has not yet reached at that point is 1489 either non-functional or in extended sleep such that it will not be 1490 reached. To get the key update, such node needs to go through the 1491 join process anew. 1493 8.4.3.2. Rekeying of regular (6LoWPAN) Nodes (6LN) 1495 When a regular 6LN node receives the Configuration object with a 1496 link-layer key set, it MUST install the new keys. The 6LN will use 1497 both the old and the new keys to decrypt and authenticate any 1498 incoming traffic that arrives based upon the key identifier in the 1499 packet. It MUST continue to use the old keys for all outgoing 1500 traffic until it has detected that the network has switched to the 1501 new key set. 1503 The detection of network switch is based upon the receipt of traffic 1504 secured with the new keys. Upon reception and successful security 1505 processing of a link-layer frame secured with a key from the new key 1506 set, a 6LN node MUST then switch to sending outgoing traffic using 1507 the keys from the new set for all outgoing traffic. The 6LN node 1508 MUST remove any old keys it has installed from the previous key set 1509 after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts 1510 using the new key set. 1512 Sending of traffic with the new keys signals to other downstream 1513 nodes to switch to their new key, and the affect is that there is a 1514 ripple of key updates in outward concentric circles around each 6LBR. 1516 8.4.3.3. Use in IEEE Std 802.15.4 1518 When Link_Layer_Key is used in the context of [IEEE802.15.4], the 1519 following considerations apply. 1521 Signaling of different keying modes of [IEEE802.15.4] is done based 1522 on the parameter values present in a Link_Layer_Key object. 1524 o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be 1525 set to 0. key_addinfo parameter MUST be present. key_addinfo 1526 parameter MUST be set to the link-layer address(es) of a single 1527 peer with whom the key should be used. Depending on the 1528 configuration of the network, key_addinfo may carry the peer's 1529 long link-layer address (i.e. pledge identifier), short link-layer 1530 address, or their concatenation with the long address being 1531 encoded first. Which address is carried is determined from the 1532 length of the byte string. 1534 o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a 1535 value different than 0. key_addinfo parameter MUST NOT be 1536 present. 1538 o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter 1539 MUST be set to a value different than 0. key_addinfo parameter 1540 MUST be present. key_addinfo parameter MUST be set to a byte 1541 string, exactly 4 bytes long. key_addinfo parameter carries the 1542 Key Source parameter used to configure [IEEE802.15.4]. 1544 o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter 1545 MUST be set to a value different than 0. key_addinfo parameter 1546 MUST be present. key_addinfo parameter MUST be set to a byte 1547 string, exactly 8 bytes long. key_addinfo parameter carries the 1548 Key Source parameter used to configure [IEEE802.15.4]. 1550 In all cases, key_usage parameter determines how a particular key 1551 should be used in respect to incoming and outgoing security policies. 1553 For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" 1554 parameter of [IEEE802.15.4] that is signaled in all outgoing frames 1555 secured with a given key. The maximum value key_id can have is 254. 1556 The value of 255 is reserved in [IEEE802.15.4] and is therefore 1557 considered invalid. 1559 Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a 1560 trusted third party and assign pairwise keys between nodes in the 1561 network. How JRC learns about the network topology is out of scope 1562 of this specification, but could be done through 6LBR - JRC signaling 1563 for example. Pairwise keys could also be derived through a key 1564 agreement protocol executed between the peers directly, where the 1565 authentication is based on the symmetric cryptographic material 1566 provided to both peers by the JRC. Such a protocol is out of scope 1567 of this specification. 1569 Implementations MUST use different link-layer keys when using 1570 different authentication tag (MIC) lengths, as using the same key 1571 with different authentication tag lengths might be unsafe. For 1572 example, this prohibits the usage of the same key for both MIC-32 and 1573 MIC-64 levels. See Annex B.4.3 of [IEEE802.15.4] for more 1574 information. 1576 8.4.4. Short Identifier 1578 The Short_Identifier object represents an identifier assigned to the 1579 pledge. It is encoded as a CBOR array object, containing, in order: 1581 o identifier: The short identifier assigned to the pledge, encoded 1582 as a byte string. This parameter MUST be included. The 1583 identifier MUST be unique in the set of all identifiers assigned 1584 in a network that is managed by a JRC. In case the identifier is 1585 invalid, the decoder MUST silently ignore the Short_Identifier 1586 object. 1588 o lease_time: The validity of the identifier in hours after the 1589 reception of the CBOR object, encoded as a CBOR unsigned integer. 1590 This parameter MAY be included. The node MUST stop using the 1591 assigned short identifier after the expiry of the lease_time 1592 interval. It is up to the JRC to renew the lease before the 1593 expiry of the previous interval. The JRC updates the lease by 1594 executing the Parameter Update exchange with the node and 1595 including the Short_Identifier in the Configuration object, as 1596 described in Section 8.2. In case the lease expires, the node 1597 SHOULD initiate a new join exchange, as described in Section 8.1. 1598 In case this parameter is omitted, the value of positive infinity 1599 MUST be assumed, meaning that the identifier is valid for as long 1600 as the node participates in the network. 1602 The CDDL fragment that represents the text above for the 1603 Short_Identifier follows. 1605 Short_Identifier = [ 1606 identifier : bstr, 1607 ? lease_time : uint 1608 ] 1610 8.4.4.1. Use in IEEE Std 802.15.4 1612 When Short_Identifier is used in the context of [IEEE802.15.4], the 1613 following considerations apply. 1615 The identifier MUST be used to set the short address of IEEE Std 1616 802.15.4 module. When operating in TSCH mode, the identifier MUST be 1617 unique in the set of all identifiers assigned in multiple networks 1618 that share link-layer key(s). If the length of the byte string 1619 corresponding to the identifier parameter is different than 2, the 1620 identifier is considered invalid. The values 0xfffe and 0xffff are 1621 reserved by [IEEE802.15.4] and their use is considered invalid. 1623 The security properties offered by the [IEEE802.15.4] link-layer in 1624 TSCH mode are conditioned on the uniqueness requirement of the short 1625 identifier (i.e. short address). The short address is one of the 1626 inputs in the construction of the nonce, which is used to protect 1627 link-layer frames. If a misconfiguration occurs, and the same short 1628 address is assigned twice under the same link-layer key, the loss of 1629 security properties is eminent. For this reason, practices where the 1630 pledge generates the short identifier locally are not safe and are 1631 likely to result in the loss of link-layer security properties. 1633 The JRC MUST ensure that at any given time there are never two same 1634 short identifiers being used under the same link-layer key. If the 1635 lease_time parameter of a given Short_Identifier object is set to 1636 positive infinity, care needs to be taken that the corresponding 1637 identifier is not assigned to another node until the JRC is certain 1638 that it is no longer in use, potentially through out-of-band 1639 signaling. If the lease_time parameter expires for any reason, the 1640 JRC should take into consideration potential ongoing transmissions by 1641 the joined node, which may be hanging in the queues, before assigning 1642 the same identifier to another node. 1644 8.4.5. Unsupported Configuration Object 1646 The Unsupported_Configuration object is encoded as a CBOR array, 1647 containing at least one Unsupported_Parameter object. Each 1648 Unsupported_Parameter object is a sequence of CBOR elements without 1649 an enclosing top-level CBOR object for compactness. The set of 1650 parameters that appear in an Unsupported_Parameter object is 1651 summarized below, in order: 1653 o code: Indicates the capability of acting on the parameter signaled 1654 by parameter_label, encoded as an integer. This parameter MUST be 1655 included. Possible values of this parameter are specified in the 1656 IANA "CoJP Unsupported Configuration Code Registry" 1657 (Section 11.3). 1659 o parameter_label: Indicates the parameter. This parameter MUST be 1660 included. Possible values of this parameter are specified in the 1661 label column of the IANA "CoJP Parameters" registry 1662 (Section 11.1). 1664 o parameter_addinfo: Additional information about the parameter that 1665 cannot be acted upon. This parameter MUST be included. In case 1666 the code is set to "Unsupported", parameter_addinfo gives 1667 additional information to the JRC. If the parameter indicated by 1668 parameter_label cannot be acted upon regardless of its value, 1669 parameter_addinfo MUST be set to null, signaling to the JRC that 1670 it SHOULD NOT attempt to configure the parameter again. If the 1671 pledge can act on the parameter, but cannot configure the setting 1672 indicated by the parameter value, the pledge can hint this to the 1673 JRC. In this case, parameter_addinfo MUST be set to the value of 1674 the parameter that cannot be acted upon following the normative 1675 parameter structure specified in this document. For example, it 1676 is possible to include only a subset of the link-layer key set 1677 object, signaling the keys that cannot be acted upon, or the 1678 entire key set that was received. In case the code is set to 1679 "Malformed", parameter_addinfo MUST be set to null, signaling to 1680 the JRC that it SHOULD NOT attempt to configure the parameter 1681 again. 1683 The CDDL fragment that represents the text above for 1684 Unsupported_Configuration and Unsupported_Parameter objects follows. 1686 Unsupported_Configuration = [ 1687 + parameter : Unsupported_Parameter 1688 ] 1690 Unsupported_Parameter = ( 1691 code : int, 1692 parameter_label : int, 1693 parameter_addinfo : nil / any 1694 ) 1696 +-------------+-------+--------------------------------+------------+ 1697 | Name | Value | Description | Reference | 1698 +-------------+-------+--------------------------------+------------+ 1699 | Unsupported | 0 | The indicated setting is not | [[this | 1700 | | | supported by the networking | document]] | 1701 | | | stack implementation. | | 1702 | | | | | 1703 | Malformed | 1 | The indicated parameter value | [[this | 1704 | | | is malformed. | document]] | 1705 +-------------+-------+--------------------------------+------------+ 1707 Table 4: Unsupported Configuration code values. 1709 8.5. Recommended Settings 1711 This section gives RECOMMENDED values of CoJP settings. 1713 +--------------------------+---------------+ 1714 | Name | Default Value | 1715 +--------------------------+---------------+ 1716 | COJP_MAX_JOIN_ATTEMPTS | 4 | 1717 | | | 1718 | COJP_REKEYING_GUARD_TIME | 12 seconds | 1719 +--------------------------+---------------+ 1721 Recommended CoJP settings. 1723 The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible 1724 retransmissions at the link layer due to imperfect wireless links. 1726 9. Security Considerations 1728 Since this document uses the pledge identifier to set the ID Context 1729 parameter of OSCORE, an important security requirement is that the 1730 pledge identifier is unique in the set of all pledge identifiers 1731 managed by a JRC. The uniqueness of the pledge identifier ensures 1732 unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also 1733 allows the JRC to retrieve the correct security context, upon the 1734 reception of a Join Request message. The management of pledge 1735 identifiers is simplified if the globally unique EUI-64 is used, but 1736 this comes with privacy risks, as discussed in Section 10. 1738 This document further mandates that the (6LBR) pledge and the JRC are 1739 provisioned with unique PSKs. The PSK is used to set the OSCORE 1740 Master Secret during security context derivation. This derivation 1741 process results in OSCORE keys that are important for mutual 1742 authentication of the (6LBR) pledge and the JRC. Should an attacker 1743 come to know the PSK, then a man-in-the-middle attack is possible. 1745 Many vendors are known to use unsafe practices when generating and 1746 provisioning PSKs. The use of a single PSK shared among a group of 1747 devices is a common pitfall that results in poor security. In this 1748 case, the compromise of a single device is likely to lead to a 1749 compromise of the entire batch, with the attacker having the ability 1750 to impersonate a legitimate device and join the network, generate 1751 bogus data and disturb the network operation. As a reminder, recall 1752 the well-known problem with Bluetooth headsets with a "0000" pin. 1753 Additionally, some vendors use methods such as scrambling or hashing 1754 of device serial numbers or their EUI-64 to generate "unique" PSKs. 1755 Without any secret information involved, the effort that the attacker 1756 needs to invest into breaking these unsafe derivation methods is 1757 quite low, resulting in the possible impersonation of any device from 1758 the batch, without even needing to compromise a single device. The 1759 use of cryptographically secure random number generators to generate 1760 the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms 1761 using deterministic methods. 1763 The JP forwards the unauthenticated join traffic into the network. A 1764 data cap on the JP prevents it from forwarding more traffic than the 1765 network can handle. The data cap can be configured by the JRC by 1766 including a join rate parameter in the Join Response and it is 1767 implemented through the CoAP's PROBING_RATE setting. The use of a 1768 data cap at a JP forces attackers to use more than one JP if they 1769 wish to overwhelm the network. Marking the join traffic packets with 1770 a non-zero DSCP allows the network to carry the traffic if it has 1771 capacity, but encourages the network to drop the extra traffic rather 1772 than add bandwidth due to that traffic. 1774 The shared nature of the "minimal" cell used for the join traffic 1775 makes the network prone to a DoS attack by congesting the JP with 1776 bogus traffic. Such an attacker is limited by its maximum transmit 1777 power. The redundancy in the number of deployed JPs alleviates the 1778 issue and also gives the pledge a possibility to use the best 1779 available link for joining. How a network node decides to become a 1780 JP is out of scope of this specification. 1782 At the beginning of the join process, the pledge has no means of 1783 verifying the content in the EB, and has to accept it at "face 1784 value". In case the pledge tries to join an attacker's network, the 1785 Join Response message will either fail the security check or time 1786 out. The pledge may implement a temporary blacklist in order to 1787 filter out undesired EBs and try to join using the next seemingly 1788 valid EB. This blacklist alleviates the issue, but is effectively 1789 limited by the node's available memory. Note that this temporary 1790 blacklist is different from the one communicated as part of the CoJP 1791 Configuration object as it helps pledge fight a DoS attack. These 1792 bogus beacons prolong the join time of the pledge, and so the time 1793 spent in "minimal" [RFC8180] duty cycle mode. The blacklist 1794 communicated as part of the CoJP Configuration object helps JP fight 1795 a DoS attack by a malicious pledge. 1797 10. Privacy Considerations 1799 The join solution specified in this document relies on the uniqueness 1800 of the pledge identifier in the set of all pledge identifiers managed 1801 by a JRC. This identifier is transferred in clear as an OSCORE kid 1802 context. The use of the globally unique EUI-64 as pledge identifier 1803 simplifies the management but comes with certain privacy risks. The 1804 implications are thoroughly discussed in [RFC7721] and comprise 1805 correlation of activities over time, location tracking, address 1806 scanning and device-specific vulnerability exploitation. Since the 1807 join process occurs rarely compared to the network lifetime, long- 1808 term threats that arise from using EUI-64 as the pledge identifier 1809 are minimal. In addition, the Join Response message contains a short 1810 address which is assigned by the JRC to the (6LBR) pledge. The 1811 assigned short address SHOULD be uncorrelated with the long-term 1812 pledge identifier. The short address is encrypted in the response. 1813 Once the join process completes, the new node uses the short 1814 addresses for all further layer 2 (and layer-3) operations. This 1815 reduces the aforementioned privacy risks as the short layer-2 address 1816 (visible even when the network is encrypted) is not traceable between 1817 locations and does not disclose the manufacturer, as is the case of 1818 EUI-64. However, an eavesdropper with access to the radio medium 1819 during the join process may be able to correlate the assigned short 1820 address with the extended address based on timing information with a 1821 non-negligible probability. This probability decreases with an 1822 increasing number of pledges joining concurrently. 1824 11. IANA Considerations 1826 Note to RFC Editor: Please replace all occurrences of "[[this 1827 document]]" with the RFC number of this specification. 1829 This document allocates a well-known name under the .arpa name space 1830 according to the rules given in [RFC3172]. The name "6tisch.arpa" is 1831 requested. No subdomains are expected. No A, AAAA or PTR record is 1832 requested. 1834 11.1. CoJP Parameters Registry 1836 This section defines a sub-registry within the "IPv6 over the TSCH 1837 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1838 "Constrained Join Protocol Parameters Registry". 1840 The columns of the registry are: 1842 Name: This is a descriptive name that enables an easier reference to 1843 the item. It is not used in the encoding. 1845 Label: The value to be used to identify this parameter. The label is 1846 an integer. 1848 CBOR type: This field contains the CBOR type for the field. 1850 Description: This field contains a brief description for the field. 1852 Reference: This field contains a pointer to the public specification 1853 for the field, if one exists. 1855 This registry is to be populated with the values in Table 2. 1857 The amending formula for this sub-registry is: Different ranges of 1858 values use different registration policies [RFC8126]. Integer values 1859 from -256 to 255 are designated as Standards Action. Integer values 1860 from -65536 to -257 and from 256 to 65535 are designated as 1861 Specification Required. Integer values greater than 65535 are 1862 designated as Expert Review. Integer values less than -65536 are 1863 marked as Private Use. 1865 11.2. CoJP Key Usage Registry 1867 This section defines a sub-registry within the "IPv6 over the TSCH 1868 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1869 "Constrained Join Protocol Key Usage Registry". 1871 The columns of this registry are: 1873 Name: This is a descriptive name that enables easier reference to the 1874 item. The name MUST be unique. It is not used in the encoding. 1876 Value: This is the value used to identify the key usage setting. 1877 These values MUST be unique. The value is an integer. 1879 Algorithm: This is a descriptive name of the link-layer algorithm in 1880 use and uniquely determines the key length. The name is not used in 1881 the encoding. 1883 Description: This field contains a description of the key usage 1884 setting. The field should describe in enough detail how the key is 1885 to be used with different frame types, specific for the link-layer 1886 technology in question. 1888 Reference: This contains a pointer to the public specification for 1889 the field, if one exists. 1891 This registry is to be populated with the values in Table 3. 1893 The amending formula for this sub-registry is: Different ranges of 1894 values use different registration policies [RFC8126]. Integer values 1895 from -256 to 255 are designated as Standards Action. Integer values 1896 from -65536 to -257 and from 256 to 65535 are designated as 1897 Specification Required. Integer values greater than 65535 are 1898 designated as Expert Review. Integer values less than -65536 are 1899 marked as Private Use. 1901 11.3. CoJP Unsupported Configuration Code Registry 1903 This section defines a sub-registry within the "IPv6 over the TSCH 1904 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1905 "Constrained Join Protocol Unsupported Configuration Code Registry". 1907 The columns of this registry are: 1909 Name: This is a descriptive name that enables easier reference to the 1910 item. The name MUST be unique. It is not used in the encoding. 1912 Value: This is the value used to identify the diagnostic code. These 1913 values MUST be unique. The value is an integer. 1915 Description: This is a descriptive human-readable name. The 1916 description MUST be unique. It is not used in the encoding. 1918 Reference: This contains a pointer to the public specification for 1919 the field, if one exists. 1921 This registry is to be populated with the values in Table 4. 1923 The amending formula for this sub-registry is: Different ranges of 1924 values use different registration policies [RFC8126]. Integer values 1925 from -256 to 255 are designated as Standards Action. Integer values 1926 from -65536 to -257 and from 256 to 65535 are designated as 1927 Specification Required. Integer values greater than 65535 are 1928 designated as Expert Review. Integer values less than -65536 are 1929 marked as Private Use. 1931 12. Acknowledgments 1933 The work on this document has been partially supported by the 1934 European Union's H2020 Programme for research, technological 1935 development and demonstration under grant agreements: No 644852, 1936 project ARMOUR; No 687884, project F-Interop and open-call project 1937 SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA. 1939 The following individuals provided input to this document (in 1940 alphabetic order): Christian Amsuss, Tengfei Chang, Klaus Hartke, 1941 Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal 1942 Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne. 1944 13. References 1945 13.1. Normative References 1947 [I-D.ietf-core-object-security] 1948 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1949 "Object Security for Constrained RESTful Environments 1950 (OSCORE)", draft-ietf-core-object-security-16 (work in 1951 progress), March 2019. 1953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1954 Requirement Levels", BCP 14, RFC 2119, 1955 DOI 10.17487/RFC2119, March 1997, 1956 . 1958 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1959 "Assured Forwarding PHB Group", RFC 2597, 1960 DOI 10.17487/RFC2597, June 1999, 1961 . 1963 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1964 Requirements for the Address and Routing Parameter Area 1965 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1966 September 2001, . 1968 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1969 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1970 October 2013, . 1972 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1973 Application Protocol (CoAP)", RFC 7252, 1974 DOI 10.17487/RFC7252, June 2014, 1975 . 1977 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1978 Writing an IANA Considerations Section in RFCs", BCP 26, 1979 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1980 . 1982 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1983 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1984 . 1986 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1987 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1988 May 2017, . 1990 13.2. Informative References 1992 [I-D.ietf-6tisch-architecture] 1993 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1994 of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work 1995 in progress), July 2019. 1997 [I-D.ietf-6tisch-terminology] 1998 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1999 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 2000 draft-ietf-6tisch-terminology-10 (work in progress), March 2001 2018. 2003 [I-D.ietf-cbor-cddl] 2004 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 2005 definition language (CDDL): a notational convention to 2006 express CBOR and JSON data structures", draft-ietf-cbor- 2007 cddl-08 (work in progress), March 2019. 2009 [I-D.ietf-core-stateless] 2010 Hartke, K., "Extended Tokens and Stateless Clients in the 2011 Constrained Application Protocol (CoAP)", draft-ietf-core- 2012 stateless-01 (work in progress), March 2019. 2014 [IEEE802.15.4] 2015 IEEE standard for Information Technology, ., "IEEE Std 2016 802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 2018 [NIST800-90A] 2019 NIST Special Publication 800-90A, Revision 1, ., Barker, 2020 E., and J. Kelsey, "Recommendation for Random Number 2021 Generation Using Deterministic Random Bit Generators", 2022 2015. 2024 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 2025 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 2026 RFC 4231, DOI 10.17487/RFC4231, December 2005, 2027 . 2029 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2030 "Transmission of IPv6 Packets over IEEE 802.15.4 2031 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2032 . 2034 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2035 Key Derivation Function (HKDF)", RFC 5869, 2036 DOI 10.17487/RFC5869, May 2010, 2037 . 2039 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2040 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2041 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2042 Low-Power and Lossy Networks", RFC 6550, 2043 DOI 10.17487/RFC6550, March 2012, 2044 . 2046 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 2047 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 2048 Internet of Things (IoT): Problem Statement", RFC 7554, 2049 DOI 10.17487/RFC7554, May 2015, 2050 . 2052 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2053 Considerations for IPv6 Address Generation Mechanisms", 2054 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2055 . 2057 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2058 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2059 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2060 May 2017, . 2062 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 2063 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 2064 DOI 10.17487/RFC8480, November 2018, 2065 . 2067 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2068 Perkins, "Registration Extensions for IPv6 over Low-Power 2069 Wireless Personal Area Network (6LoWPAN) Neighbor 2070 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2071 . 2073 Appendix A. Example 2075 Figure 3 illustrates a successful join protocol exchange. The pledge 2076 instantiates the OSCORE context and derives the OSCORE keys and 2077 nonces from the PSK. It uses the instantiated context to protect the 2078 Join Request addressed with a Proxy-Scheme option, the well-known 2079 host name of the JRC in the Uri-Host option, and its EUI-64 as pledge 2080 identifier and OSCORE kid context. Triggered by the presence of a 2081 Proxy-Scheme option, the JP forwards the request to the JRC and sets 2082 the CoAP token to the internally needed state. The JP has learned 2083 the IPv6 address of the JRC when it acted as a pledge and joined the 2084 network. Once the JRC receives the request, it looks up the correct 2085 context based on the kid context parameter. The OSCORE data 2086 authenticity verification ensures that the request has not been 2087 modified in transit. In addition, replay protection is ensured 2088 through persistent handling of mutable context parameters. 2090 Once the JP receives the Join Response, it authenticates the state 2091 within the CoAP token before deciding where to forward. The JP sets 2092 its internal state to that found in the token, and forwards the Join 2093 Response to the correct pledge. Note that the JP does not possess 2094 the key to decrypt the CBOR object (configuration) present in the 2095 payload. The Join Response is matched to the Join Request and 2096 verified for replay protection at the pledge using OSCORE processing 2097 rules. In this example, the Join Response does not contain the IPv6 2098 address of the JRC, the pledge hence understands the JRC is co- 2099 located with the 6LBR. 2101 <---E2E OSCORE--> 2102 Client Proxy Server 2103 Pledge JP JRC 2104 | | | 2105 | Join | | Code: 0.02 (POST) 2106 | Request | | Token: - 2107 +--------->| | Proxy-Scheme: coap 2108 | | | Uri-Host: 6tisch.arpa 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 | | Join | Code: 0.02 (POST) 2117 | | Request | Token: opaque state 2118 | +--------->| OSCORE: kid: -, 2119 | | | kid_context: EUI-64, 2120 | | | Partial IV: 1 2121 | | | Payload: { Code: 0.02 (POST), 2122 | | | Uri-Path: "j", 2123 | | | join_request, } 2124 | | | 2125 | | | 2126 | | Join | Code: 2.04 (Changed) 2127 | | Response | Token: opaque state 2128 | |<---------+ OSCORE: - 2129 | | | Payload: { Code: 2.04 (Changed), 2130 | | | configuration, } 2131 | | | 2132 | | | 2133 | Join | | Code: 2.04 (Changed) 2134 | Response | | Token: - 2135 |<---------+ | OSCORE: - 2136 | | | Payload: { Code: 2.04 (Changed), 2137 | | | configuration, } 2138 | | | 2140 Figure 3: Example of a successful join protocol exchange. { ... } 2141 denotes authenticated encryption, denotes the authentication 2142 tag. 2144 Where the join_request object is: 2146 join_request: 2147 { 2148 5 : h'cafe' / PAN ID of the network pledge is attempting to join / 2149 } 2151 Since the role parameter is not present, the default role of "6TiSCH 2152 Node" is implied. 2154 The join_request object encodes to h'a10542cafe' with a size of 5 2155 bytes. 2157 And the configuration object is: 2159 configuration: 2160 { 2161 2 : [ / link-layer key set / 2162 1, / key_id / 2163 h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / 2164 ], 2165 3 : [ / short identifier / 2166 h'af93' / assigned short address / 2167 ] 2168 } 2170 Since the key_usage parameter is not present in the link-layer key 2171 set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. 2172 Since key_addinfo parameter is not present and key_id is different 2173 than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since 2174 the lease_time parameter is not present in the short identifier 2175 object, the default value of positive infinity is implied. 2177 The configuration object encodes to 2179 h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size 2180 of 26 bytes. 2182 Appendix B. Lightweight Implementation Option 2184 In environments where optimizing the implementation footprint is 2185 important, it is possible to implement this specification without 2186 having the implementations of HKDF [RFC5869] and SHA [RFC4231] on 2187 constrained devices. HKDF and SHA are used during the OSCORE 2188 security context derivation phase. This derivation can also be done 2189 by the JRC or a provisioning device, on behalf of the (6LBR) pledge 2190 during the provisioning phase. In that case, the derived OSCORE 2191 security context parameters are written directly into the (6LBR) 2192 pledge, without requiring the PSK be provisioned to the (6LBR) 2193 pledge. 2195 The use of HKDF to derive OSCORE security context parameters ensures 2196 that the resulting OSCORE keys have good security properties, and are 2197 unique as long as the input for different pledges varies. This 2198 specification ensures the uniqueness by mandating unique pledge 2199 identifiers and a unique PSK for each (6LBR) pledge. From the AEAD 2200 nonce reuse viewpoint, having a unique pledge identifier is a 2201 sufficient condition. However, as discussed in Section 9, the use of 2202 a single PSK shared among many devices is a common security pitfall. 2203 The compromise of this shared PSK on a single device would lead to 2204 the compromise of the entire batch. When using the implementation/ 2205 deployment scheme outlined above, the PSK does not need to be written 2206 to individual pledges. As a consequence, even if a shared PSK is 2207 used, the scheme offers the same level of security as in the scenario 2208 where each pledge is provisioned with a unique PSK. 2210 Authors' Addresses 2212 Malisa Vucinic (editor) 2213 Inria 2214 2 Rue Simone Iff 2215 Paris 75012 2216 France 2218 Email: malisa.vucinic@inria.fr 2220 Jonathan Simon 2221 Analog Devices 2222 32990 Alvarado-Niles Road, Suite 910 2223 Union City, CA 94587 2224 USA 2226 Email: jonathan.simon@analog.com 2228 Kris Pister 2229 University of California Berkeley 2230 512 Cory Hall 2231 Berkeley, CA 94720 2232 USA 2234 Email: pister@eecs.berkeley.edu 2235 Michael Richardson 2236 Sandelman Software Works 2237 470 Dawson Avenue 2238 Ottawa, ON K1Z5V7 2239 Canada 2241 Email: mcr+ietf@sandelman.ca