idnits 2.17.1 draft-ietf-6tisch-minimal-security-08.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 (November 08, 2018) is 1996 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-15 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-05 Summary: 2 errors (**), 0 flaws (~~), 5 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: May 12, 2019 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 November 08, 2018 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-08 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 May 12, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. 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 6. Network-layer Configuration . . . . . . . . . . . . . . . . . 11 77 6.1. Identification of Unauthenticated Traffic . . . . . . . . 12 78 7. Application-level Configuration . . . . . . . . . . . . . . . 13 79 7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 13 80 7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 14 81 7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 18 83 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 19 84 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 20 85 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 22 86 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24 87 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 35 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 89 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 90 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 91 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 38 92 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 39 93 11.3. CoJP Error Registry . . . . . . . . . . . . . . . . . . 39 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 96 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 97 13.2. Informative References . . . . . . . . . . . . . . . . . 41 98 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 43 99 Appendix B. Lightweight Implementation Option . . . . . . . . . 46 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 102 1. Introduction 104 This document defines a "secure join" solution for a new device, 105 called "pledge", to securely join a 6TiSCH network. The term "secure 106 join" refers to network access authentication, authorization and 107 parameter distribution, as defined in [I-D.ietf-6tisch-terminology]. 108 The Constrained Join Protocol (CoJP) defined in this document handles 109 parameter distribution needed for a pledge to become a joined node. 110 Authorization mechanisms are considered out of scope. Mutual 111 authentication during network access is achieved through the use of a 112 secure channel, as configured by this document. This document also 113 specifies a configuration of different layers of the 6TiSCH protocol 114 stack that reduces the Denial of Service (DoS) attack surface during 115 the join process. 117 This document presumes a 6TiSCH network as described by [RFC7554] and 118 [RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their 119 radio turned off most of the time, to conserve energy. As a 120 consequence, the link used by a new device for joining the network 121 has limited bandwidth [RFC8180]. The secure join solution defined in 122 this document therefore keeps the number of over-the-air exchanges to 123 a minimum. 125 The micro-controllers at the heart of 6TiSCH nodes have a small 126 amount of code memory. It is therefore paramount to reuse existing 127 protocols available as part of the 6TiSCH stack. At the application 128 layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web 129 transfer, and on OSCORE [I-D.ietf-core-object-security] for its end- 130 to-end security. The secure join solution defined in this document 131 therefore reuses those two protocols as its building blocks. 133 CoJP is a generic protocol that can be used as-is in all modes of 134 IEEE Std 802.15.4, including the Time-Slotted Channel Hopping (TSCH) 135 mode 6TiSCH is based on. CoJP may as well be used in other (low- 136 power) networking technologies where efficiency in terms of 137 communication overhead and code footprint is important. In such a 138 case, it may be necessary to define configuration parameters specific 139 to the technology in question, through companion documents. The 140 overall process described in Section 4 and the configuration of the 141 stack is specific to 6TiSCH. 143 CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a 144 central entity. The configuration defined in this document assumes 145 that the pledge and the JRC share a secret cryptographic key, called 146 PSK (pre-shared key). The PSK is used to configure OSCORE to provide 147 a secure channel to CoJP. How the PSK is installed is out of scope 148 of this document: this may happen during the provisioning phase or by 149 a key exchange protocol that may precede the execution of CoJP. 151 When the pledge seeks admission to a 6TiSCH network, it first 152 synchronizes to it, by initiating the passive scan defined in 153 [IEEE802.15.4]. The pledge then exchanges CoJP messages with the 154 JRC; these messages can be forwarded by nodes already part of the 155 6TiSCH network, called Join Proxies. The messages exchanged allow 156 the JRC and the pledge to mutually authenticate, based on the 157 properties provided by OSCORE. They also allow the JRC to configure 158 the pledge with link-layer keying material, short identifier and 159 other parameters. After this secure join process successfully 160 completes, the joined node can interact with its neighbors to request 161 additional bandwidth using the 6top Protocol [RFC8480] and start 162 sending application traffic. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in 169 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 The reader is expected to be familiar with the terms and concepts 173 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 174 [I-D.ietf-core-object-security], and [RFC8152]. 176 The specification also includes a set of informative specifications 177 using the Concise data definition language (CDDL) 178 [I-D.ietf-cbor-cddl]. 180 The following terms defined in [I-D.ietf-6tisch-terminology] are used 181 extensively throughout this document: 183 o pledge 185 o joined node 187 o join proxy (JP) 189 o join registrar/coordinator (JRC) 190 o enhanced beacon (EB) 192 o join protocol 194 o join process 196 The following terms defined in [RFC6775] are also used throughout 197 this document: 199 o 6LoWPAN Border Router (6LBR) 201 The term "6LBR" is used interchangeably with the term "DODAG root" 202 defined in [RFC6550], assuming the two entities are co-located, as 203 recommended by [I-D.ietf-6tisch-architecture]. 205 The term "pledge", as used throughout the document, explicitly 206 denotes non-6LBR devices attempting to join the network using their 207 IEEE Std 802.15.4 network interface. The device that attempts to 208 join as the 6LBR of the network and does so over another network 209 interface is explicitly denoted as the "6LBR pledge". When the text 210 equally applies to the pledge and the 6LBR pledge, the "(6LBR) 211 pledge" form is used. 213 In addition, we use generic terms "pledge identifier" and "network 214 identifier". See Section 3. 216 The terms "secret key" and "symmetric key" are used interchangeably. 218 3. Provisioning Phase 220 The (6LBR) pledge is provisioned with certain parameters before 221 attempting to join the network, and the same parameters are 222 provisioned to the JRC. There are many ways by which this 223 provisioning can be done. Physically, the parameters can be written 224 into the (6LBR) pledge using a number of mechanisms, such as a JTAG 225 interface, a serial (craft) console interface, pushing buttons 226 simultaneously on different devices, over-the-air configuration in a 227 Faraday cage, etc. The provisioning can be done by the vendor, the 228 manufacturer, the integrator, etc. 230 Details of how this provisioning is done is out of scope of this 231 document. What is assumed is that there can be a secure, private 232 conversation between the JRC and the (6LBR) pledge, and that the two 233 devices can exchange the parameters. 235 Parameters that are provisioned to the (6LBR) pledge include: 237 o pledge identifier. The pledge identifier identifies the (6LBR) 238 pledge. The pledge identifier MUST be unique in the set of all 239 pledge identifiers managed by a JRC. The pledge identifier 240 uniqueness is an important security requirement, as discussed in 241 Section 9. The pledge identifier is typically the globally unique 242 64-bit Extended Unique Identifier (EUI-64) of the IEEE Std 243 802.15.4 device, in which case it is provisioned by the hardware 244 manufacturer. The pledge identifier is used to generate the IPv6 245 addresses of the (6LBR) pledge and to identify it during the 246 execution of the join protocol. For privacy reasons (see 247 Section 10), it is possible to use a pledge identifier different 248 from the EUI-64. For example, a pledge identifier may be a random 249 byte string, but care needs to be taken that such a string meets 250 the uniqueness requirement. 252 o Pre-Shared Key (PSK). A secret cryptographic key shared between 253 the (6LBR) pledge and the JRC. The JRC additionally needs to 254 store the pledge identifier bound to the given PSK. Each (6LBR) 255 pledge MUST be provisioned with a unique PSK. The PSK SHOULD be a 256 cryptographically strong key, at least 128 bits in length, 257 indistinguishable by feasible computation from a random uniform 258 string of the same length. How the PSK is generated and/or 259 provisioned is out of scope of this specification. This could be 260 done during a provisioning step or companion documents can specify 261 the use of a key agreement protocol. Common pitfalls when 262 generating PSKs are discussed in Section 9. 264 o Optionally, a network identifier. The network identifier 265 identifies the 6TiSCH network. The network identifier MUST be 266 carried within Enhanced Beacon (EB) frames. Typically, the 16-bit 267 Personal Area Network Identifier (PAN ID) defined in 268 [IEEE802.15.4] is used as the network identifier. However, PAN ID 269 is not considered a stable network identifier as it may change 270 during network lifetime if a collision with another network is 271 detected. Companion documents can specify the use of a different 272 network identifier for join purposes, but this is out of scope of 273 this specification. Provisioning the network identifier is 274 RECOMMENDED. However, due to operational constraints, the network 275 identifier may not be known at the time when the provisioning is 276 done. In case this parameter is not provisioned to the pledge, 277 the pledge attempts to join one advertised network at a time, 278 which significantly prolongs the join process. In case this 279 parameter is not provisioned to the 6LBR pledge, the 6LBR pledge 280 can receive it from the JRC as part of the join protocol. 282 o Optionally, any non-default algorithms. The default algorithms 283 are specified in Section 7.3.3. When algorithm identifiers are 284 not exchanged, the use of these default algorithms is implied. 286 Additionally, the 6LBR pledge that is not co-located with the JRC 287 needs to be provisioned with: 289 o Global IPv6 address of the JRC. This address is used by the 6LBR 290 pledge to address the JRC during the join process. The 6LBR 291 pledge may also obtain the IPv6 address of the JRC through other 292 available mechanisms, such as DHCPv6, GRASP, mDNS, the use of 293 which is out of scope of this document. Pledges do not need to be 294 provisioned with this address as they discover it dynamically 295 through CoJP. 297 4. Join Process Overview 299 This section describes the steps taken by a pledge in a 6TiSCH 300 network. When a pledge seeks admission to a 6TiSCH network, the 301 following exchange occurs: 303 1. The pledge listens for an Enhanced Beacon (EB) frame 304 [IEEE802.15.4]. This frame provides network synchronization 305 information, and tells the device when it can send a frame to the 306 node sending the beacons, which acts as a Join Proxy (JP) for the 307 pledge, and when it can expect to receive a frame. The Enhanced 308 Beacon provides the L2 address of the JP and it may also provide 309 its link-local IPv6 address. 311 2. The pledge configures its link-local IPv6 address and advertises 312 it to the JP using Neighbor Discovery. This step may be omitted 313 if the link-local address has been derived from a known unique 314 interface identifier, such as an EUI-64 address. 316 3. The pledge sends a Join Request to the JP in order to securely 317 identify itself to the network. The Join Request is forwarded to 318 the JRC. 320 4. In case of successful processing of the request, the pledge 321 receives a Join Response from the JRC (via the JP). The Join 322 Response contains configuration parameters necessary for the 323 pledge to join the network. 325 From the pledge's perspective, joining is a local phenomenon - the 326 pledge only interacts with the JP, and it needs not know how far it 327 is from the 6LBR, or how to route to the JRC. Only after 328 establishing one or more link-layer keys does it need to know about 329 the particulars of a 6TiSCH network. 331 The join process is shown as a transaction diagram in Figure 1: 333 +--------+ +-------+ +--------+ 334 | pledge | | JP | | JRC | 335 | | | | | | 336 +--------+ +-------+ +--------+ 337 | | | 338 |<---Enhanced Beacon (1)---| | 339 | | | 340 |<-Neighbor Discovery (2)->| | 341 | | | 342 |-----Join Request (3a)----|----Join Request (3a)---->| \ 343 | | | | CoJP 344 |<----Join Response (3b)---|----Join Response (3b)----| / 345 | | | 347 Figure 1: Overview of a successful join process. 349 As other nodes in the network, the 6LBR node may act as the JP. The 350 6LBR may in addition be co-located with the JRC. 352 The details of each step are described in the following sections. 354 4.1. Step 1 - Enhanced Beacon 356 The pledge synchronizes to the network by listening for, and 357 receiving, an Enhanced Beacon (EB) sent by a node already in the 358 network. This process is entirely defined by [IEEE802.15.4], and 359 described in [RFC7554]. 361 Once the pledge hears an EB, it synchronizes to the joining schedule 362 using the cells contained in the EB. The pledge can hear multiple 363 EBs; the selection of which EB to use is out of the scope for this 364 document, and is discussed in [RFC7554]. Implementers should make 365 use of information such as: what network identifier the EB contains, 366 the value of the Join Metric field within EBs, whether the source 367 link-layer address of the EB has been tried before, what signal 368 strength the different EBs were received at, etc. In addition, the 369 pledge may be pre-configured to search for EBs with a specific 370 network identifier. 372 If the pledge is not provisioned with the network identifier, it 373 attempts to join one network at a time, as described in 374 Section 8.1.1. 376 Once the pledge selects the EB, it synchronizes to it and transitions 377 into a low-power mode. It follows the schedule information contained 378 in the EB which indicates the slots that the pledge may use for the 379 join process. During the remainder of the join process, the node 380 that has sent the EB to the pledge acts as the JP. 382 At this point, the pledge may proceed to step 2, or continue to 383 listen for additional EBs. 385 4.2. Step 2 - Neighbor Discovery 387 The pledge forms its link-local IPv6 address based on the interface 388 identifier, as per [RFC4944]. The pledge MAY perform the Neighbor 389 Solicitation / Neighbor Advertisement exchange with the JP, as per 390 Section 5.5.1 of [RFC6775]. The pledge and the JP use their link- 391 local IPv6 addresses for all subsequent communication during the join 392 process. 394 Note that Neighbor Discovery exchanges at this point are not 395 protected with link-layer security as the pledge is not in possession 396 of the keys. How JP accepts these unprotected frames is discussed in 397 Section 5. 399 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution 401 The pledge triggers the join exchange of the Constrained Join 402 Protocol (CoJP). The join exchange consists of two messages: the 403 Join Request message (Step 3a), and the Join Response message 404 conditioned on the successful security processing of the request 405 (Step 3b). 407 All CoJP messages are exchanged over a secure end-to-end channel that 408 provides confidentiality, data authenticity and replay protection. 409 Frames carrying CoJP messages are not protected with link-layer 410 security when exchanged between the pledge and the JP as the pledge 411 is not in possession of the link-layer keys in use. How JP and 412 pledge accept these unprotected frames is discussed in Section 5. 413 When frames carrying CoJP messages are exchanged between nodes that 414 have already joined the network, the link-layer security is applied 415 according to the security configuration used in the network. 417 4.3.1. Step 3a - Join Request 419 The Join Request is a message sent from the pledge to the JP, and 420 which the JP forwards to the JRC. The pledge indicates in the Join 421 Request the role it requests to play in the network, as well as the 422 identifier of the network it requests to join. The JP forwards the 423 Join Request to the JRC on the existing links. How exactly this 424 happens is out of scope of this document; some networks may wish to 425 dedicate specific link layer resources for this join traffic. 427 4.3.2. Step 3b - Join Response 429 The Join Response is sent by the JRC to the pledge, and is forwarded 430 through the JP. The packet containing the Join Response travels from 431 the JRC to the JP using the operating routes in the network. The JP 432 delivers it to the pledge. The JP operates as the application-layer 433 proxy. 435 The Join Response contains different parameters needed by the pledge 436 to become a fully operational network node. These parameters include 437 the link-layer key(s) currently in use in the network, the short 438 address assigned to the pledge, the IPv6 address of the JRC needed by 439 the pledge to operate as the JP, amoung others. 441 4.4. The Special Case of the 6LBR Pledge Joining 443 The 6LBR pledge performs Section 4.3 of the join process described 444 above, just as any other pledge, albeit over a different network 445 interface. There is no JP intermediating the communication between 446 the 6LBR pledge and the JRC, as described in Section 6. The other 447 steps of the described join process do not apply to the 6LBR pledge. 448 How the 6LBR pledge obtains an IPv6 address and triggers the 449 execution of the CoJP protocol is out of scope of this document. 451 5. Link-layer Configuration 453 In an operational 6TiSCH network, all frames MUST use link-layer 454 frame security [RFC8180]. The IEEE Std 802.15.4 security attributes 455 MUST include frame authenticity, and MAY include frame 456 confidentiality (i.e. encryption). 458 The pledge does not initially do any authenticity check of the EB 459 frames, as it does not possess the link-layer key(s) in use. The 460 pledge is still able to parse the contents of the received EBs and 461 synchronize to the network, as EBs are not encrypted [RFC8180]. 463 When sending frames during the join process, the pledge sends 464 unencrypted and unauthenticated frames. The JP accepts these 465 unsecured frames for the duration of the join process. This behavior 466 may be implemented by setting the "secExempt" attribute in the IEEE 467 Std 802.15.4 security configuration tables. How the JP learns 468 whether the join process is ongoing is out of scope of this 469 specification. 471 As the EB itself cannot be authenticated by the pledge, an attacker 472 may craft a frame that appears to be a valid EB, since the pledge can 473 neither verify the freshness nor verify the address of the JP. This 474 opens up a DoS vector, as discussed in Section 9. 476 6. Network-layer Configuration 478 The pledge and the JP SHOULD keep a separate neighbor cache for 479 untrusted entries and use it to store each other's information during 480 the join process. Mixing neighbor entries belonging to pledges and 481 nodes that are part of the network opens up the JP to a DoS attack, 482 as the attacker may fill JP's neighbor table and prevent the 483 discovery of legitimate neighbors. 485 Once the pledge obtains link-layer keys and becomes a joined node, it 486 is able to securely communicate with its neighbors, obtain the 487 network IPv6 prefix and form its global IPv6 address. The joined 488 node then undergoes an independent process to bootstrap its neighbor 489 cache entries, possibly with a node that formerly acted as a JP, 490 following [RFC6775]. From the point of view of the JP, there is no 491 relationship between the neighbor cache entry belonging to a pledge 492 and the joined node that formerly acted as a pledge. 494 The pledge does not communicate with the JRC at the network layer. 495 This allows the pledge to join without knowing the IPv6 address of 496 the JRC. Instead, the pledge communicates with the JP at the network 497 layer using link-local addressing, and with the JRC at the 498 application layer, as specified in Section 7. 500 The JP communicates with the JRC over global IPv6 addresses. The JP 501 discovers the network IPv6 prefix and configures its global IPv6 502 address upon successful completion of the join process and the 503 obtention of link-layer keys. The pledge learns the IPv6 address of 504 the JRC from the Join Response, as specified in Section 8.1.2; it 505 uses it once joined in order to operate as a JP. 507 As a special case, the 6LBR pledge is expected to have an additional 508 network interface that it uses in order to obtain the configuration 509 parameters from the JRC and start advertising the 6TiSCH network. 510 This additional interface needs to be configured with a global IPv6 511 address, by a mechanism that is out of scope of this document. The 512 6LBR pledge uses this interface to directly communicate with the JRC 513 using global IPv6 addressing. 515 The JRC can be co-located on the 6LBR. In this special case, the 516 IPv6 address of the JRC can be omitted from the Join Response message 517 for space optimization. The 6LBR then MUST set the DODAGID field in 518 the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the 519 address of the JRC once joined and upon the reception of the first 520 RPL DIO message, and uses it to operate as a JP. 522 6.1. Identification of Unauthenticated Traffic 524 The traffic that is proxied by the Join Proxy (JP) comes from 525 unauthenticated pledges, and there may be an arbitrary amount of it. 526 In particular, an attacker may send fraudulent traffic in an attempt 527 to overwhelm the network. 529 When operating as part of a [RFC8180] 6TiSCH minimal network using 530 distributed scheduling algorithms, the traffic from unauthenticated 531 pledges may cause intermediate nodes to request additional bandwidth. 532 An attacker could use this property to cause the network to 533 overcommit bandwidth (and energy) to the join process. 535 The Join Proxy is aware of what traffic originates from 536 unauthenticated pledges, and so can avoid allocating additional 537 bandwidth itself. The Join Proxy implements a bandwidth cap on 538 outgoing join traffic through CoAP's congestion control mechanism. 539 This cap will not protect intermediate nodes as they can not tell 540 join traffic from regular traffic. Despite the bandwidth cap 541 implemented separately on each Join Proxy, the aggregate join traffic 542 from many Join Proxies may cause intermediate nodes to decide to 543 allocate additional cells. It is undesirable to do so in response to 544 the traffic originated at unauthenticated pledges. In order to 545 permit the intermediate nodes to avoid this, the traffic needs to be 546 tagged. [RFC2597] defines a set of per-hop behaviors that may be 547 encoded into the Diffserv Code Points (DSCPs). Based on the DSCP, 548 intermediate nodes can decide whether to act on a given packet. 550 6.1.1. Traffic from JP to JRC 552 The Join Proxy SHOULD set the DSCP of packets that it produces as 553 part of the forwarding process to AF43 code point (See Section 6 of 554 [RFC2597]). A Join Proxy that does not set the DSCP on traffic 555 forwarded should set it to zero so that it is compressed out. 557 A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT 558 allocate additional cells as a result of traffic with code point 559 AF43. Companion SF documents SHOULD specify how this recommended 560 behavior is achieved. 562 6.1.2. Traffic from JRC to JP 564 The JRC SHOULD set the DSCP of join response packets addressed to the 565 Join Proxy to AF42 code point. AF42 has lower drop probability than 566 AF43, giving this traffic priority in buffers over the traffic going 567 towards the JRC. 569 Due to the convergecast nature of the DODAG, the 6LBR links are often 570 the most congested, and from that point down there is progressively 571 less (or equal) congestion. If the 6LBR paces itself when sending 572 join response traffic then it ought to never exceed the bandwidth 573 allocated to the best effort traffic cells. If the 6LBR has the 574 capacity (if it is not constrained) then it should provide some 575 buffers in order to satisfy the Assured Forwarding behavior. 577 Companion SF documents SHOULD specify how traffic with code point 578 AF42 is handled with respect to cell allocation. 580 7. Application-level Configuration 582 The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and 583 the secure channel provided by OSCORE 584 [I-D.ietf-core-object-security]. The (6LBR) acts as a CoAP client; 585 the JRC acts as a CoAP server. The JP implements CoAP forward proxy 586 functionality [RFC7252]. Because the JP can also be a constrained 587 device, it cannot implement a cache. 589 The pledge designates a JP as a proxy by including the Proxy-Scheme 590 option in CoAP requests it sends to the JP. The pledge also includes 591 in the requests the Uri-Host option with its value set to the well- 592 known JRC's alias, as specified in Section 8.1.1. 594 The JP resolves the alias to the IPv6 address of the JRC that it 595 learned when it acted as a pledge, and joined the network. This 596 allows the JP to reach the JRC at the network layer and forward the 597 requests on behalf of the pledge. 599 7.1. Statelessness of the JP 601 The CoAP proxy defined in [RFC7252] keeps per-client state 602 information in order to forward the response towards the originator 603 of the request. This state information includes at least the CoAP 604 token, the IPv6 address of the client, and the UDP source port 605 number. Since the JP can be a constrained device that acts as a CoAP 606 proxy, memory limitations make it prone to a Denial-of-Service (DoS) 607 attack. 609 This DoS vector on the JP can be mitigated by making the JP act as a 610 stateless CoAP proxy, where "state" refers to individual pledges. 611 The JP can wrap the state it needs to keep for a given pledge 612 throughout the network stack in a "state object" and include it as a 613 CoAP token in the forwarded request to the JRC. The JP may use the 614 CoAP token as defined in [RFC7252], if the size of the serialized 615 state object permits, or use the extended CoAP token defined in 616 [I-D.hartke-core-stateless], to transport the state object. Since 617 the CoAP token is echoed back in the response, the JP is able to 618 decode the state object and configure the state needed to forward the 619 response to the pledge. The information that the JP needs to encode 620 in the state object to operate in a fully stateless manner with 621 respect to a given pledge is implementation specific. 623 It is RECOMMENDED that the JP operates in a stateless manner and 624 signals the per-pledge state within the CoAP token, for every request 625 it forwards into the network on behalf of unauthenticated pledges. 626 When operating in a stateles manner, the state object communicated in 627 the token MUST be integrity protected, potentially with a key that is 628 known only to the JP, MUST include a freshness indicator, and MAY be 629 encrypted. Security considerations from [I-D.hartke-core-stateless] 630 apply. 632 When operating in a stateless manner, the type of the CoAP message 633 that the JP forwards on behalf of the pledge MUST be non-confirmable 634 (NON), regardless of the message type received from the pledge. The 635 use of a non-confirmable message by the JP alleviates the JP from 636 keeping CoAP message exchange state. The retransmission burden is 637 then entirely shifted to the pledge. A JP that operates in a 638 stateless manner still needs to keep congestion control state with 639 the JRC, see Section 9. Recommended values of CoAP settings for use 640 during the join process, both by the pledge and the JP, are given in 641 Section 7.2. 643 Note that in some networking stack implementations, a fully (per- 644 pledge) stateless operation of the JP may be challenging from the 645 implementation's point of view. In those cases, the JP may operate 646 as a statefull proxy that stores the per-pledge state until the 647 response is received or timed out, but this comes at a price of an 648 additional DoS vector. 650 7.2. Recommended Settings 652 This section gives RECOMMENDED values of CoAP settings during the 653 join process. 655 +-------------------+-----------------------+-------------------+ 656 | Name | Default Value: Pledge | Default Value: JP | 657 +-------------------+-----------------------+-------------------+ 658 | ACK_TIMEOUT | 10 seconds | (10 seconds) | 659 | | | | 660 | ACK_RANDOM_FACTOR | 1.5 | (1.5) | 661 | | | | 662 | MAX_RETRANSMIT | 4 | (4) | 663 | | | | 664 | NSTART | 1 | (3) | 665 | | | | 666 | PROBING_RATE | 4 byte/second | 12 byte/second | 667 +-------------------+-----------------------+-------------------+ 669 Recommended CoAP settings. Values enclosed in () have no effect when 670 JP operates in a stateless manner. 672 These values may be configured to values specific to the deployment. 673 The default values have been chosen to accommodate a wide range of 674 deployments, taking into account dense networks. Increased values of 675 NSTART and PROBING_RATE at the JP enable multiple pledges 676 (approximately 3 pledges by default) to concurrently join through the 677 same JP. Following [RFC7252], the average data rate in sending to JP 678 or JRC must not exceed PROBING_RATE. For security reasons, the 679 average data rate SHOULD be measured over a rather short window, e.g. 680 ACK_TIMEOUT, see Section 9. 682 7.3. OSCORE 684 Before the (6LBR) pledge and the JRC start exchanging CoAP messages 685 protected with OSCORE, they need to derive the OSCORE security 686 context from the provisioned parameters, as discussed in Section 3. 688 The OSCORE security context MUST be derived as per Section 3 of 689 [I-D.ietf-core-object-security]. 691 o the Master Secret MUST be the PSK. 693 o the Master Salt MUST be the empty byte string. 695 o the ID Context MUST be set to the pledge identifier. 697 o the ID of the pledge MUST be set to the empty byte string. This 698 identifier is used as the OSCORE Sender ID of the pledge in the 699 security context derivation, since the pledge initially acts as a 700 CoAP client. 702 o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" 703 in ASCII). This identifier is used as the OSCORE Recipient ID of 704 the pledge in the security context derivation, as the JRC 705 initially acts as a CoAP server. 707 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 708 of-band by the same mechanism used to provision the PSK. The 709 default is AES-CCM-16-64-128. 711 o the Key Derivation Function MUST be agreed out-of-band by the same 712 mechanism used to provision the PSK. Default is HKDF SHA-256 713 [RFC5869]. 715 Since the pledge's OSCORE ID is the empty byte string, when 716 constructing the OSCORE option, the pledge sets the k bit in the 717 OSCORE flag byte, but indicates a 0-length kid. The pledge 718 transports its pledge identifier within the kid context field of the 719 OSCORE option. The derivation in [I-D.ietf-core-object-security] 720 results in OSCORE keys and a common IV for each side of the 721 conversation. Nonces are constructed by XOR'ing the common IV with 722 the current sequence number. For details on nonce and OSCORE option 723 construction, refer to [I-D.ietf-core-object-security]. 725 Implementations MUST ensure that multiple CoAP requests to different 726 JRCs are properly incrementing the sequence numbers in the OSCORE 727 security context for each message, so that the same sequence number 728 is never reused in distinct requests. The pledge typically sends 729 requests to different JRCs if it is not provisioned with the network 730 identifier and attempts to join one network at a time. A simple 731 implementation technique is to instantiate the OSCORE security 732 context with a given PSK only once and use it for all subsequent 733 requests. Failure to comply will break the security guarantees of 734 the Authenticated Encryption with Associated Data (AEAD) algorithm 735 because of nonce reuse. 737 This OSCORE security context is used for initial joining of the 738 (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well 739 as for any later parameter updates, where the JRC acts as a CoAP 740 client and the joined node as a CoAP server, as discussed in 741 Section 8.2. The (6LBR) pledge and the JRC use the OSCORE security 742 context parameters (e.g. sender and recipient identifiers) as they 743 were used at the moment of context derivation, regardless of whether 744 they currently act as a CoAP client or a CoAP server. A (6LBR) 745 pledge is expected to have exactly one OSCORE security context with 746 the JRC. 748 7.3.1. Replay Window and Persistency 750 Both (6LBR) pledge and the JRC MUST implement a replay protection 751 mechanism. The use of the default OSCORE replay protection mechanism 752 specified in Section 3.2.2 of [I-D.ietf-core-object-security] is 753 RECOMMENDED. 755 Implementations MUST ensure that mutable OSCORE context parameters 756 (Sender Sequence Number, Replay Window) are stored in persistent 757 memory. A technique that prevents reuse of sequence numbers, 758 detailed in Section 7.5.1 of [I-D.ietf-core-object-security], MUST be 759 implemented. Each update of the OSCORE Replay Window MUST be written 760 to persistent memory. 762 This is an important security requirement in order to guarantee nonce 763 uniqueness and resistance to replay attacks across reboots and 764 rejoins. Traffic between the (6LBR) pledge and the JRC is rare, 765 making security outweigh the cost of writing to persistent memory. 767 7.3.2. OSCORE Error Handling 769 Errors raised by OSCORE during the join process MUST be silently 770 dropped, with no error response being signaled. The pledge MUST 771 silently discard any response not protected with OSCORE, including 772 error codes. 774 Such errors may happen for a number of reasons, including failed 775 lookup of an appropriate security context (e.g. the pledge attempting 776 to join a wrong network), failed decryption, positive replay window 777 lookup, formatting errors (possibly due to malicious alterations in 778 transit). Silently dropping OSCORE messages prevents a DoS attack on 779 the pledge where the attacker could send bogus error responses, 780 forcing the pledge to attempt joining one network at a time, until 781 all networks have been tried. 783 7.3.3. Mandatory to Implement Algorithms 785 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 786 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 787 securing IEEE Std 802.15.4 frames, and hardware acceleration for it 788 is present in virtually all compliant radio chips. With this choice, 789 CoAP messages are protected with an 8-byte CCM authentication tag, 790 and the algorithm uses 13-byte long nonces. 792 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The 793 mandatory to implement key derivation function is HKDF [RFC5869], 794 instantiated with a SHA-256 hash. See Appendix B for implementation 795 guidance when code footprint is important. 797 8. Constrained Join Protocol (CoJP) 799 The Constrained Join Protocol (CoJP) is a lightweight protocol over 800 CoAP [RFC7252] and a secure channel provided by OSCORE 801 [I-D.ietf-core-object-security]. CoJP allows the (6LBR) pledge to 802 request admission into a network managed by the JRC, and for the JRC 803 to configure the pledge with the parameters necessary for joining the 804 network, or advertising it in the case of 6LBR pledge. The JRC may 805 update the parameters at any time, by reaching out to the joined node 806 that formerly acted as a (6LBR) pledge. For example, network-wide 807 rekeying can be implemented by updating the keying material on each 808 node. 810 This section specifies how the CoJP messages are mapped to CoAP and 811 OSCORE, CBOR data structures carrying different parameters, 812 transported within CoAP payload, and the parameter semantics and 813 processing rules. 815 CoJP relies on the security properties provided by OSCORE. This 816 includes end-to-end confidentiality, data authenticity, replay 817 protection, and a secure binding of responses to requests. 819 +-----------------------------------+ 820 | Constrained Join Protocol (CoJP) | 821 +-----------------------------------+ 822 +-----------------------------------+ \ 823 | Requests / Responses | | 824 |-----------------------------------| | 825 | OSCORE | | CoAP 826 |-----------------------------------| | 827 | Messaging Layer | | 828 +-----------------------------------+ / 829 +-----------------------------------+ 830 | UDP | 831 +-----------------------------------+ 833 Figure 2: Abstract layering of CoJP. 835 When a (6LBR) pledge requests admission to a given network, it 836 undergoes the CoJP join exchange that consists of: 838 o the Join Request message, sent by the (6LBR) pledge to the JRC, 839 potentially proxied by the JP. The Join Request message and its 840 mapping to CoAP is specified in Section 8.1.1. 842 o the Join Response message, sent by the JRC to the (6LBR) pledge, 843 if the JRC successfully processes the Join Request using OSCORE 844 and it determines through a mechanism that is out of scope of this 845 specification that the (6LBR) pledge is authorized to join the 846 network. The Join Response message is potentially proxied by the 847 JP. The Join Response message and its mapping to CoAP is 848 specified in Section 8.1.2. 850 When the JRC needs to update the parameters of a joined node that 851 formerly acted as a (6LBR) pledge, it executes the CoJP parameter 852 update exchange that consists of: 854 o the Parameter Update message, sent by the JRC to the joined node 855 that formerly acted as a (6LBR) pledge. The Parameter Update 856 message and its mapping to CoAP is specified in Section 8.2.1. 858 o the Parameter Update Response message, sent by the joined node to 859 the JRC in response to the Parameter Update message to signal 860 successful reception of the updated parameters. The Parameter 861 Update Response message and its mapping to CoAP is specified in 862 Section 8.2.2. 864 The payload of CoJP messages is encoded with CBOR [RFC7049]. The 865 CBOR data structures that may appear as the payload of different CoJP 866 messages are specified in Section 8.4. 868 8.1. Join Exchange 870 This section specifies the messages exchanged when the (6LBR) pledge 871 requests admission and configuration parameters from the JRC. 873 8.1.1. Join Request Message 875 The Join Request message that the (6LBR) pledge sends SHALL be mapped 876 to a CoAP request: 878 o The request method is POST. 880 o The type is Confirmable (CON). 882 o The Proxy-Scheme option is set to "coap". 884 o The Uri-Host option is set to "6tisch.arpa". This is an anycast 885 type of identifier of the JRC that is resolved to its IPv6 address 886 by the JP or the 6LBR pledge. 888 o The Uri-Path option is set to "j". 890 o The OSCORE option SHALL be set according to 891 [I-D.ietf-core-object-security]. The OSCORE security context used 892 is the one derived in Section 7.3. The OSCORE kid context allows 893 the JRC to retrieve the security context for a given pledge. 895 o The payload is a Join_Request CBOR object, as defined in 896 Section 8.4.1. 898 Since the Join Request is a confirmable message, the transmission at 899 (6LBR) pledge will be controlled by CoAP's retransmission mechanism. 900 The JP, when operating in a stateless manner, forwards this Join 901 Request as a non-confirmable (NON) CoAP message, as specified in 902 Section 7. If the CoAP at (6LBR) pledge declares the message 903 transmission as failure, the (6LBR) pledge SHOULD attempt to join the 904 next advertised 6TiSCH network. See Section 7.2 for recommended 905 values of CoAP settings to use during the join exchange. 907 If all join attempts to advertised networks have failed, the (6LBR) 908 pledge SHOULD signal to the user the presence of an error condition, 909 through some out-of-band mechanism. 911 8.1.2. Join Response Message 913 The Join Response message that the JRC sends SHALL be mapped to a 914 CoAP response: 916 o The response Code is 2.04 (Changed). 918 o The payload is a Configuration CBOR object, as defined in 919 Section 8.4.2. 921 8.2. Parameter Update Exchange 923 During the network lifetime, parameters returned as part of the Join 924 Response may need to be updated. One typical example is the update 925 of link-layer keying material for the network, a process known as 926 rekeying. This section specifies a generic mechanism when this 927 parameter update is initiated by the JRC. 929 At the time of the join, the (6LBR) pledge acts as a CoAP client and 930 requests the network parameters through a representation of the "/j" 931 resource, exposed by the JRC. In order for the update of these 932 parameters to happen, the JRC needs to asynchronously contact the 933 joined node. The use of the CoAP Observe option for this purpose is 934 not feasible due to the change in the IPv6 address when the pledge 935 becomes the joined node and obtains a global address. 937 Instead, once the (6LBR) pledge receives and successfully validates 938 the Join Response and so becomes a joined node, it becomes a CoAP 939 server. The joined node exposes the "/j" resource that is used by 940 the JRC to update the parameters. Consequently, the JRC operates as 941 a CoAP client when updating the parameters. The request/response 942 exchange between the JRC and the (6LBR) pledge happens over the 943 already-established OSCORE secure channel. 945 8.2.1. Parameter Update Message 947 The Parameter Update message that the JRC sends to the joined node 948 SHALL be mapped to a CoAP request: 950 o The request method is POST. 952 o The type is Confirmable (CON). 954 o The Uri-Path option is set to "j". 956 o The OSCORE option SHALL be set according to 957 [I-D.ietf-core-object-security]. The OSCORE security context used 958 is the one derived in Section 7.3. When a joined node receives a 959 request with the Sender ID set to 0x4a5243 (ID of the JRC), it is 960 able to correctly retrieve the security context with the JRC. 962 o The payload is a Configuration CBOR object, as defined in 963 Section 8.4.2. 965 The JRC has implicit knowledge on the global IPv6 address of the 966 joined node, as it knows the pledge identifier that the joined node 967 used when it acted as a pledge, and the IPv6 network prefix. The JRC 968 uses this implicitly derived IPv6 address of the joined node to 969 directly address CoAP messages to it. 971 In case the JRC does not receive a response to a Parameter Update 972 message, it attempts multiple retransmissions, as configured by the 973 underlying CoAP retransmission mechanism triggered for confirmable 974 messages. Finally, if the CoAP implementation declares the 975 transmission as failure, the JRC may consider this as a hint that the 976 joined node is no longer in the network. How the JRC decides when to 977 stop attempting to contact a previously joined node is out of scope 978 of this specification but security considerations on the reuse of 979 assigned resources apply, as discussed in Section 9. 981 8.2.2. Parameter Update Response Message 983 The Parameter Update Response message that the joined node sends to 984 the JRC SHALL be mapped to a CoAP response: 986 o The response Code is 2.04 (Changed). 988 o The payload is empty. 990 8.3. Error Handling 992 8.3.1. CoJP CBOR Object Processing 994 This section describes error handling when processing CoJP CBOR 995 objects that are transported within the payload of different CoJP 996 messages. See Section 7.3.2 for the handling of errors that may be 997 raised by the underlying OSCORE implementation. 999 CoJP CBOR objects are transported within both CoAP requests and 1000 responses. When an error is detected while processing CoJP objects 1001 in a CoAP request (Join Request message, Parameter Update message), 1002 an Error Response message MUST be returned. An Error Response 1003 message maps to a CoAP response and is specified in Section 8.3.2. 1005 When an error is detected while processing a CoJP object in a CoAP 1006 response (Join Response message), a (6LBR) pledge SHOULD reattempt to 1007 join. In this case, the (6LBR) pledge SHOULD include the Error CBOR 1008 object within the Join Request object in the following Join Request 1009 message. A (6LBR) pledge MUST NOT attempt more than MAX_RETRANSMIT 1010 number of attempts to join if the processing of the Join Response 1011 message fails each time. If COJP_MAX_JOIN_ATTEMPTS number of 1012 attempts is reached without success, the (6LBR) pledge SHOULD signal 1013 to the user the presence of an error condition, through some out-of- 1014 band mechanism. 1016 8.3.2. Error Response Message 1018 The Error Response Message is returned for any CoJP request when the 1019 processing of the payload failed. The Error Response message is 1020 protected by OSCORE as any other CoJP protocol message. 1022 The Error Response message SHALL be mapped to a CoAP response: 1024 o The response Code is 4.00 (Bad Request). 1026 o The payload is an Error CBOR object, as defined in Section 8.4.5, 1027 containing the error code that triggered the sending of this 1028 message. 1030 8.3.3. Failure Handling 1032 The Parameter Update exchange may be triggered at any time during the 1033 network lifetime, which may span several years. During this period, 1034 it may occur that a joined node or the JRC experience unexpected 1035 events such as reboots or complete failures. 1037 This document mandates that the mutable parameters in the security 1038 context are written to persistent memory (see Section 7.3.1) by both 1039 the JRC and pledges (joined nodes). In case of a reboot on either 1040 side, the retrieval of mutable security context parameters is 1041 feasible from the persistent memory such that there is no risk of 1042 AEAD nonce reuse due to a reinitialized Sender Sequence number, or of 1043 a replay attack due to the reinitialized replay window. 1045 In the case of a complete failure, where the mutable security context 1046 parameters cannot be retrieved, it is expected that a failed joined 1047 node is replaced with a new physical device, using a new pledge 1048 identifier and a PSK. When such an event occurs at the JRC, it is 1049 likely that the information about joined nodes, their assigned short 1050 identifiers and mutable security context parameters is lost. If this 1051 is the case, during the process of JRC replacement, the network 1052 administrator MUST force all the networks managed by the failed JRC 1053 to rejoin, through e.g. the reinitialization of the 6LBR nodes. 1054 Since the joined nodes kept track of their mutable security context 1055 parameters, they will use these during the (re)join exchange without 1056 a risk of AEAD nonce reuse. However, even after all the nodes 1057 rejoined, the AEAD nonce reuse risk exists during the first Parameter 1058 Update exchange, as the new JRC does not possess the last Sender 1059 Sequence number used, and can only initialize it to zero. Since the 1060 sending of this first Parameter Update message by the new JRC results 1061 in AEAD nonce reuse, the JRC MUST set the payload to a randomly 1062 generated byte string, at least 40 bytes long. 1064 When such a message arrives at the joined node, the OSCORE 1065 implementation rejects it due to the Partial IV being largely below 1066 the acceptable replay window state and does not process the payload. 1067 When this is detected, the joined node MUST send an Error Response 1068 message with error code set to "Significant OSCORE partial IV 1069 mismatch" from Table 4 and Additional information set to the next 1070 Partial IV it will expect. When protecting this error response by 1071 OSCORE, the joined node uses the value of its Sender Sequence number 1072 to generate the Partial IV and includes it in the CoAP OSCORE option, 1073 as specified by [I-D.ietf-core-object-security]. Upon successful 1074 OSCORE verification of the received CoJP message, the JRC processes 1075 the error response and configures the Sender Sequence number to the 1076 one indicated in the Additional information field. The next 1077 Parameter Update exchange triggered by the JRC will therefore use the 1078 proper Sender Sequence number and will be accepted by the joined 1079 node. 1081 8.4. CoJP Objects 1083 This section specifies the structure of CoJP CBOR objects that may be 1084 carried as the payload of CoJP messages. Some of these objects may 1085 be received both as part of the CoJP join exchange when the device 1086 operates as a (CoJP) pledge, or the parameter update exchange, when 1087 the device operates as a joined (6LBR) node. 1089 8.4.1. Join Request Object 1091 The Join_Request structure is built on a CBOR map object. 1093 The set of parameters that can appear in a Join_Request object is 1094 summarized below. The labels can be found in the "CoJP Parameters" 1095 registry Section 11.1. 1097 o role: The identifier of the role that the pledge requests to play 1098 in the network once it joins, encoded as an unsigned integer. 1099 Possible values are specified in Table 1. This parameter MAY be 1100 included. In case the parameter is omitted, the default value of 1101 0, i.e. the role "6TiSCH Node", MUST be assumed. 1103 o network identifier: The identifier of the network, as discussed in 1104 Section 3, encoded as a CBOR byte string. This parameter may 1105 appear both in the Join_Request and in the Configuration objects. 1106 When present in the Join_Request, it hints to the JRC the network 1107 that the pledge is requesting to join, enabling the JRC to manage 1108 multiple networks. The pledge obtains the value of the network 1109 identifier from the received EB frames. This parameter MUST be 1110 included in a Join_Request object if the role parameter is set to 1111 "6TiSCH Node". This parameter MAY be included if the role 1112 parameter is set to "6LBR". The inclusion of this parameter by 1113 the 6LBR pledge depends on whether the parameter was exchanged 1114 during the provisioning phase, which in turn depends on the 1115 operational constraints. 1117 o response processing error: The identifier of the error from the 1118 previous join attempt, encoded as an Error object described in 1119 Section 8.4.5. This parameter MAY be included. If a (6LBR) 1120 pledge previously attempted to join and received a valid Join 1121 Response message over OSCORE, but failed to process its payload 1122 (Configuration object), it SHOULD include this parameter to 1123 facilitate the debugging process. 1125 The CDDL fragment that represents the text above for the Join_Request 1126 follows. 1128 Join_Request = { 1129 ? 1 : uint, ; role 1130 ? 5 : bstr, ; network identifier 1131 ? 7 : Error, ; response processing error 1132 } 1134 +--------+-------+-------------------------------------+------------+ 1135 | Name | Value | Description | Reference | 1136 +--------+-------+-------------------------------------+------------+ 1137 | 6TiSCH | 0 | The pledge requests to play the | [[this | 1138 | Node | | role of a regular 6TiSCH node, i.e. | document]] | 1139 | | | non-6LBR node. | | 1140 | | | | | 1141 | 6LBR | 1 | The pledge requests to play the | [[this | 1142 | | | role of 6LoWPAN Border Router | document]] | 1143 | | | (6LBR). | | 1144 +--------+-------+-------------------------------------+------------+ 1146 Table 1: Role values. 1148 8.4.2. Configuration Object 1150 The Configuration structure is built on a CBOR map object. The set 1151 of parameters that can appear in a Configuration object is summarized 1152 below. The labels can be found in "CoJP Parameters" registry 1153 Section 11.1. 1155 o link-layer key set: An array encompassing a set of cryptographic 1156 keys and their identifiers that are currently in use in the 1157 network, or that are scheduled to be used in the future. The 1158 encoding of individual keys is described in Section 8.4.3. The 1159 link-layer key set parameter MAY be included in a Configuration 1160 object. When present, the link-layer key set parameter MUST 1161 contain at least one key. How the keys are installed and used 1162 differs for the 6LBR and other nodes. When 6LBR receives this 1163 parameter, it MUST immediately install and start using the new 1164 keys for all outgoing traffic, and remove any old keys it has 1165 installed from the previous key set after a delay of 1166 COJP_REKEYING_GUARD_TIME has passed. When a non-6LBR node 1167 receives this parameter, it MUST install the keys, use them for 1168 any incoming traffic matching the key identifier, but keep using 1169 the old keys for all outgoing traffic. 6LBR and non-6LBR nodes 1170 accept any frame for which they have keys: both old and new keys. 1171 Upon reception and successful security processing of a link-layer 1172 frame secured with a key from the new key set, a non-6LBR node 1173 MUST start using the keys from the new set for all outgoing 1174 traffic. A non-6LBR node MUST remove any old keys it has 1175 installed from the previous key set after a delay of 1176 COJP_REKEYING_GUARD_TIME has passed. In the case when the pledge 1177 is joining for the first time, before sending the first outgoing 1178 frame secured with a received key, the pledge needs to 1179 successfully complete the security processing of an incoming 1180 frame. To do so, the pledge can wait to receive a new frame, or 1181 it can store an EB frame that it used to find the JP and use it 1182 for immediate security processing upon reception of the key set. 1183 The described mechanism permits the JRC to provision the new key 1184 set to all the nodes while the network continues to use the 1185 existing keys. When the JRC is certain that all (or enough) nodes 1186 have been provisioned with the new keys, then the JRC updates the 1187 6LBR. In the special case when the JRC is co-located with the 1188 6LBR, it can simply trigger the sending of a new broadcast frame 1189 (e.g. EB), secured with a key from the new key set. The frame 1190 goes out with the new key, and upon reception and successful 1191 security processing of the new frame all receiving nodes will 1192 switch to the new active keys. Outgoing traffic from those nodes 1193 will then use the new key, which causes an update of additional 1194 peers, and the network will switch over in a flood-fill fashion. 1196 o short identifier: a compact identifier assigned to the pledge. 1197 The short identifier structure is described in Section 8.4.4. The 1198 short identifier parameter MAY be included in a Configuration 1199 object. 1201 o JRC address: the IPv6 address of the JRC, encoded as a byte 1202 string, with the length of 16 bytes. If the length of the byte 1203 string is different from 16, the parameter MUST be discarded. If 1204 the JRC is not co-located with the 6LBR and has a different IPv6 1205 address than the 6LBR, this parameter MUST be included. In the 1206 special case where the JRC is co-located with the 6LBR and has the 1207 same IPv6 address as the 6LBR, this parameter MAY be included. If 1208 the JRC address parameter is not present in the Configuration 1209 object, this indicates that the JRC has the same IPv6 address as 1210 the 6LBR. The joined node can then discover the IPv6 address of 1211 the JRC through network control traffic. See Section 6. 1213 o network identifier: the identifier of the network, as discussed in 1214 Section 3, encoded as a byte string. When present in the 1215 Configuration object, this parameter is only valid when received 1216 by the 6LBR pledge. The parameter indicates to the 6LBR the value 1217 of the network identifier it should advertise at the link layer. 1218 This parameter MUST NOT be included in the Configuration object if 1219 the role parameter from the corresponding Join_Request object 1220 indicated 0, i.e. the role "6TiSCH Node". In the case where the 1221 corresponding Join_Request object does not contain the network 1222 identifier parameter, this parameter MUST be included. When the 1223 corresponding Join_Request object does contain the network 1224 identifier parameter, this parameter MAY be included in the 1225 Configuration object. This may happen if the JRC decides to 1226 overwrite the network identifier obtained during the provisioning 1227 phase. The value of the network identifier parameter from the 1228 Configuration object SHOULD take precedence over the value 1229 obtained during the provisioning phase. 1231 o blacklist: An array encompassing a list of pledge identifiers that 1232 are blacklisted by the JRC, with each pledge identifier encoded as 1233 a byte string. The blacklist parameter MAY be included in a 1234 Configuration object. When present, the blacklist parameter MUST 1235 contain at least one pledge identifier. When the joined node 1236 receives this parameter, it MUST silently drop any link-layer 1237 frames originating from the indicated pledge identifiers. This 1238 parameter allows the JRC to configure the node acting as a JP to 1239 filter out traffic from misconfigured or malicious pledges before 1240 their traffic is forwarded into the network. 1242 The CDDL fragment that represents the text above for the 1243 Configuration follows. Structures Link_Layer_Key and 1244 Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. 1246 Configuration = { 1247 ? 2 : [ +Link_Layer_Key ], ; link-layer key set 1248 ? 3 : Short_Identifier, ; short identifier 1249 ? 4 : bstr, ; JRC address 1250 ? 5 : bstr, ; network identifier 1251 ? 6 : [ +bstr ], ; blacklist 1252 } 1253 +------------+-------+----------+----------------------+------------+ 1254 | Name | Label | CBOR | Description | Reference | 1255 | | | type | | | 1256 +------------+-------+----------+----------------------+------------+ 1257 | role | 1 | unsigned | Identifies the role | [[this | 1258 | | | integer | parameter | document]] | 1259 | | | | | | 1260 | link-layer | 2 | array | Identifies the array | [[this | 1261 | key set | | | carrying one or more | document]] | 1262 | | | | link-level | | 1263 | | | | cryptographic keys | | 1264 | | | | | | 1265 | short | 3 | array | Identifies the | [[this | 1266 | identifier | | | assigned short | document]] | 1267 | | | | identifier | | 1268 | | | | | | 1269 | JRC | 4 | byte | Identifies the IPv6 | [[this | 1270 | address | | string | address of the JRC | document]] | 1271 | | | | | | 1272 | network | 5 | byte | Identifies the | [[this | 1273 | identifier | | string | network identifier | document]] | 1274 | | | | parameter | | 1275 | | | | | | 1276 | blacklist | 6 | array | Identifies the | [[this | 1277 | | | | blacklist parameter | document]] | 1278 | | | | | | 1279 | error | 7 | array | Identifies the error | [[this | 1280 | | | | parameter | document]] | 1281 +------------+-------+----------+----------------------+------------+ 1283 Table 2: CoJP parameters map labels. 1285 8.4.3. Link-Layer Key 1287 The Link_Layer_Key structure encompasses the parameters needed to 1288 configure the link-layer security module: the key identifier; the 1289 value of the cryptographic key; the link-layer algorithm identifier 1290 and the security level and the frame types that it should be used 1291 with, both for outgoing and incoming security operations; and any 1292 additional information that may be needed to configure the key. 1294 For encoding compactness, the Link_Layer_Key object is not enclosed 1295 in a top-level CBOR object. Rather, it is transported as a sequence 1296 of CBOR elements, some being optional. 1298 The set of parameters that can appear in a Link_Layer_Key object is 1299 summarized below, in order: 1301 o key_id: The identifier of the key, encoded as a CBOR unsigned 1302 integer. This parameter MUST be included. If the decoded CBOR 1303 unsigned integer value is larger than the maximum link-layer key 1304 identifier, the key is considered invalid. In case the key is 1305 considered invalid, the key MUST be discarded and the 1306 implementation MUST signal the error as specified in 1307 Section 8.3.1. 1309 o key_usage: The identifier of the link-layer algorithm, security 1310 level and link-layer frame types that can be used with the key, 1311 encoded as an integer. This parameter MAY be included. Possible 1312 values and the corresponding link-layer settings are specified in 1313 IANA "CoJP Key Usage" registry (Section 11.2). In case the 1314 parameter is omitted, the default value of 0 from Table 3 MUST be 1315 assumed. 1317 o key_value: The value of the cryptographic key, encoded as a byte 1318 string. This parameter MUST be included. If the length of the 1319 byte string is different than the corresponding key length for a 1320 given algorithm specified by the key_usage parameter, the key MUST 1321 be discarded and the implementation MUST signal the error as 1322 specified in Section 8.3.1. 1324 o key_addinfo: Additional information needed to configure the link- 1325 layer key, encoded as a byte string. This parameter MAY be 1326 included. The processing of this parameter is dependent on the 1327 link-layer technology in use and a particular keying mode. 1329 To be able to decode the keys that are present in the link-layer key 1330 set, and to identify individual parameters of a single Link_Layer_Key 1331 object, the CBOR decoder needs to differentiate between elements 1332 based on the CBOR type. For example, a uint that follows a byte 1333 string signals to the decoder that a new Link_Layer_Key object is 1334 being processed. 1336 The CDDL fragment that represents the text above for the 1337 Link_Layer_Key follows. 1339 Link_Layer_Key = ( 1340 key_id : uint, 1341 ? key_usage : int, 1342 key_value : bstr, 1343 ? key_addinfo : bstr, 1344 ) 1346 +-----------------+-----+------------------+-------------+----------+ 1347 | Name | Val | Algorithm | Description | Referenc | 1348 | | ue | | | e | 1349 +-----------------+-----+------------------+-------------+----------+ 1350 | 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | 1351 | -ENC-MIC32 | | CCM-128 | for EBs, | ocument] | 1352 | | | | ENC-MIC-32 | ] | 1353 | | | | for DATA | | 1354 | | | | and ACKNOWL | | 1355 | | | | EDGMENT. | | 1356 | | | | | | 1357 | 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | 1358 | -ENC-MIC64 | | CCM-128 | for EBs, | ocument] | 1359 | | | | ENC-MIC-64 | ] | 1360 | | | | for DATA | | 1361 | | | | and ACKNOWL | | 1362 | | | | EDGMENT. | | 1363 | | | | | | 1364 | 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | 1365 | -ENC-MIC128 | | CCM-128 | for EBs, | ocument] | 1366 | | | | ENC-MIC-128 | ] | 1367 | | | | for DATA | | 1368 | | | | and ACKNOWL | | 1369 | | | | EDGMENT. | | 1370 | | | | | | 1371 | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | 1372 | K1K2-MIC32 | | CCM-128 | for EBs, | ocument] | 1373 | | | | DATA and AC | ] | 1374 | | | | KNOWLEDGMEN | | 1375 | | | | T. | | 1376 | | | | | | 1377 | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | 1378 | K1K2-MIC64 | | CCM-128 | for EBs, | ocument] | 1379 | | | | DATA and AC | ] | 1380 | | | | KNOWLEDGMEN | | 1381 | | | | T. | | 1382 | | | | | | 1383 | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | 1384 | K1K2-MIC128 | | CCM-128 | for EBs, | ocument] | 1385 | | | | DATA and AC | ] | 1386 | | | | KNOWLEDGMEN | | 1387 | | | | T. | | 1388 | | | | | | 1389 | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | 1390 | | | CCM-128 | for EBs. | ocument] | 1391 | | | | | ] | 1392 | | | | | | 1393 | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | 1394 | | | CCM-128 | for EBs. | ocument] | 1395 | | | | | ] | 1396 | | | | | | 1397 | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | 1398 | 8 | | CCM-128 | for EBs. | ocument] | 1399 | | | | | ] | 1400 | | | | | | 1401 | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | 1402 | | | CCM-128 | for DATA | ocument] | 1403 | | | | and ACKNOWL | ] | 1404 | | | | EDGMENT. | | 1405 | | | | | | 1406 | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | 1407 | | | CCM-128 | for DATA | ocument] | 1408 | | | | and ACKNOWL | ] | 1409 | | | | EDGMENT. | | 1410 | | | | | | 1411 | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | 1412 | 8 | | CCM-128 | for DATA | ocument] | 1413 | | | | and ACKNOWL | ] | 1414 | | | | EDGMENT. | | 1415 | | | | | | 1416 | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | 1417 | MIC32 | | CCM-128 | MIC-32 for | ocument] | 1418 | | | | DATA and AC | ] | 1419 | | | | KNOWLEDGMEN | | 1420 | | | | T. | | 1421 | | | | | | 1422 | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | 1423 | MIC64 | | CCM-128 | MIC-64 for | ocument] | 1424 | | | | DATA and AC | ] | 1425 | | | | KNOWLEDGMEN | | 1426 | | | | T. | | 1427 | | | | | | 1428 | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | 1429 | MIC128 | | CCM-128 | MIC-128 for | ocument] | 1430 | | | | DATA and AC | ] | 1431 | | | | KNOWLEDGMEN | | 1432 | | | | T. | | 1433 +-----------------+-----+------------------+-------------+----------+ 1435 Table 3: Key Usage values. 1437 8.4.3.1. Use in IEEE Std 802.15.4 1439 When Link_Layer_Key is used in the context of [IEEE802.15.4], the 1440 following considerations apply. 1442 Signaling of different keying modes of [IEEE802.15.4] is done based 1443 on the parameter values present in a Link_Layer_Key object. 1445 o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be 1446 set to 0. key_addinfo parameter MUST be present. key_addinfo 1447 parameter MUST be set to the link-layer address(es) of a single 1448 peer with whom the key should be used. Depending on the 1449 configuration of the network, key_addinfo may carry the peer's 1450 long link-layer address (i.e. pledge identifier), short link-layer 1451 address, or their concatenation with the long address being 1452 encoded first. Which address is carried is determined from the 1453 length of the byte string. 1455 o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a 1456 value different than 0. key_addinfo parameter MUST NOT be 1457 present. 1459 o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter 1460 MUST be set to a value different than 0. key_addinfo parameter 1461 MUST be present. key_addinfo parameter MUST be set to a byte 1462 string, exactly 4 bytes long. key_addinfo parameter carries the 1463 Key Source parameter used to configure [IEEE802.15.4]. 1465 o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter 1466 MUST be set to a value different than 0. key_addinfo parameter 1467 MUST be present. key_addinfo parameter MUST be set to a byte 1468 string, exactly 8 bytes long. key_addinfo parameter carries the 1469 Key Source parameter used to configure [IEEE802.15.4]. 1471 In all cases, key_usage parameter determines how a particular key 1472 should be used in respect to incoming and outgoing security policies. 1474 For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" 1475 parameter of {{IEEE802.15.4} that is signaled in all outgoing frames 1476 secured with a given key. The maximum value key_id can have is 254. 1477 The value of 255 is reserved in {{IEEE802.15.4} and is therefore 1478 considered invalid. 1480 Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a 1481 trusted third party and assign pairwise keys between nodes in the 1482 network. How JRC learns about the network topology is out of scope 1483 of this specification, but could be done through 6LBR - JRC signaling 1484 for example. Pairwise keys could also be derived through a key 1485 agreement protocol executed between the peers directly, where the 1486 authentication is based on the symmetric cryptographic material 1487 provided to both peers by the JRC. Such a protocol is out of scope 1488 of this specification. 1490 8.4.4. Short Identifier 1492 The Short_Identifier object represents an identifier assigned to the 1493 pledge. It is encoded as a CBOR array object, containing, in order: 1495 o identifier: The short identifier assigned to the pledge, encoded 1496 as a byte string. This parameter MUST be included. The 1497 identifier MUST be unique in the set of all identifiers assigned 1498 in a network that is managed by a JRC. In case the identifier is 1499 invalid, the decoder MUST silently ignore the Short_Identifier 1500 object. 1502 o lease_time: The validity of the identifier in hours after the 1503 reception of the CBOR object, encoded as a CBOR unsigned integer. 1504 This parameter MAY be included. The node MUST stop using the 1505 assigned short identifier after the expiry of the lease_time 1506 interval. It is up to the JRC to renew the lease before the 1507 expiry of the previous interval. The JRC updates the lease by 1508 executing the Parameter Update exchange with the node and 1509 including the Short_Identifier in the Configuration object, as 1510 described in Section 8.2. In case the lease expires, the node 1511 SHOULD initiate a new join exchange, as described in Section 8.1. 1512 In case this parameter is omitted, the value of positive infinity 1513 MUST be assumed, meaning that the identifier is valid for as long 1514 as the node participates in the network. 1516 The CDDL fragment that represents the text above for the 1517 Short_Identifier follows. 1519 Short_Identifier = [ 1520 identifier : bstr, 1521 ? lease_time : uint 1522 ] 1524 8.4.4.1. Use in IEEE Std 802.15.4 1526 When Short_Identifier is used in the context of [IEEE802.15.4], the 1527 following considerations apply. 1529 The identifier MUST be used to set the short address of IEEE Std 1530 802.15.4 module. When operating in TSCH mode, the identifier MUST be 1531 unique in the set of all identifiers assigned in multiple networks 1532 that share link-layer key(s). If the length of the byte string 1533 corresponding to the identifier parameter is different than 2, the 1534 identifier is considered invalid. The values 0xfffe and 0xffff are 1535 reserved by [IEEE802.15.4] and their use is considered invalid. 1537 The security properties offered by the [IEEE802.15.4] link-layer in 1538 TSCH mode are conditioned on the uniqueness requirement of the short 1539 identifier (i.e. short address). The short address is one of the 1540 inputs in the construction of the nonce, which is used to protect 1541 link-layer frames. If a misconfiguration occurs, and the same short 1542 address is assigned twice under the same link-layer key, the loss of 1543 security properties is eminent. For this reason, practices where the 1544 pledge generates the short identifier locally are not safe and are 1545 likely to result in the loss of link-layer security properties. 1547 The JRC MUST ensure that at any given time there are never two same 1548 short identifiers being used under the same link-layer key. If the 1549 lease_time parameter of a given Short_Identifier object is set to 1550 positive infinity, care needs to be taken that the corresponding 1551 identifier is not assigned to another node until the JRC is certain 1552 that it is no longer in use, potentially through out-of-band 1553 signaling. If the lease_time parameter expires for any reason, the 1554 JRC should take into consideration potential ongoing transmissions by 1555 the joined node, which may be hanging in the queues, before assigning 1556 the same identifier to another node. 1558 8.4.5. Error Object 1560 The Error object is encoded as a CBOR array object, containing in 1561 order: 1563 o error_code: Error code for the first encountered error while 1564 processing a CoJP object, encoded as an integer. This parameter 1565 MUST be included. Possible values of this parameter are specified 1566 in the IANA "CoJP Error Registry" (Section 11.3). 1568 o error_addinfo: Additional information relevant to the error. This 1569 parameter MUST be included. This parameter MUST be set as 1570 described by the "Additional info" column of the "CoJP Error 1571 Registry" (Section 11.3). 1573 o error_description: Human-readable description of the error, 1574 encoded as a text string. This parameter MAY be included. The 1575 RECOMMENDED setting of this parameter is the "Description" column 1576 of the "CoJP Error Registry" Section 11.3). 1578 The CDDL fragment that represents the text above for the Error object 1579 follows. 1581 Error = [ 1582 error_code : int, 1583 error_addinfo : int / bstr / tstr / nil, 1584 ? error_description : tstr, 1585 ] 1587 +-----------------+-------+---------------+------------+------------+ 1588 | Description | Value | Additional | Additional | Reference | 1589 | | | info | info type | | 1590 +-----------------+-------+---------------+------------+------------+ 1591 | Invalid | 0 | None | nil | [[this | 1592 | Join_Request | | | | document]] | 1593 | object | | | | | 1594 | | | | | | 1595 | Invalid | 1 | None | nil | [[this | 1596 | Configuration | | | | document]] | 1597 | object | | | | | 1598 | | | | | | 1599 | Invalid | 2 | Label of the | int | [[this | 1600 | parameter | | invalid | | document]] | 1601 | | | parameter | | | 1602 | | | | | | 1603 | Invalid link- | 3 | Index of the | uint | [[this | 1604 | layer key | | invalid key | | document]] | 1605 | | | | | | 1606 | Significant | 4 | Next | bstr | [[this | 1607 | OSCORE partial | | acceptable | | document]] | 1608 | IV mismatch | | OSCORE | | | 1609 | | | partial IV | | | 1610 +-----------------+-------+---------------+------------+------------+ 1612 Table 4: CoJP error codes. 1614 8.5. Recommended Settings 1616 This section gives RECOMMENDED values of CoJP settings discussed in 1617 this section. 1619 +--------------------------+---------------+ 1620 | Name | Default Value | 1621 +--------------------------+---------------+ 1622 | COJP_MAX_JOIN_ATTEMPTS | 4 | 1623 | | | 1624 | COJP_REKEYING_GUARD_TIME | 12 seconds | 1625 +--------------------------+---------------+ 1627 Recommended CoJP settings. 1629 The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible 1630 retransmissions at the link layer due to imperfect wireless links. 1632 9. Security Considerations 1634 Since this document uses the pledge identifier to set the ID Context 1635 parameter of OSCORE, an important security requirement is that the 1636 pledge identifier is unique in the set of all pledge identifiers 1637 managed by a JRC. The uniqueness of the pledge identifier ensures 1638 unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also 1639 allows the JRC to retrieve the correct security context, upon the 1640 reception of a Join Request message. The management of pledge 1641 identifiers is simplified if the globally unique EUI-64 is used, but 1642 this comes with privacy risks, as discussed in Section 10. 1644 This document further mandates that the (6LBR) pledge and the JRC are 1645 provisioned with unique PSKs. The PSK is used to set the OSCORE 1646 Master Secret during security context derivation. This derivation 1647 process results in OSCORE keys that are important for mutual 1648 authentication of the (6LBR) pledge and the JRC. Should an attacker 1649 come to know the PSK, then a man-in-the-middle attack is possible. 1651 Many vendors are known to use unsafe practices when generating and 1652 provisioning PSKs. The use of a single PSK shared among a group of 1653 devices is a common pitfall that results in poor security. In this 1654 case, the compromise of a single device is likely to lead to a 1655 compromise of the entire batch, with the attacker having the ability 1656 to impersonate a legitimate device and join the network, generate 1657 bogus data and disturb the network operation. As a reminder, recall 1658 the well-known problem with Bluetooth headsets with a "0000" pin. 1659 Additionally, some vendors use methods such as scrambling or hashing 1660 of device serial numbers or their EUI-64 to generate "unique" PSKs. 1661 Without any secret information involved, the effort that the attacker 1662 needs to invest into breaking these unsafe derivation methods is 1663 quite low, resulting in the possible impersonation of any device from 1664 the batch, without even needing to compromise a single device. The 1665 use of cryptographically secure random number generators to generate 1666 the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms 1667 using deterministic methods. 1669 The JP forwards the unauthenticated join traffic into the network. A 1670 bandwidth cap on the JP prevents it from forwarding more traffic than 1671 the network can handle. The bandwidth cap is configured through the 1672 CoAP's PROBING_RATE parameter. The default values recommended in 1673 this document allow 3 pledges to concurrently join through the same 1674 JP over a window ACK_TIMEOUT long. The use of a bandwidth cap at a 1675 JP forces attackers to use more than one JP if they wish to overwhelm 1676 the network. Marking the join traffic packets with a non-zero DSCP 1677 allows the network to carry the traffic if it has capacity, but 1678 encourages the network to drop the extra traffic rather than add 1679 bandwidth due to that traffic. 1681 The shared nature of the "minimal" cell used for the join traffic 1682 makes the network prone to a DoS attack by congesting the JP with 1683 bogus traffic. Such an attacker is limited by its maximum transmit 1684 power. The redundancy in the number of deployed JPs alleviates the 1685 issue and also gives the pledge a possibility to use the best 1686 available link for joining. How a network node decides to become a 1687 JP is out of scope of this specification. 1689 At the beginning of the join process, the pledge has no means of 1690 verifying the content in the EB, and has to accept it at "face 1691 value". In case the pledge tries to join an attacker's network, the 1692 Join Response message will either fail the security check or time 1693 out. The pledge may implement a temporary blacklist in order to 1694 filter out undesired EBs and try to join using the next seemingly 1695 valid EB. This blacklist alleviates the issue, but is effectively 1696 limited by the node's available memory. Note that this temporary 1697 blacklist is different from the one communicated as part of the CoJP 1698 Configuration object as it helps pledge fight a DoS attack. These 1699 bogus beacons prolong the join time of the pledge, and so the time 1700 spent in "minimal" [RFC8180] duty cycle mode. The blacklist 1701 communicated as part of the CoJP Configuration object helps JP fight 1702 a DoS attack by a malicious pledge. 1704 10. Privacy Considerations 1706 The join solution specified in this document relies on the uniqueness 1707 of the pledge identifier in the set of all pledge identifiers managed 1708 by a JRC. This identifier is transferred in clear as an OSCORE kid 1709 context. The use of the globally unique EUI-64 as pledge identifier 1710 simplifies the management but comes with certain privacy risks. The 1711 implications are thoroughly discussed in [RFC7721] and comprise 1712 correlation of activities over time, location tracking, address 1713 scanning and device-specific vulnerability exploitation. Since the 1714 join process occurs rarely compared to the network lifetime, long- 1715 term threats that arise from using EUI-64 as the pledge identifier 1716 are minimal. In addition, the Join Response message contains a short 1717 address which is assigned by the JRC to the (6LBR) pledge. The 1718 assigned short address SHOULD be uncorrelated with the long-term 1719 pledge identifier. The short address is encrypted in the response. 1720 Once the join process completes, the new node uses the short 1721 addresses for all further layer 2 (and layer-3) operations. This 1722 reduces the aforementioned privacy risks as the short layer-2 address 1723 (visible even when the network is encrypted) is not traceable between 1724 locations and does not disclose the manufacturer, as is the case of 1725 EUI-64. However, an eavesdropper with access to the radio medium 1726 during the join process may be able to correlate the assigned short 1727 address with the extended address based on timing information with a 1728 non-negligible probability. This probability decreases with an 1729 increasing number of pledges joining concurrently. 1731 11. IANA Considerations 1733 Note to RFC Editor: Please replace all occurrences of "[[this 1734 document]]" with the RFC number of this specification. 1736 This document allocates a well-known name under the .arpa name space 1737 according to the rules given in [RFC3172]. The name "6tisch.arpa" is 1738 requested. No subdomains are expected. No A, AAAA or PTR record is 1739 requested. 1741 11.1. CoJP Parameters Registry 1743 This section defines a sub-registries within the "IPv6 over the TSCH 1744 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1745 "Constrained Join Protocol Parameters Registry". 1747 The columns of the registry are: 1749 Name: This is a descriptive name that enables an easier reference to 1750 the item. It is not used in the encoding. 1752 Label: The value to be used to identify this parameter. The label is 1753 an integer. 1755 CBOR type: This field contains the CBOR type for the field. 1757 Description: This field contains a brief description for the field. 1759 Reference: This field contains a pointer to the public specification 1760 for the field, if one exists. 1762 This registry is to be populated with the values in Table 2. 1764 The amending formula for this sub-registry is: Different ranges of 1765 values use different registration policies [RFC8126]. Integer values 1766 from -256 to 255 are designated as Standards Action. Integer values 1767 from -65536 to -257 and from 256 to 65535 are designated as 1768 Specification Required. Integer values greater than 65535 are 1769 designated as Expert Review. Integer values less than -65536 are 1770 marked as Private Use. 1772 11.2. CoJP Key Usage Registry 1774 This section defines a sub-registries within the "IPv6 over the TSCH 1775 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1776 "Constrained Join Protocol Key Usage Registry". 1778 The columns of this registry are: 1780 Name: This is a descriptive name that enables easier reference to the 1781 item. The name MUST be unique. It is not used in the encoding. 1783 Value: This is the value used to identify the key usage setting. 1784 These values MUST be unique. The value is an integer. 1786 Algorithm: This is a descriptive name of the link-layer algorithm in 1787 use and uniquely determines the key length. The name is not used in 1788 the encoding. 1790 Description: This field contains a description of the key usage 1791 setting. The field should describe in enough detail how the key is 1792 to be used with different frame types, specific for the link-layer 1793 technology in question. 1795 Reference: This contains a pointer to the public specification for 1796 the field, if one exists. 1798 This registry is to be populated with the values in Table 3. 1800 The amending formula for this sub-registry is: Different ranges of 1801 values use different registration policies [RFC8126]. Integer values 1802 from -256 to 255 are designated as Standards Action. Integer values 1803 from -65536 to -257 and from 256 to 65535 are designated as 1804 Specification Required. Integer values greater than 65535 are 1805 designated as Expert Review. Integer values less than -65536 are 1806 marked as Private Use. 1808 11.3. CoJP Error Registry 1810 This section defines a sub-registries within the "IPv6 over the TSCH 1811 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1812 "Constrained Join Protocol Error Registry". 1814 The columns of this registry are: 1816 Description: This is a descriptive human-readable name. The 1817 description MUST be unique. It is not used in the encoding. 1819 Value: This is the value used to identify the error. These values 1820 MUST be unique. The value is an integer. 1822 Additional information: This is a descriptive name of additional 1823 information that is meaningful for the error. The name is not used 1824 in the encoding. 1826 Additional information type: A CBOR type of the additional 1827 information field. 1829 Reference: This contains a pointer to the public specification for 1830 the field, if one exists. 1832 This registry is to be populated with the values in Table 4. 1834 The amending formula for this sub-registry is: Different ranges of 1835 values use different registration policies [RFC8126]. Integer values 1836 from -256 to 255 are designated as Standards Action. Integer values 1837 from -65536 to -257 and from 256 to 65535 are designated as 1838 Specification Required. Integer values greater than 65535 are 1839 designated as Expert Review. Integer values less than -65536 are 1840 marked as Private Use. 1842 12. Acknowledgments 1844 The work on this document has been partially supported by the 1845 European Union's H2020 Programme for research, technological 1846 development and demonstration under grant agreements: No 644852, 1847 project ARMOUR; No 687884, project F-Interop and open-call project 1848 SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA. 1850 The following individuals provided input to this document (in 1851 alphabetic order): Tengfei Chang, Klaus Hartke, Tero Kivinen, Jim 1852 Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal Thubert, William 1853 Vignat, Xavier Vilajosana, Thomas Watteyne. 1855 13. References 1857 13.1. Normative References 1859 [I-D.ietf-core-object-security] 1860 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1861 "Object Security for Constrained RESTful Environments 1862 (OSCORE)", draft-ietf-core-object-security-15 (work in 1863 progress), August 2018. 1865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1866 Requirement Levels", BCP 14, RFC 2119, 1867 DOI 10.17487/RFC2119, March 1997, 1868 . 1870 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1871 "Assured Forwarding PHB Group", RFC 2597, 1872 DOI 10.17487/RFC2597, June 1999, 1873 . 1875 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1876 Requirements for the Address and Routing Parameter Area 1877 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1878 September 2001, . 1880 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1881 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1882 October 2013, . 1884 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1885 Application Protocol (CoAP)", RFC 7252, 1886 DOI 10.17487/RFC7252, June 2014, 1887 . 1889 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1890 Writing an IANA Considerations Section in RFCs", BCP 26, 1891 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1892 . 1894 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1895 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1896 . 1898 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1899 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1900 May 2017, . 1902 13.2. Informative References 1904 [I-D.hartke-core-stateless] 1905 Hartke, K., "Extended Tokens and Stateless Clients in the 1906 Constrained Application Protocol (CoAP)", draft-hartke- 1907 core-stateless-02 (work in progress), October 2018. 1909 [I-D.ietf-6tisch-architecture] 1910 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1911 of IEEE 802.15.4", draft-ietf-6tisch-architecture-15 (work 1912 in progress), October 2018. 1914 [I-D.ietf-6tisch-terminology] 1915 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1916 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 1917 draft-ietf-6tisch-terminology-10 (work in progress), March 1918 2018. 1920 [I-D.ietf-cbor-cddl] 1921 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 1922 definition language (CDDL): a notational convention to 1923 express CBOR and JSON data structures", draft-ietf-cbor- 1924 cddl-05 (work in progress), August 2018. 1926 [IEEE802.15.4] 1927 IEEE standard for Information Technology, ., "IEEE Std 1928 802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 1930 [NIST800-90A] 1931 NIST Special Publication 800-90A, Revision 1, ., Barker, 1932 E., and J. Kelsey, "Recommendation for Random Number 1933 Generation Using Deterministic Random Bit Generators", 1934 2015. 1936 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1937 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1938 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1939 . 1941 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1942 "Transmission of IPv6 Packets over IEEE 802.15.4 1943 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1944 . 1946 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1947 Key Derivation Function (HKDF)", RFC 5869, 1948 DOI 10.17487/RFC5869, May 2010, 1949 . 1951 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1952 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1953 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1954 Low-Power and Lossy Networks", RFC 6550, 1955 DOI 10.17487/RFC6550, March 2012, 1956 . 1958 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1959 Bormann, "Neighbor Discovery Optimization for IPv6 over 1960 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1961 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1962 . 1964 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1965 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1966 Internet of Things (IoT): Problem Statement", RFC 7554, 1967 DOI 10.17487/RFC7554, May 2015, 1968 . 1970 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1971 Considerations for IPv6 Address Generation Mechanisms", 1972 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1973 . 1975 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 1976 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 1977 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 1978 May 2017, . 1980 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 1981 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 1982 DOI 10.17487/RFC8480, November 2018, 1983 . 1985 Appendix A. Example 1987 Figure 3 illustrates a successful join protocol exchange. The pledge 1988 instantiates the OSCORE context and derives the OSCORE keys and 1989 nonces from the PSK. It uses the instantiated context to protect the 1990 Join Request addressed with a Proxy-Scheme option, the well-known 1991 host name of the JRC in the Uri-Host option, and its EUI-64 as pledge 1992 identifier and OSCORE kid context. Triggered by the presence of a 1993 Proxy-Scheme option, the JP forwards the request to the JRC and sets 1994 the CoAP token to the internally needed state. The JP has learned 1995 the IPv6 address of the JRC when it acted as a pledge and joined the 1996 network. Once the JRC receives the request, it looks up the correct 1997 context based on the kid context parameter. The OSCORE data 1998 authenticity verification ensures that the request has not been 1999 modified in transit. In addition, replay protection is ensured 2000 through persistent handling of mutable context parameters. 2002 Once the JP receives the Join Response, it authenticates the state 2003 within the CoAP token before deciding where to forward. The JP sets 2004 its internal state to that found in the token, and forwards the Join 2005 Response to the correct pledge. Note that the JP does not possess 2006 the key to decrypt the CBOR object (configuration) present in the 2007 payload. The Join Response is matched to the Join Request and 2008 verified for replay protection at the pledge using OSCORE processing 2009 rules. In this example, the Join Response does not contain the IPv6 2010 address of the JRC, the pledge hence understands the JRC is co- 2011 located with the 6LBR. 2013 <---E2E OSCORE--> 2014 Client Proxy Server 2015 Pledge JP JRC 2016 | | | 2017 | Join | | Code: 0.02 (POST) 2018 | Request | | Token: - 2019 +--------->| | Proxy-Scheme: coap 2020 | | | Uri-Host: 6tisch.arpa 2021 | | | OSCORE: kid: -, 2022 | | | kid_context: EUI-64, 2023 | | | Partial IV: 1 2024 | | | Payload: { Code: 0.02 (POST), 2025 | | | Uri-Path: "j", 2026 | | | join_request, } 2027 | | | 2028 | | Join | Code: 0.02 (POST) 2029 | | Request | Token: opaque state 2030 | +--------->| OSCORE: kid: -, 2031 | | | kid_context: EUI-64, 2032 | | | Partial IV: 1 2033 | | | Payload: { Code: 0.02 (POST), 2034 | | | Uri-Path: "j", 2035 | | | join_request, } 2036 | | | 2037 | | | 2038 | | Join | Code: 2.04 (Changed) 2039 | | Response | Token: opaque state 2040 | |<---------+ OSCORE: - 2041 | | | Payload: { Code: 2.04 (Changed), 2042 | | | configuration, } 2043 | | | 2044 | | | 2045 | Join | | Code: 2.04 (Changed) 2046 | Response | | Token: - 2047 |<---------+ | OSCORE: - 2048 | | | Payload: { Code: 2.04 (Changed), 2049 | | | configuration, } 2050 | | | 2052 Figure 3: Example of a successful join protocol exchange. { ... } 2053 denotes authenticated encryption, denotes the authentication 2054 tag. 2056 Where the join_request object is: 2058 join_request: 2059 { 2060 5 : h'cafe' / PAN ID of the network pledge is attempting to join / 2061 } 2063 Since the role parameter is not present, the default role of "6TiSCH 2064 Node" is implied. 2066 The join_request object encodes to h'a10542cafe' with a size of 5 2067 bytes. 2069 And the configuration object is: 2071 configuration: 2072 { 2073 2 : [ / link-layer key set / 2074 1, / key_id / 2075 h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / 2076 ], 2077 3 : [ / short identifier / 2078 h'af93' / assigned short address / 2079 ] 2080 } 2082 Since the key_usage parameter is not present in the link-layer key 2083 set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. 2084 Since key_addinfo parameter is not present and key_id is different 2085 than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since 2086 the lease_time parameter is not present in the short identifier 2087 object, the default value of positive infinity is implied. 2089 The configuration object encodes to 2091 h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size 2092 of 26 bytes. 2094 Appendix B. Lightweight Implementation Option 2096 In environments where optimizing the implementation footprint is 2097 important, it is possible to implement this specification without 2098 having the implementations of HKDF [RFC5869] and SHA [RFC4231] on 2099 constrained devices. HKDF and SHA are used during the OSCORE 2100 security context derivation phase. This derivation can also be done 2101 by the JRC or a provisioning device, on behalf of the (6LBR) pledge 2102 during the provisioning phase. In that case, the derived OSCORE 2103 security context parameters are written directly into the (6LBR) 2104 pledge, without requiring the PSK be provisioned to the (6LBR) 2105 pledge. 2107 The use of HKDF to derive OSCORE security context parameters ensures 2108 that the resulting OSCORE keys have good security properties, and are 2109 unique as long as the input for different pledges varies. This 2110 specification ensures the uniqueness by mandating unique pledge 2111 identifiers and a unique PSK for each (6LBR) pledge. From the AEAD 2112 nonce reuse viewpoint, having a unique pledge identifier is a 2113 sufficient condition. However, as discussed in Section 9, the use of 2114 a single PSK shared among many devices is a common security pitfall. 2115 The compromise of this shared PSK on a single device would lead to 2116 the compromise of the entire batch. When using the implementation/ 2117 deployment scheme outlined above, the PSK does not need to be written 2118 to individual pledges. As a consequence, even if a shared PSK is 2119 used, the scheme offers the same level of security as in the scenario 2120 where each pledge is provisioned with a unique PSK. 2122 Authors' Addresses 2124 Malisa Vucinic (editor) 2125 Inria 2126 2 Rue Simone Iff 2127 Paris 75012 2128 France 2130 Email: malisa.vucinic@inria.fr 2132 Jonathan Simon 2133 Analog Devices 2134 32990 Alvarado-Niles Road, Suite 910 2135 Union City, CA 94587 2136 USA 2138 Email: jonathan.simon@analog.com 2140 Kris Pister 2141 University of California Berkeley 2142 512 Cory Hall 2143 Berkeley, CA 94720 2144 USA 2146 Email: pister@eecs.berkeley.edu 2147 Michael Richardson 2148 Sandelman Software Works 2149 470 Dawson Avenue 2150 Ottawa, ON K1Z5V7 2151 Canada 2153 Email: mcr+ietf@sandelman.ca