idnits 2.17.1 draft-ietf-6tisch-minimal-security-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 25, 2018) is 2162 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-13 ** 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 (-12) exists of draft-ietf-6tisch-6top-protocol-11 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-14 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-02 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 University of Montenegro 4 Intended status: Standards Track J. Simon 5 Expires: November 26, 2018 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 May 25, 2018 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-06 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, a new Stateless-Proxy CoAP option, and configures the 31 rest of the 6TiSCH communication stack for this join process to occur 32 in a secure manner. Additional security mechanisms may be added on 33 top of this minimal framework. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 26, 2018. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 5 72 5. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 73 5.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 74 5.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 75 5.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 76 5.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 77 6. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 78 7. Network-layer Configuration . . . . . . . . . . . . . . . . . 10 79 7.1. Identification of Join Request Traffic . . . . . . . . . 11 80 7.2. Identification of Join Response Traffic . . . . . . . . . 12 81 8. Application-level Configuration . . . . . . . . . . . . . . . 12 82 8.1. OSCORE Security Context . . . . . . . . . . . . . . . . . 13 83 9. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 15 84 9.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 16 85 9.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 18 86 9.3. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 19 87 9.4. Parameters . . . . . . . . . . . . . . . . . . . . . . . 27 88 9.5. Mandatory to Implement Algorithms . . . . . . . . . . . . 28 89 10. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . . . 28 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 91 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 93 13.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 31 94 13.2. CoJP Parameters Registry . . . . . . . . . . . . . . . . 31 95 13.3. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 31 96 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 97 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 98 15.1. Normative References . . . . . . . . . . . . . . . . . . 33 99 15.2. Informative References . . . . . . . . . . . . . . . . . 33 100 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 35 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 103 1. Introduction 105 This document presumes a 6TiSCH network as described by [RFC7554] and 106 [RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their 107 radio turned off most of the time, to conserve energy. As a 108 consequence, the link used by a new device for joining the network 109 has limited bandwidth [RFC8180]. The secure join solution defined in 110 this document therefore keeps the number of over-the-air exchanges 111 for join purposes to a minimum. 113 The micro-controllers at the heart of 6TiSCH nodes have a small 114 amount of code memory. It is therefore paramount to reuse existing 115 protocols available as part of the 6TiSCH stack. At the application 116 layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web 117 transfer, and on OSCORE [I-D.ietf-core-object-security] for its end- 118 to-end security. The secure join solution defined in this document 119 therefore reuses those two protocols as its building blocks. 121 This document defines a secure join solution for a new device, called 122 "pledge", to securely join a 6TiSCH network. The specification 123 defines the Constrained Join Protocol (CoJP) used by the pledge to 124 request admission into a network managed by the JRC, and for the JRC 125 to configure the pledge with the necessary parameters and update them 126 at a later time, a new CoAP option, and configures different layers 127 of the 6TiSCH protocol stack for the join process to occur in a 128 secure manner. 130 The Constrained Join Protocol defined in this document is generic and 131 can be used as-is in modes of IEEE Std 802.15.4 other than TSCH, that 132 6TiSCH is based on. The Constrained Join Protocol may as well be 133 used in other (low-power) networking technologies where efficiency in 134 terms of communication overhead and code footprint is important. In 135 such a case, it may be necessary to register configuration parameters 136 specific to the technology in question, through the IANA process. 137 The overall join process described in Section 5 and the configuration 138 of the stack is, however, specific to 6TiSCH. 140 The Constrained Join Protocol assumes the presence of a JRC (join 141 registrar/coordinator), a central entity. It further assumes that 142 the pledge and the JRC share a symmetric key, called PSK (pre-shared 143 key). The PSK is used to configure OSCORE to provide a secure 144 channel to CoJP. How the PSK is installed is out of scope of this 145 document: this may happen through the one-touch provisioning process 146 or by a key exchange protocol that may precede the execution of the 147 6TiSCH Join protocol. 149 When the pledge seeks admission to a 6TiSCH network, it first 150 synchronizes to it, by initiating the passive scan defined in 151 [IEEE802.15.4]. The pledge then exchanges messages with the JRC; 152 these messages can be forwarded by nodes already part of the 6TiSCH 153 network. The messages exchanged allow the JRC and the pledge to 154 mutually authenticate, based on the PSK. They also allow the JRC to 155 configure the pledge with link-layer keying material, link-layer 156 short address and other parameters. After this secure join process 157 successfully completes, the joined node can interact with its 158 neighbors to request additional bandwidth using the 6top Protocol 159 [I-D.ietf-6tisch-6top-protocol] and start sending the application 160 traffic. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. These 167 words may also appear in this document in lowercase, absent their 168 normative meanings. 170 The reader is expected to be familiar with the terms and concepts 171 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 172 [I-D.ietf-core-object-security], and [RFC8152]. 174 The specification also includes a set of informative specifications 175 using the Concise data definition language (CDDL) 176 [I-D.ietf-cbor-cddl]. 178 The following terms defined in [I-D.ietf-6tisch-terminology] are used 179 extensively throughout this document: 181 o pledge 183 o joined node 185 o join proxy (JP) 187 o join registrar/coordinator (JRC) 189 o enhanced beacon (EB) 191 o join protocol 192 o join process 194 The following terms defined in [RFC6775] are also used throughout 195 this document: 197 o 6LoWPAN Border Router (6LBR) 199 The term "6LBR" is used interchangeably with the term "DODAG root" 200 defined in [RFC6550], assuming the two entities are co-located, as 201 recommended by [I-D.ietf-6tisch-architecture]. 203 The term "pledge", as used throughout the document, explicitly 204 denotes non-6LBR devices attempting to join over an IEEE Std 802.15.4 205 network interface. The device that attempts to join as the 6LBR of 206 the network and does so over another network interface is explicitly 207 denoted as the "6LBR pledge". When the text equally applies to the 208 pledge and the 6LBR pledge, the "(6LBR) pledge" form is used. 210 In addition, we use the generic terms "network identifier" and 211 "pledge identifier". See Section 3. 213 3. Identifiers 215 The "network identifier" uniquely identifies the 6TiSCH network in 216 the namespace managed by a JRC. Typically, this is the 16-bit 217 Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4]. 218 Companion documents can specify the use of a different network 219 identifier for join purposes, but this is out of scope of this 220 specification. Such identifier needs to be carried within Enhanced 221 Beacon (EB) frames. 223 The "pledge identifier" uniquely identifies the (6LBR) pledge in the 224 namespace managed by a JRC. The pledge identifier is typically the 225 globally unique 64-bit Extended Unique Identifier (EUI-64) of the 226 IEEE Std 802.15.4 device. This identifier is used to generate the 227 IPv6 addresses of the (6LBR) pledge and to identify it during the 228 execution of the join protocol. For privacy reasons, it is possible 229 to use an identifier different from the EUI-64 (e.g. a random 230 string). See Section 12. 232 4. One-Touch Assumption 234 This document assumes a one-touch scenario. The (6LBR) pledge is 235 provisioned with certain parameters before attempting to join the 236 network, and the same parameters are provisioned to the JRC. 238 There are many ways by which this provisioning can be done. 239 Physically, the parameters can be written into the (6LBR) pledge 240 using a number of mechanisms, such as a JTAG interface, a serial 241 (craft) console interface, pushing buttons simultaneously on 242 different devices, over-the-air configuration in a Faraday cage, etc. 243 The provisioning can be done by the vendor, the manufacturer, the 244 integrator, etc. 246 Details of how this provisioning is done is out of scope of this 247 document. What is assumed is that there can be a secure, private 248 conversation between the JRC and the (6LBR) pledge, and that the two 249 devices can exchange the parameters. 251 Parameters that are provisioned to the (6LBR) pledge include: 253 o Pre-Shared Key (PSK). The JRC additionally needs to store the 254 pledge identifier bound to the given PSK. The PSK SHOULD be at 255 least 128 bits in length, generated uniformly at random. It is 256 RECOMMENDED to generate the PSK with a cryptographically secure 257 pseudorandom number generator. Each (6LBR) pledge SHOULD be 258 provisioned with a unique PSK. 260 o Optionally, a network identifier. Provisioning the network 261 identifier is RECOMMENDED. However, due to the operational 262 constraints the network identifier may not be known at the time 263 when the provisioning is done. In case this parameter is not 264 provisioned to the pledge, the pledge attempts to join one network 265 at a time, which significantly prolongs the join process. In case 266 this parameter is not provisioned to the 6LBR pledge, the 6LBR 267 pledge can receive it from the JRC as part of the join protocol. 269 o Optionally, any non-default algorithms. The default algorithms 270 are specified in Section 9.5. When algorithm identifiers are not 271 exchanged, the use of these default algorithms is implied. 273 Additionally, the 6LBR pledge that is not co-located with the JRC 274 needs to be provisioned with: 276 o Global IPv6 address of the JRC. This address is used by the 6LBR 277 pledge to address the JRC during the join process. The 6LBR 278 pledge may also obtain the IPv6 address of the JRC through other 279 available mechanisms, such as DHCPv6, GRASP, mDNS, the use of 280 which is out of scope of this document. Pledges do not need to be 281 provisioned with this address as they discover it dynamically 282 during the join process. 284 5. Join Process Overview 286 This section describes the steps taken by a pledge in a 6TiSCH 287 network. When a pledge seeks admission to a 6TiSCH network, the 288 following exchange occurs: 290 1. The pledge listens for an Enhanced Beacon (EB) frame 291 [IEEE802.15.4]. This frame provides network synchronization 292 information, and tells the device when it can send a frame to the 293 node sending the beacons, which plays the role of Join Proxy (JP) 294 for the pledge, and when it can expect to receive a frame. The 295 Enhanced Beacon provides the L2 address of the JP and it may also 296 provide its link-local IPv6 address. 298 2. The pledge configures its link-local IPv6 address and advertises 299 it to the JP using Neighbor Discovery. This step may be omitted 300 if the link-local address has been derived from a known unique 301 interface identifier, such as an EUI-64 address. 303 3. The pledge sends a Join Request to the JP in order to securely 304 identify itself to the network. The Join Request is forwarded to 305 the JRC. 307 4. In case of successful processing of the request, the pledge 308 receives a Join Response from the JRC (via the JP). The Join 309 Response contains configuration parameters necessary for the 310 pledge to join the network. 312 From the pledge's perspective, joining is a local phenomenon - the 313 pledge only interacts with the JP, and it needs not know how far it 314 is from the 6LBR, or how to route to the JRC. Only after 315 establishing one or more link-layer keys does it need to know about 316 the particulars of a 6TiSCH network. 318 The join process is shown as a transaction diagram in Figure 1: 320 +--------+ +-------+ +--------+ 321 | pledge | | JP | | JRC | 322 | | | | | | 323 +--------+ +-------+ +--------+ 324 | | | 325 |<---Enhanced Beacon (1)---| | 326 | | | 327 |<-Neighbor Discovery (2)->| | 328 | | | 329 |-----Join Request (3a)----|----Join Request (3a)---->| \ 330 | | | | CoJP 331 |<----Join Response (3b)---|----Join Response (3b)----| / 332 | | | 334 Figure 1: Overview of a successful join process. CoJP stands for 335 Constrained Join Protocol. 337 As other nodes in the network, the 6LBR node plays the role of the 338 JP. The 6LBR may in addition be co-located with the JRC. 340 The details of each step are described in the following sections. 342 5.1. Step 1 - Enhanced Beacon 344 The pledge synchronizes to the network by listening for, and 345 receiving, an Enhanced Beacon (EB) sent by a node already in the 346 network. This process is entirely defined by [IEEE802.15.4], and 347 described in [RFC7554]. 349 Once the pledge hears an EB, it synchronizes to the joining schedule 350 using the cells contained in the EB. The pledge can hear multiple 351 EBs; the selection of which EB to use is out of the scope for this 352 document, and is discussed in [RFC7554]. Implementers should make 353 use of information such as: what network identifier the EB contains, 354 whether the source link-layer address of the EB has been tried 355 before, what signal strength the different EBs were received at, etc. 356 In addition, the pledge may be pre-configured to search for EBs with 357 a specific network identifier. 359 If the pledge is not provisioned with the network identifier, it 360 attempts to join one network at a time, as described in 361 Section 9.1.3. 363 Once the pledge selects the EB, it synchronizes to it and transitions 364 into a low-power mode. It follows the provided schedule which 365 indicates the slots that the pledge may use for the join process. 366 During the remainder of the join process, the node that has sent the 367 EB to the pledge plays the role of JP. 369 At this point, the pledge may proceed to step 2, or continue to 370 listen for additional EBs. 372 5.2. Step 2 - Neighbor Discovery 374 The pledge forms its link-local IPv6 address based on the interface 375 identifier, as per [RFC4944]. The pledge MAY perform the Neighbor 376 Solicitation / Neighbor Advertisement exchange with the JP, as per 377 Section 5.5.1 of [RFC6775]. The pledge and the JP use their link- 378 local IPv6 addresses for all subsequent communication during the join 379 process. 381 Note that Neighbor Discovery exchanges at this point are not 382 protected with link-layer security as the pledge is not in possession 383 of the keys. How JP accepts these unprotected frames is discussed in 384 Section 6. 386 5.3. Step 3 - Constrained Join Protocol (CoJP) Execution 388 The pledge triggers the join exchange of the Constrained Join 389 Protocol (CoJP). The join exchange consists of two messages: the 390 Join Request message (Step 3a), and the Join Response message 391 conditioned on the successful security processing of the request 392 (Step 3b). All CoJP messages are exchanged over a secure channel 393 that provides confidentiality, data authenticity and replay 394 protection. 396 5.3.1. Step 3a - Join Request 398 The Join Request is a message sent from the pledge to the JP, and 399 which the JP forwards to the JRC. The pledge indicates in the Join 400 Request the role it requests to play in the network as well as the 401 identifier of the network it requests to join. The JP forwards the 402 Join Request to the JRC on the existing 6TiSCH network. How exactly 403 this happens is out of scope of this document; some networks may wish 404 to dedicate specific slots for this join traffic. 406 5.3.2. Step 3b - Join Response 408 The Join Response is sent by the JRC to the pledge, and is forwarded 409 through the JP. The packet containing the Join Response travels from 410 the JRC to JP using the operating routes in the 6TiSCH network. The 411 JP delivers it to the pledge. The JP operates as the application- 412 layer proxy, and does not keep any state to forward the message. 414 The Join Response contains different parameters needed by the pledge 415 to become a fully operational network node. For example, these 416 parameters are the link-layer key(s) currently in use in the network, 417 the short link-layer address assigned to the pledge, the IPv6 address 418 of the JRC needed by the pledge to operate as the JP, and others. 420 5.4. The Special Case of the 6LBR Pledge Joining 422 The 6LBR pledge performs Section 5.3 of the join process described 423 above, just as any other pledge, albeit over another network 424 interface. There is no JP intermediating the communication between 425 the 6LBR pledge and the JRC, as described in Section 7. The other 426 steps of the described join process do not apply to the 6LBR pledge. 427 How the 6LBR pledge obtains an IPv6 address and triggers the 428 execution of the CoJP protocol is out of scope of this document. 430 6. Link-layer Configuration 432 In an operational 6TiSCH network, all frames MUST use link-layer 433 frame security [RFC8180]. The IEEE Std 802.15.4 security attributes 434 MUST include frame authenticity, and MAY include frame 435 confidentiality (i.e. encryption). 437 The pledge does not initially do any authenticity check of the EB 438 frames, as it does not possess the link-layer key(s) in use. The 439 pledge is still able to parse the contents of the received EBs and 440 synchronize to the network, as EBs are not encrypted [RFC8180]. 442 When sending frames during the join process, the pledge sends 443 unencrypted and unauthenticated frames. The JP accepts these 444 unsecured frames for the duration of the join process. This behavior 445 may be implemented by setting the "secExempt" attribute in the IEEE 446 Std 802.15.4 security configuration tables. How the JP learns 447 whether the join process is ongoing is out of scope of this 448 specification. 450 As the EB itself cannot be authenticated by the pledge, an attacker 451 may craft a frame that appears to be a valid EB, since the pledge can 452 neither verify the freshness nor verify the address of the JP. This 453 opens up a possibility of DoS attack, as discussed in Section 11. 455 7. Network-layer Configuration 457 The pledge and the JP SHOULD keep a separate neighbor cache for 458 untrusted entries and use it to store each other's information during 459 the join process. Mixing neighbor entries belonging to pledges and 460 nodes that are part of the network opens up the JP to a DoS attack, 461 as the attacker may fill JP's neighbor table and prevent the 462 discovery of legitimate neighbors. How the pledge and the JP decide 463 to transition each other from untrusted to trusted cache, once the 464 join process completes, is out of scope. One implementation 465 technique is to use the information whether the incoming frames are 466 secured at the link layer. 468 The pledge does not communicate with the JRC at the network layer. 469 This allows the pledge to join without knowing the IPv6 address of 470 the JRC. Instead, the pledge communicates with the JP at the network 471 layer using link-local addressing, and with the JRC at the 472 application layer, as specified in Section 8. 474 The JP communicates with the JRC over global IPv6 addresses. The JP 475 discovers the network IPv6 prefix and configures its global IPv6 476 address upon successful completion of the join process and the 477 obtention of link-layer keys. The pledge learns the actual IPv6 478 address of the JRC from the Join Response, as specified in 479 Section 9.1.2; it uses it once joined in order to operate as a JP. 481 As a special case, the 6LBR pledge is expected to have an additional 482 network interface that it uses in order to obtain the configuration 483 parameters from the JRC and start advertising the 6TiSCH network. 484 This additional interface needs to be configured with a global IPv6 485 address, by a mechanism that is out of scope of this document. The 486 6LBR pledge uses this interface to directly communicate with the JRC 487 using global IPv6 addressing. 489 The JRC can be co-located on the 6LBR. In this special case, the 490 IPv6 address of the JRC can be omitted from the Join Response message 491 for space optimization. The 6LBR then MUST set the DODAGID field in 492 the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the 493 address of the JRC once joined and upon the reception of the first 494 RPL DIO message, and uses it to operate as a JP. 496 7.1. Identification of Join Request Traffic 498 The join request traffic that is proxied by the Join Proxy (JP) comes 499 from unauthenticated nodes, and there may be an arbitrary amount of 500 it. In particular, an attacker may send fraudulent traffic in 501 attempt to overwhelm the network. 503 When operating as part of a [RFC8180] 6TiSCH minimal network using 504 distributed scheduling algorithms, the join request traffic present 505 may cause intermediate nodes to request additional bandwidth. An 506 attacker could use this property to cause the network to overcommit 507 bandwidth (and energy) to the join process. 509 The Join Proxy is aware of what traffic is join request traffic, and 510 so can avoid allocating additional bandwidth itself. The Join Proxy 511 SHOULD implement a bandwidth cap on outgoing join request traffic. 512 This cap will not protect intermediate nodes as they can not tell 513 join request traffic from regular traffic. Despite the bandwidth cap 514 implemented separately on each Join Proxy, the aggregate join request 515 traffic from many Join Proxies may cause intermediate nodes to decide 516 to allocate additional cells. It is undesirable to do so in response 517 to the join request traffic. In order to permit the intermediate 518 nodes to avoid this, the traffic needs to be tagged. 520 [RFC2597] defines a set of per-hop behaviors that may be encoded into 521 the Diffserv Code Points (DSCPs). The Join Proxy SHOULD set the DSCP 522 of join request packets that it produces as part of the relay process 523 to AF43 code point (See Section 6 of [RFC2597]). 525 A Join Proxy that does not set the DSCP on traffic forwarded should 526 set it to zero so that it is compressed out. 528 A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT 529 allocate additional cells as a result of traffic with code point 530 AF43. Companion SF documents SHOULD specify how this recommended 531 behavior is achieved. 533 7.2. Identification of Join Response Traffic 535 The JRC SHOULD set the DSCP of join response packets addressed to the 536 Join Proxy to AF42 code point. Join response traffic can not be 537 induced by an attacker as it is generated only in response to 538 legitimate pledges (see Section 9.1.3). AF42 has lower drop 539 probability than AF43, giving join response traffic priority in 540 buffers over join request traffic. 542 Due to the convergecast nature of the DODAG, the 6LBR links are often 543 the most congested, and from that point down there is progressively 544 less (or equal) congestion. If the 6LBR paces itself when sending 545 join response traffic then it ought to never exceed the bandwidth 546 allocated to the best effort traffic cells. If the 6LBR has the 547 capacity (if it is not constrained) then it should provide some 548 buffers in order to satisfy the Assured Forwarding behavior. 550 Companion SF documents SHOULD specify how traffic with code point 551 AF42 is handled with respect to cell allocation. 553 8. Application-level Configuration 555 The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and 556 the secure channel provided by OSCORE 557 [I-D.ietf-core-object-security]. The (6LBR) pledge plays the role of 558 a CoAP client; the JRC plays the role of a CoAP server. The JP 559 implements CoAP forward proxy functionality [RFC7252]. Because the 560 JP can also be a constrained device, it cannot implement a cache. If 561 the JP used the stateful CoAP proxy defined in [RFC7252], it would be 562 prone to Denial-of-Service (DoS) attacks, due to its limited memory. 563 Rather, the JP processes forwarding-related CoAP options and makes 564 requests on behalf of the pledge, in a stateless manner by using the 565 Stateless-Proxy option defined in this document. 567 The pledge designates a JP as a proxy by including the Proxy-Scheme 568 option in CoAP requests it sends to the JP. The pledge also includes 569 in the requests the Uri-Host option with its value set to the well- 570 known JRC's alias, as specified in Section 9.1.1. 572 The JP resolves the alias to the IPv6 address of the JRC that it 573 learned when it acted as a pledge, and joined the network. This 574 allows the JP to reach the JRC at the network layer and forward the 575 requests on behalf of the pledge. 577 The JP MUST add a Stateless-Proxy option to all the requests that it 578 forwards on behalf of the pledge as part of the join process. 580 The value of the Stateless-Proxy option is set to the internal JP 581 state, needed to forward the Join Response message to the pledge. 582 The Stateless-Proxy option handling is defined in Section 10. 584 The JP also tags all packets carrying the Join Request message at the 585 network layer, as specified in Section 7.1. 587 8.1. OSCORE Security Context 589 Before the (6LBR) pledge and the JRC may start exchanging CoAP 590 messages protected with OSCORE, they need to derive the OSCORE 591 security context from the parameters provisioned out-of-band, as 592 discussed in Section 4. 594 The OSCORE security context MUST be derived as per Section 3 of 595 [I-D.ietf-core-object-security]. 597 o the Master Secret MUST be the PSK. 599 o the Master Salt MUST be empty. 601 o the ID of the pledge MUST be set to the byte string 0x00. This 602 identifier is used as the OSCORE Sender ID in the security context 603 derivation, as the pledge initially plays the role of a CoAP 604 client. 606 o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" 607 in ASCII). This identifier is used as the OSCORE Recipient ID in 608 the security context derivation, as the JRC initially plays the 609 role of a CoAP server. 611 o the ID Context MUST be set to the pledge identifier. 613 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 614 of-band by the same mechanism used to provision the PSK. The 615 default is AES-CCM-16-64-128. 617 o the Key Derivation Function MUST be agreed out-of-band. Default 618 is HKDF SHA-256 [RFC5869]. 620 The derivation in [I-D.ietf-core-object-security] results in traffic 621 keys and a common IV for each side of the conversation. Nonces are 622 constructed by XOR'ing the common IV with the current sequence number 623 and sender identifier. For details on nonce construction, refer to 624 [I-D.ietf-core-object-security]. 626 Implementations MUST ensure that multiple CoAP requests to different 627 JRCs result in the use of the same OSCORE context, so that the 628 sequence numbers are properly incremented for each request. The 629 pledge typically sends requests to different JRCs if it is not 630 provisioned with the network identifier and attempts to join one 631 network at a time. A simple implementation technique is to 632 instantiate the OSCORE security context with a given PSK only once 633 and use it for all subsequent requests. Failure to comply will break 634 the confidentiality property of the Authenticated Encryption with 635 Associated Data (AEAD) algorithm due to the nonce reuse. 637 This OSCORE security context is used for initial joining of the 638 (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well 639 as for any later parameter updates, where the JRC acts as a CoAP 640 client and the joined node as a CoAP server, as discussed in 641 Section 9.2. A (6LBR) pledge is expected to have exactly one OSCORE 642 security context with the JRC. 644 8.1.1. Persistency 646 Implementations MUST ensure that mutable OSCORE context parameters 647 (Sender Sequence Number, Replay Window) are stored in persistent 648 memory. A technique that prevents reuse of sequence numbers, 649 detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be 650 implemented. Each update of the OSCORE Replay Window MUST be written 651 to persistent memory. 653 This is an important security requirement in order to guarantee nonce 654 uniqueness and resistance to replay attacks across reboots and 655 rejoins. Traffic between the (6LBR) pledge and the JRC is rare, 656 making security outweigh the cost of writing to persistent memory. 658 9. Constrained Join Protocol (CoJP) 660 Constrained Join Protocol (CoJP) is a lightweight protocol over CoAP 661 [RFC7252] and a secure channel provided by OSCORE 662 [I-D.ietf-core-object-security]. CoJP allows the (6LBR) pledge to 663 request admission into a network managed by the JRC, and for the JRC 664 to configure the pledge with the parameters necessary for joining the 665 network, or advertising it in the case of 6LBR pledge. The JRC may 666 update the parameters at any time, by reaching out to the joined node 667 that formerly acted as a (6LBR) pledge. For example, network-wide 668 rekeying can be implemented by updating the keying material on each 669 node. 671 This section specifies how the CoJP messages are mapped to CoAP and 672 OSCORE, CBOR data structures carrying different parameters, 673 transported within CoAP payload, and the parameter semantics and 674 processing rules. 676 CoJP relies on the security properties provided by OSCORE. This 677 includes end-to-end confidentiality, data authenticity, replay 678 protection, and a secure binding of responses to requests. 680 +-----------------------------------+ 681 | Constrained Join Protocol (CoJP) | 682 +-----------------------------------+ 683 +-----------------------------------+ \ 684 | Requests / Responses | | 685 |-----------------------------------| | 686 | OSCORE | | CoAP 687 |-----------------------------------| | 688 | Messaging Layer / Message Framing | | 689 +-----------------------------------+ / 690 +-----------------------------------+ 691 | UDP | 692 +-----------------------------------+ 694 Figure 2: Abstract layering of CoJP. 696 When a (6LBR) pledge requests admission to a given network, it 697 undergoes the CoJP join exchange that consists of: 699 o the Join Request message, sent by the (6LBR) pledge to the JRC, 700 potentially proxied by the JP. The Join Request message and its 701 mapping to CoAP is specified in Section 9.1.1. 703 o the Join Response message, sent by the JRC to the (6LBR) pledge if 704 the JRC successfully processes the Join Request using OSCORE and 705 it determines through a mechanism that is out of scope of this 706 specification that the (6LBR) pledge is authorized to join the 707 network. The Join Response message is potentially proxied by the 708 JP. The Join Response message and its mapping to CoAP is 709 specified in Section 9.1.2. 711 When the JRC needs to update the parameters of a joined node that 712 formerly acted as a (6LBR) pledge, it executes the CoJP parameter 713 update exchange that consists of: 715 o the Parameter Update message, sent by the JRC to the joined node 716 that formerly acted as a (6LBR) pledge. The Parameter Update 717 message and its mapping to CoAP is specified in Section 9.2.1. 719 o the Parameter Update Response message, sent by the joined node to 720 the JRC in response to the Parameter Update message to signal 721 successful reception of the updated parameters. The Parameter 722 Update Response message and its mapping to CoAP is specified in 723 Section 9.2.2. 725 The payload of CoJP messages is encoded with CBOR [RFC7049]. The 726 CBOR data structures that may appear as the payload of different CoJP 727 messages are specified in Section 9.3. 729 9.1. Join Exchange 731 This section specifies the messages exchanged when the (6LBR) pledge 732 requests admission and configuration parameters from the JRC. 734 9.1.1. Join Request Message 736 The Join Request message SHALL be mapped to a CoAP request: 738 o The request method is POST. 740 o The type is Non-confirmable (NON). 742 o The Proxy-Scheme option is set to "coap". 744 o The Uri-Host option is set to "6tisch.arpa". This is an anycast 745 type of identifier of the JRC that is resolved to its IPv6 address 746 by the JP or the 6LBR pledge. 748 o The Uri-Path option is set to "j". 750 o The Object-Security option SHALL be set according to 751 [I-D.ietf-core-object-security]. The OSCORE security context used 752 is the one derived in Section 8.1. The OSCORE kid context is set 753 to the ID context, which in turn is set to the pledge identifier. 754 The OSCORE kid context allows the JRC to retrieve the security 755 context for a given pledge. 757 o The payload is a Join_Request CBOR object, as defined in 758 Section 9.3.1. 760 9.1.2. Join Response Message 762 The Join Response message that the JRC sends SHALL be mapped to a 763 CoAP response: 765 o The response Code is 2.04 (Changed). 767 o The payload is a Configuration CBOR object, as defined in 768 Section 9.3.2. 770 9.1.3. Error Handling and Retransmission 772 Since the Join Request is mapped to a Non-confirmable CoAP message, 773 OSCORE processing at the JRC will silently drop the request in case 774 of a failure. This may happen for a number of reasons, including 775 failed lookup of an appropriate security context (e.g. the pledge 776 attempting to join a wrong network), failed decryption, positive 777 replay window lookup, formatting errors (possibly due to malicious 778 alterations in transit). Silently dropping the Join Request at the 779 JRC prevents a DoS attack where an attacker could force the pledge to 780 attempt joining one network at a time, until all networks have been 781 tried. 783 Using a Non-confirmable CoAP message to transport the Join Request 784 also helps minimize the required CoAP state at the pledge and the 785 Join Proxy, keeping it to a minimum typically needed to perform CoAP 786 congestion control. It does, however, introduce some complexity as 787 the pledge needs to implement a retransmission mechanism. 789 The following binary exponential back-off algorithm is inspired by 790 the one described in [RFC7252]. For each Join Request the pledge 791 sends while waiting for a Join Response, the pledge MUST keep track 792 of a timeout and a retransmission counter. For a new Join Request, 793 the timeout is set to a random value between TIMEOUT_BASE and 794 (TIMEOUT_BASE * TIMEOUT_RANDOM_FACTOR). The retransmission counter 795 is set to 0. When the timeout is triggered and the retransmission 796 counter is less than MAX_RETRANSMIT, the Join Request is 797 retransmitted, the retransmission counter is incremented, and the 798 timeout is doubled. Note that the retransmitted Join Request passes 799 new OSCORE processing, such that the sequence number in the OSCORE 800 context is properly incremented. If the retransmission counter 801 reaches MAX_RETRANSMIT on a timeout, the pledge SHOULD attempt to 802 join the next advertised 6TiSCH network. If the pledge receives a 803 Join Response that successfully passes OSCORE processing, it cancels 804 the pending timeout and processes the response. The pledge MUST 805 silently discard any response not protected with OSCORE, including 806 error codes. For default values of retransmission parameters, see 807 Section 9.4. 809 If all join attempts to advertised networks have failed, the pledge 810 SHOULD signal to the user the presence of an error condition, through 811 some out-of-band mechanism. 813 9.2. Parameter Update Exchange 815 During the network lifetime, parameters returned as part of the Join 816 Response may need to be updated. One typical example is the update 817 of link-layer keying material for the network, a process known as 818 rekeying. This section specifies a generic mechanism when this 819 parameter update is initiated by the JRC. 821 At the time of the join, the (6LBR) pledge acts as a CoAP client and 822 requests the network parameters through a representation of the "/j" 823 resource, exposed by the JRC. In order for the update of these 824 parameters to happen, the JRC needs to asynchronously contact the 825 joined node. The use of the CoAP Observe option for this purpose is 826 not feasible due to the change in the IPv6 address when the pledge 827 becomes the joined node and obtains a global address. 829 Instead, once the (6LBR) pledge receives and successfully validates 830 the Join Response and so becomes a joined node, it switches its CoAP 831 role and becomes a server. The joined node exposes the "/j" resource 832 that is used by the JRC to update the parameters. Consequently, the 833 JRC operates as a CoAP client when updating the parameters. The 834 request/response exchange between the JRC and the (6LBR) pledge 835 happens over the already-established OSCORE secure channel. 837 9.2.1. Parameter Update Message 839 The Parameter Update message that the JRC sends to the joined node 840 SHALL be mapped to a CoAP request: 842 o The request method is POST. 844 o The type is Confirmable (CON). 846 o The Uri-Path option is set to "j". 848 o The Object-Security option SHALL be set according to 849 [I-D.ietf-core-object-security]. The OSCORE security context used 850 is the one derived in Section 8.1. When a joined node receives a 851 request with the Sender ID set to 0x4a5243 (ID of the JRC), it is 852 able to correctly retrieve the security context with the JRC. 854 o The payload is a Configuration CBOR object, as defined in 855 Section 9.3.2. 857 The JRC has implicit knowledge on the global IPv6 address of the 858 joined node, as it knows the pledge identifier that the joined node 859 used when it acted as a pledge, and the IPv6 network prefix. The JRC 860 uses this implicitly derived IPv6 address of the joined node to 861 directly address CoAP messages to it. 863 9.2.2. Parameter Update Response Message 865 The Parameter Update Response message that the joined node sends to 866 the JRC SHALL be mapped to a CoAP response: 868 o The response Code is 2.04 (Changed). 870 o The payload is empty. 872 9.3. CoJP Objects 874 This section specifies the structure of CoJP CBOR objects that may be 875 carried as the payload of CoJP messages. Some of these objects may 876 be received both as part of the CoJP join exchange when the device 877 operates as a (CoJP) pledge, or the parameter update exchange, when 878 the device operates as a joined (6LBR) node. 880 9.3.1. Join Request Object 882 The Join_Request structure is built on a CBOR map object. 884 The set of parameters that can appear in a Join_Request object is 885 summarized below. The defined labels can be found below, the details 886 of this registry are in section "CoJP Parameters" registry 887 Section 13.2. 889 o role: The identifier of the role that the pledge requests to play 890 in the network once it joins, encoded as an unsigned integer. 891 Possible values are specified in Table 1. This parameter MAY be 892 included. In case the parameter is omitted, the default value of 893 0, i.e. the role "6TiSCH Node", MUST be assumed. 895 o network identifier: The identifier of the network, as discussed in 896 Section 3, encoded as a CBOR byte string. This parameter may 897 appear both in the Join Request and in the Join Response. When 898 present in the Join Request, it hints to the JRC the network that 899 the pledge is requesting to join, enabling the JRC to manage 900 multiple networks. The pledge obtains the value of the network 901 identifier from the received EB frames. This parameter MUST be 902 included in a Join_Request object if the role parameter is set to 903 "6TiSCH Node". This parameter MAY be included if the role 904 parameter is set to "6LBR". The inclusion of this parameter by 905 the 6LBR pledge depends on whether the parameter was exchanged 906 during the one-touch process, which in turn depends on the 907 operational constraints. 909 The CDDL fragment that represents the text above for the Join_Request 910 follows. 912 Join_Request = { 913 ? 1 : uint ; role 914 ? 5 : bstr ; network identifier 915 } 917 +--------+-------+-------------------------------------+------------+ 918 | Name | Value | Description | Reference | 919 +--------+-------+-------------------------------------+------------+ 920 | 6TiSCH | 0 | The pledge requests to play the | [[this | 921 | Node | | role of a regular 6TiSCH node, i.e. | document]] | 922 | | | non-6LBR node. | | 923 | | | | | 924 | 6LBR | 1 | The pledge requests to play the | [[this | 925 | | | role of 6LoWPAN Border Router | document]] | 926 | | | (6LBR). | | 927 +--------+-------+-------------------------------------+------------+ 929 Table 1: Role values. 931 9.3.2. Configuration Object 933 The Configuration structure is built on a CBOR map object. The set 934 of parameters that can appear in a Configuration object is summarized 935 below. The defined labels can be found below, the details of this 936 registry are in section "CoJP Key Usage Registry" Section 13.3. 938 o link-layer key set: An array encompassing a set of cryptographic 939 keys and their identifiers that are currently in use in the 940 network, or that are scheduled to be used in the future. The 941 encoding of individual keys is described in Section 9.3.2.1. The 942 link-layer key set parameter MAY be included in a Configuration 943 object. When present, the link-layer key set parameter MUST 944 contain at least one key. How the keys are installed and used 945 differs for the 6LBR and other nodes. When 6LBR receives this 946 parameter, it MUST remove any old keys it has installed from the 947 previous key set and immediately install and start using the new 948 keys for all outgoing and incoming traffic. When a non-6LBR node 949 receives this parameter, it MUST install the keys, use them for 950 any incoming traffic matching the key identifier, but keep using 951 the old keys for all outgoing traffic. A non-6LBR node accepts 952 any frames for which it has keys: both old and new keys. Upon 953 reception and successful security processing of a link-layer frame 954 secured with a key from the new key set, a non-6LBR node MUST 955 remove any old keys it has installed from the previous key set. 956 From that moment on, a non-6LBR node MUST use the keys from the 957 new key set for all outgoing traffic. In the case when the pledge 958 is joining for the first time, before sending the first outgoing 959 frame secured with a received key, the pledge needs to 960 successfully complete the security processing of an incoming 961 frame. To do so, the pledge can wait to receive a new frame or it 962 can also store an EB frame that it used to find the JP and use it 963 for immediate security processing upon reception of the key set. 964 The described mechanism permits the JRC to provision the new key 965 set to all the nodes while the network continues to use the 966 existing keys. When the JRC is certain that all (or enough) nodes 967 have been provisioned with the new keys, then the JRC updates the 968 6LBR. In the special case when the JRC is co-located with the 969 6LBR, it can simply trigger the sending of a new broadcast frame 970 (e.g. EB), secured with a key from the new key set. The frame 971 goes out with the new key, and upon reception and successful 972 security processing of the new frame all receiving nodes will 973 switch to the new active keys. Outgoing traffic from those nodes 974 will then use the new key, which causes an update of additional 975 peers, and the network will switch over in a flood-fill fashion. 977 o link-layer short address: IEEE Std 802.15.4 short address assigned 978 to the pledge. The short address structure is described in 979 Section 9.3.2.2. The link-layer short address parameter MAY be 980 included in a Configuration object. When a node receives this 981 parameter as part of the Parameter Update message, it MUST update 982 its link-layer short address to the one received. 984 o JRC address: the IPv6 address of the JRC, encoded as a byte 985 string, with the length of 16 bytes. If the length of the byte 986 string is different than 16, the parameter MUST be discarded. If 987 the JRC is not co-located with the 6LBR and has a different IPv6 988 address than the 6LBR, this parameter MUST be included. In the 989 special case where the JRC is co-located with the 6LBR and has the 990 same IPv6 address as the 6LBR, this parameter MAY be included. If 991 the JRC address parameter is not present in the Join Response, 992 this indicates that the JRC has the same IPv6 address as the 6LBR. 993 The joined node can then discover the IPv6 address of the JRC 994 through network control traffic. See Section 7. 996 o network identifier: the identifier of the network, as discussed in 997 Section 3, encoded as a byte string. When present in the Join 998 Response, this parameter is only valid when received by the 6LBR 999 pledge. The parameter indicates to the 6LBR the value of the 1000 network identifier it should advertise at the link layer. This 1001 parameter MUST NOT be included in the Join Response if the role 1002 parameter from the corresponding Join Request indicated 0, i.e. 1003 the role "6TiSCH Node". In the case where the corresponding 1004 Join_Request object does not contain the network identifier 1005 parameter, this parameter MUST be included. When the 1006 corresponding Join_Request object does contain the network 1007 identifier parameter, this parameter MAY be included in the 1008 Configuration object. This may happen if the JRC decides to 1009 overwrite the network identifier provisioned during the one-touch 1010 process. The value of the network identifier parameter from the 1011 Configuration object SHOULD take precedence over the value 1012 provisioned during the one-touch process. 1014 o network prefix: the IPv6 network prefix, encoded as a byte string. 1015 The length of the byte string determines the prefix length. This 1016 parameter is only valid when received by the 6LBR pledge. The 1017 parameter indicates to the 6LBR the value of the IPv6 network 1018 prefix. This parameter MAY be included in the Join Response if 1019 the role parameter from the corresponding Join_Request object 1020 indicated 1, i.e. the role "6LBR". This parameter MUST NOT be 1021 included in the Join Response if the role parameter from the 1022 corresponding Join_Request object indicated 0, i.e. the role 1023 "6TiSCH Node". 1025 The CDDL fragment that represents the text above for the 1026 Configuration follows. Structures Link_Layer_Key and Short_Address 1027 are specified in Section 9.3.2.1 and Section 9.3.2.2. 1029 Configuration = { 1030 ? 2 : [ +Link_Layer_Key ], ; link-layer key set 1031 ? 3 : Short_Address, ; link-layer short address 1032 ? 4 : bstr ; JRC address 1033 ? 5 : bstr ; network identifier 1034 ? 6 : bstr ; network prefix 1035 } 1036 +------------+-------+----------+----------------------+------------+ 1037 | Name | Label | CBOR | Description | Reference | 1038 | | | type | | | 1039 +------------+-------+----------+----------------------+------------+ 1040 | role | 1 | unsigned | Identifies the role | [[this | 1041 | | | integer | parameter. | document]] | 1042 | | | | | | 1043 | link-layer | 2 | array | Identifies the array | [[this | 1044 | key set | | | carrying one or more | document]] | 1045 | | | | link-level | | 1046 | | | | cryptographic keys. | | 1047 | | | | | | 1048 | link-layer | 3 | array | Identifies the | [[this | 1049 | short | | | assigned link-layer | document]] | 1050 | address | | | short address | | 1051 | | | | | | 1052 | JRC | 4 | byte | Identifies the IPv6 | [[this | 1053 | address | | string | address of the JRC | document]] | 1054 | | | | | | 1055 | network | 5 | byte | Identifies the | [[this | 1056 | identifier | | string | network identifier | document]] | 1057 | | | | parameter | | 1058 | | | | | | 1059 | network | 6 | byte | Identifies the IPv6 | [[this | 1060 | prefix | | string | prefix of the | document]] | 1061 | | | | network | | 1062 +------------+-------+----------+----------------------+------------+ 1064 Table 2: Join Response map labels. 1066 9.3.2.1. Link-Layer Key 1068 The Link_Layer_Key structure encompasses the parameters needed to 1069 configure the link-layer security module: the value of the 1070 cryptographic key, the key identifier, the link-layer algorithm 1071 identifier, and the security level and the frame types that it should 1072 be used with, both for outgoing and incoming security operations. 1074 For encoding compactness, Link_Layer_Key object is not enclosed in a 1075 top-level CBOR object. Rather, it is transported as a consecutive 1076 group of CBOR elements, with some being optional. To be able to 1077 decode the keys that are present in the link-layer key set, and to 1078 identify individual parameters of a single Link_Layer_Key object, the 1079 CBOR decoder needs to differentiate between elements based on the 1080 CBOR type. For example, when the decoder determines that the current 1081 element in the array is a byte string, it is certain that it is 1082 processing the last element of a given Link_Layer_Key object. 1084 The set of parameters that can appear in a Link_Layer_Key object is 1085 summarized below, in order: 1087 o key_index: The identifier of the key, encoded as a CBOR unsigned 1088 integer. This parameter MUST be included. The parameter uniquely 1089 identifies the key and is used to retrieve the key for incoming 1090 traffic. In case of [IEEE802.15.4], the decoded CBOR unsigned 1091 integer value sets the "secKeyIndex" parameter that is signaled in 1092 all outgoing and incoming frames secured with this key. If the 1093 decoded CBOR unsigned integer value is larger than the maximum 1094 link-layer key identifier, which is 255 in [IEEE802.15.4]), the 1095 key is considered invalid. Additionally, in case of 1096 [IEEE802.15.4], the value of 0 is considered invalid. In case the 1097 key is considered invalid, the implementation MUST discard the key 1098 and attempt to decode the next key in the array. 1100 o key_usage: The identifier of the link-layer algorithm, security 1101 level and link-layer frame types that can be used with the key, 1102 encoded as a CBOR unsigned or negative integer. This parameter 1103 MAY be included. Possible values and the corresponding link-layer 1104 settings are specified in IANA "CoJP Key Usage" registry 1105 (Section 13.3). In case the parameter is omitted, the default 1106 value of 0 from Table 3 MUST be assumed. 1108 o key_value: The value of the cryptographic key, encoded as a byte 1109 string. This parameter MUST be included. If the length of the 1110 byte string is different than the corresponding key length for a 1111 given algorithm specified by the key_usage parameter, the key MUST 1112 be discarded and the decoder should attempt to decode the next key 1113 in the array. 1115 The CDDL fragment that represents the text above for the 1116 Link_Layer_Key follows. 1118 Link_Layer_Key = ( 1119 key_index : uint, 1120 ? key_usage : uint / nint, 1121 key_value : bstr, 1122 ) 1124 +------------------+-----+-----------------+-------------+----------+ 1125 | Name | Val | Algorithm | Description | Referenc | 1126 | | ue | | | e | 1127 +------------------+-----+-----------------+-------------+----------+ 1128 | 6TiSCH-K1K2-ENC- | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | 1129 | MIC-32 | | CCM-128 | for EBs, | ocument] | 1130 | | | | ENC-MIC-32 | ] | 1131 | | | | for DATA | | 1132 | | | | and ACKNOWL | | 1133 | | | | EDGMENT. | | 1134 | | | | | | 1135 | 6TiSCH-K1K2-ENC- | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | 1136 | MIC-64 | | CCM-128 | for EBs, | ocument] | 1137 | | | | ENC-MIC-64 | ] | 1138 | | | | for DATA | | 1139 | | | | and ACKNOWL | | 1140 | | | | EDGMENT. | | 1141 | | | | | | 1142 | 6TiSCH-K1K2-ENC- | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | 1143 | MIC-128 | | CCM-128 | for EBs, | ocument] | 1144 | | | | ENC-MIC-128 | ] | 1145 | | | | for DATA | | 1146 | | | | and ACKNOWL | | 1147 | | | | EDGMENT. | | 1148 | | | | | | 1149 | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | 1150 | K1K2-MIC-32 | | CCM-128 | for EBs, | ocument] | 1151 | | | | DATA and AC | ] | 1152 | | | | KNOWLEDGMEN | | 1153 | | | | T. | | 1154 | | | | | | 1155 | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | 1156 | K1K2-MIC-64 | | CCM-128 | for EBs, | ocument] | 1157 | | | | DATA and AC | ] | 1158 | | | | KNOWLEDGMEN | | 1159 | | | | T. | | 1160 | | | | | | 1161 | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | 1162 | K1K2-MIC-128 | | CCM-128 | for EBs, | ocument] | 1163 | | | | DATA and AC | ] | 1164 | | | | KNOWLEDGMEN | | 1165 | | | | T. | | 1166 | | | | | | 1167 | 6TiSCH-K1-MIC-32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | 1168 | | | CCM-128 | for EBs. | ocument] | 1169 | | | | | ] | 1170 | | | | | | 1171 | 6TiSCH-K1-MIC-64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | 1172 | | | CCM-128 | for EBs. | ocument] | 1173 | | | | | ] | 1174 | | | | | | 1175 | 6TiSCH-K1-MIC-12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | 1176 | 8 | | CCM-128 | for EBs. | ocument] | 1177 | | | | | ] | 1178 | | | | | | 1179 | 6TiSCH-K2-MIC-32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | 1180 | | | CCM-128 | for DATA | ocument] | 1181 | | | | and ACKNOWL | ] | 1182 | | | | EDGMENT. | | 1183 | | | | | | 1184 | 6TiSCH-K2-MIC-64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | 1185 | | | CCM-128 | for DATA | ocument] | 1186 | | | | and ACKNOWL | ] | 1187 | | | | EDGMENT. | | 1188 | | | | | | 1189 | 6TiSCH-K2-MIC-12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | 1190 | 8 | | CCM-128 | for DATA | ocument] | 1191 | | | | and ACKNOWL | ] | 1192 | | | | EDGMENT. | | 1193 | | | | | | 1194 | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | 1195 | MIC-32 | | CCM-128 | MIC-32 for | ocument] | 1196 | | | | DATA and AC | ] | 1197 | | | | KNOWLEDGMEN | | 1198 | | | | T. | | 1199 | | | | | | 1200 | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | 1201 | MIC-64 | | CCM-128 | MIC-64 for | ocument] | 1202 | | | | DATA and AC | ] | 1203 | | | | KNOWLEDGMEN | | 1204 | | | | T. | | 1205 | | | | | | 1206 | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | 1207 | MIC-128 | | CCM-128 | MIC-128 for | ocument] | 1208 | | | | DATA and AC | ] | 1209 | | | | KNOWLEDGMEN | | 1210 | | | | T. | | 1211 +------------------+-----+-----------------+-------------+----------+ 1213 Table 3: Key Usage values. 1215 9.3.2.2. Short Address 1217 The Short_Address object represents an address assigned to the pledge 1218 that is unique locally in the network. It is encoded as a CBOR array 1219 object, containing, in order: 1221 o address: The assigned locally-unique address, encoded as a byte 1222 string. This parameter MUST be included. In case of 1223 [IEEE802.15.4], if the length of the byte string is different than 1224 2, the address is considered invalid. In case of [IEEE802.15.4], 1225 the value of this parameter is used to set the short address of 1226 IEEE Std 802.15.4 module. In case the address is considered 1227 invalid, the decoder MUST silently ignore the Short_Address 1228 object. 1230 o lease_time: The validity of the address in seconds after the 1231 reception of the CBOR object, encoded as a CBOR unsigned integer. 1232 This parameter MAY be included. The node MUST stop using the 1233 assigned short address after the expiry of the lease_time 1234 interval. It is up to the JRC to renew the lease before the 1235 expiry of the previous interval. The JRC updates the lease by 1236 executing the Parameter Update exchange with the node and 1237 including the Short_Address in the Configuration object, as 1238 described in Section 9.2. In case the address lease expires, the 1239 node SHOULD initiate a new join exchange, as described in 1240 Section 9.1. In case this parameter is omitted, the value of 1241 positive infinity MUST be assumed, meaning that the address is 1242 valid for as long as the node participates in the network. 1244 The CDDL fragment that represents the text above for the 1245 Short_Address follows. 1247 Short_Address = [ 1248 address : bstr, 1249 ? lease_time : uint 1250 ] 1252 9.4. Parameters 1254 CoJP uses the following parameters: 1256 +-----------------------+----------------+ 1257 | Name | Default Value | 1258 +-----------------------+----------------+ 1259 | TIMEOUT_BASE | 10 s | 1260 +-----------------------+----------------+ 1261 | TIMEOUT_RANDOM_FACTOR | 1.5 | 1262 +-----------------------+----------------+ 1263 | MAX_RETRANSMIT | 4 | 1264 +----------------------------------------+ 1266 The values of TIMEOUT_BASE, TIMEOUT_RANDOM_FACTOR, MAX_RETRANSMIT may 1267 be configured to values specific to the deployment. The default 1268 values have been chosen to accommodate a wide range of deployments, 1269 taking into account dense networks. 1271 9.5. Mandatory to Implement Algorithms 1273 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 1274 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 1275 securing IEEE Std 802.15.4 frames, and hardware acceleration for it 1276 is present in virtually all compliant radio chips. With this choice, 1277 CoAP messages are protected with an 8-byte CCM authentication tag, 1278 and the algorithm uses 13-byte long nonces. 1280 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. 1282 The mandatory to implement key derivation function is HKDF [RFC5869], 1283 instantiated with a SHA-256 hash. 1285 10. Stateless-Proxy CoAP Option 1287 The CoAP proxy defined in [RFC7252] keeps per-client state 1288 information in order to forward the response towards the originator 1289 of the request. This state information includes at least the CoAP 1290 token, the IPv6 address of the host, and the UDP source port number. 1292 The Stateless-Proxy CoAP option (see Figure 3) allows the proxy to be 1293 entirely stateless. The proxy inserts this option in the request to 1294 carry the state information needed for relaying the response back to 1295 the client. The proxy still keeps some general state (e.g. for 1296 congestion control or request retransmission), but no per-client 1297 state. 1299 The Stateless-Proxy CoAP option is critical, Safe-to-Forward, not 1300 part of the cache key, not repeatable and opaque. When processed by 1301 OSCORE, the Stateless-Proxy option is neither encrypted nor integrity 1302 protected. 1304 +-----+---+---+---+---+-----------------+--------+--------+ 1305 | No. | C | U | N | R | Name | Format | Length | 1306 +-----+---+---+---+---+-----------------+--------+--------| 1307 | TBD | x | | x | | Stateless-Proxy | opaque | 1-255 | 1308 +-----+---+---+---+---+-----------------+--------+--------+ 1309 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 1311 Figure 3: Stateless-Proxy CoAP Option 1313 Upon reception of a Stateless-Proxy option, the CoAP server MUST echo 1314 it in the response. The value of the Stateless-Proxy option is 1315 internal proxy state that is opaque to the server. For security 1316 reasons, the option value MUST be authenticated, MUST include a 1317 freshness indicator (e.g. a sequence number or timestamp) and MAY be 1318 encrypted. The proxy may use a COSE structure [RFC8152] to wrap the 1319 state information as the value of the Stateless-Proxy option. The 1320 key used for encryption/authentication of the state information may 1321 be known only to the proxy. 1323 Once the proxy has received the CoAP response with a Stateless-Proxy 1324 option present, it decrypts/authenticates it, checks the freshness 1325 indicator and constructs the response for the client, based on the 1326 information present in the option value. 1328 Note that a CoAP proxy using the Stateless-Proxy option is not able 1329 to return a 5.04 Gateway Timeout Response Code in case the request to 1330 the server times out. Likewise, if the response to the proxy's 1331 request does not contain the Stateless-Proxy option, for example when 1332 the option is not supported by the server, the proxy is not able to 1333 return the response to the client, and the client eventually times 1334 out. 1336 11. Security Considerations 1338 This document recommends that the (6LBR) pledge and JRC are 1339 provisioned with unique PSKs. The nonce used for the Join Request 1340 and the Join Response is the same, but used under a different key. 1341 The design differentiates between keys derived for requests and keys 1342 derived for responses by different sender identifiers. Note that the 1343 address of the JRC does not take part in nonce or key construction. 1344 Even in the case of a misconfiguration in which the same PSK is used 1345 for several pledges, the keys used to protect the requests/responses 1346 from/towards different pledges are different, as they are derived 1347 using the pledge identifier as Master Salt. The PSK is still 1348 important for mutual authentication of the (6LBR) pledge and the JRC. 1349 Should an attacker come to know the PSK, then a man-in-the-middle 1350 attack is possible. The well-known problem with Bluetooth headsets 1351 with a "0000" pin applies here. 1353 Being a stateless relay, the JP blindly forwards the join traffic 1354 into the network. A simple bandwidth cap on the JP prevents it from 1355 forwarding more traffic than the network can handle. This forces 1356 attackers to use more than one Join Proxy if they wish to overwhelm 1357 the network. Marking the join traffic packets with a non-zero DSCP 1358 allows the network to carry the traffic if it has capacity, but 1359 encourages the network to drop the extra traffic rather than add 1360 bandwidth due to that traffic. 1362 The shared nature of the "minimal" cell used for the join traffic 1363 makes the network prone to DoS attacks by congesting the JP with 1364 bogus traffic. Such an attacker is limited by its maximum transmit 1365 power. The redundancy in the number of deployed JPs alleviates the 1366 issue and also gives the pledge a possibility to use the best 1367 available link for joining. How a network node decides to become a 1368 JP is out of scope of this specification. 1370 At the beginning of the join process, the pledge has no means of 1371 verifying the content in the EB, and has to accept it at "face 1372 value". In case the pledge tries to join an attacker's network, the 1373 Join Response message will either fail the security check or time 1374 out. The pledge may implement a temporary blacklist in order to 1375 filter out undesired EBs and try to join using the next seemingly 1376 valid EB. This blacklist alleviates the issue, but is effectively 1377 limited by the node's available memory. Bogus beacons prolong the 1378 join time of the pledge, and so the time spent in "minimal" [RFC8180] 1379 duty cycle mode. 1381 12. Privacy Considerations 1383 The join solution specified in this document relies on the uniqueness 1384 of the pledge identifier within the namespace managed by the JRC. 1385 This identifier is transferred in clear as an OSCORE kid context. 1386 The use of the globally unique EUI-64 as pledge identifier simplifies 1387 the management but comes with certain privacy risks. The 1388 implications are thoroughly discussed in [RFC7721] and comprise 1389 correlation of activities over time, location tracking, address 1390 scanning and device-specific vulnerability exploitation. Since the 1391 join protocol is executed rarely compared to the network lifetime, 1392 long-term threats that arise from using EUI-64 as the pledge 1393 identifier are minimal. In addition, the Join Response message 1394 contains a short address which is assigned by the JRC to the (6LBR) 1395 pledge. The assigned short address SHOULD be uncorrelated with the 1396 long-term pledge identifier. The short address is encrypted in the 1397 response. Once the join process completes, the new node uses the 1398 short addresses for all further layer 2 (and layer-3) operations. 1399 This mitigates the aforementioned privacy risks as the short layer-2 1400 address (visible even when the network is encrypted) is not traceable 1401 between locations and does not disclose the manufacturer, as is the 1402 case of EUI-64. 1404 13. IANA Considerations 1406 Note to RFC Editor: Please replace all occurrences of "[[this 1407 document]]" with the RFC number of this specification. 1409 This document allocates a well-known name under the .arpa name space 1410 according to the rules given in [RFC3172]. The name "6tisch.arpa" is 1411 requested. No subdomains are expected. No A, AAAA or PTR record is 1412 requested. 1414 13.1. CoAP Option Numbers Registry 1416 The Stateless-Proxy option is added to the CoAP Option Numbers 1417 registry: 1419 +--------+-----------------+-----------------------+ 1420 | Number | Name | Reference | 1421 +--------+-----------------+-----------------------+ 1422 | TBD | Stateless-Proxy | \[\[this document\]\] | 1423 +--------+-----------------+-----------------------+ 1425 13.2. CoJP Parameters Registry 1427 This section defines a sub-registries within the "IPv6 over the TSCH 1428 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1429 "Constrained Join Protocol Parameters Registry". 1431 The columns of the registry are: 1433 Name: This is a descriptive name that enables an easier reference to 1434 the item. It is not used in the encoding. 1436 Label: The value to be used to identify this parameter. The label is 1437 an unsigned integer. 1439 CBOR type: This field contains the CBOR type for the field. 1441 Description: This field contains a brief description for the field. 1443 Reference: This field contains a pointer to the public specification 1444 for the field, if one exists. 1446 This registry is to be populated with the values in Table 2. 1448 The amending formula for this sub-registry is: Different ranges of 1449 values use different registration policies [RFC8126]. Integer values 1450 from -256 to 255 are designated as Standards Action. Integer values 1451 from -65536 to -257 and from 256 to 65535 are designated as 1452 Specification Required. Integer values greater than 65535 are 1453 designated as Expert Review. Integer values less than -65536 are 1454 marked as Private Use. 1456 13.3. CoJP Key Usage Registry 1458 This section defines a sub-registries within the "IPv6 over the TSCH 1459 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1460 "Constrained Join Protocol Key Usage Registry". 1462 The columns of this registry are: 1464 Name: This is a descriptive name that enables easier reference to the 1465 item. The name MUST be unique. It is not used in the encoding. 1467 Value: This is the value used to identify the key usage setting. 1468 These values MUST be unique. The value is an integer. 1470 Algorithm: This is a descriptive name of the link-layer algorithm in 1471 use and uniquely determines the key length. The name is not used in 1472 the encoding. 1474 Description: This field contains a description of the key usage 1475 setting. The field should describe in enough detail how the key is 1476 to be used with different frame types, specific for the link-layer 1477 technology in question. 1479 References: This contains a pointer to the public specification for 1480 the field, if one exists. 1482 This registry is to be populated with the values in Table 3. 1484 The amending formula for this sub-registry is: Different ranges of 1485 values use different registration policies [RFC8126]. Integer values 1486 from -256 to 255 are designated as Standards Action. Integer values 1487 from -65536 to -257 and from 256 to 65535 are designated as 1488 Specification Required. Integer values greater than 65535 are 1489 designated as Expert Review. Integer values less than -65536 are 1490 marked as Private Use. 1492 14. Acknowledgments 1494 The work on this document has been partially supported by the 1495 European Union's H2020 Programme for research, technological 1496 development and demonstration under grant agreement No 644852, 1497 project ARMOUR. 1499 The authors are grateful to Thomas Watteyne, Goeran Selander, Xavier 1500 Vilajosana, Pascal Thubert for reviewing, and to Klaus Hartke for 1501 providing input on the Stateless-Proxy CoAP option. 1503 The authors would also like to thank Francesca Palombini, Ludwig 1504 Seitz and John Mattsson for participating in the discussions that 1505 have helped shape the document. 1507 The IANA considerations for the three created registries is copied 1508 verbatim from RFC8392 at the suggestion of Mike Jones. 1510 15. References 1512 15.1. Normative References 1514 [I-D.ietf-core-object-security] 1515 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1516 "Object Security for Constrained RESTful Environments 1517 (OSCORE)", draft-ietf-core-object-security-13 (work in 1518 progress), May 2018. 1520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1521 Requirement Levels", BCP 14, RFC 2119, 1522 DOI 10.17487/RFC2119, March 1997, . 1525 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1526 "Assured Forwarding PHB Group", RFC 2597, 1527 DOI 10.17487/RFC2597, June 1999, . 1530 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1531 Requirements for the Address and Routing Parameter Area 1532 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1533 September 2001, . 1535 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1536 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1537 October 2013, . 1539 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1540 Application Protocol (CoAP)", RFC 7252, 1541 DOI 10.17487/RFC7252, June 2014, . 1544 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1545 Writing an IANA Considerations Section in RFCs", BCP 26, 1546 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1547 . 1549 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1550 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1551 . 1553 15.2. Informative References 1555 [I-D.ietf-6tisch-6top-protocol] 1556 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol 1557 (6P)", draft-ietf-6tisch-6top-protocol-11 (work in 1558 progress), March 2018. 1560 [I-D.ietf-6tisch-architecture] 1561 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1562 of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work 1563 in progress), April 2018. 1565 [I-D.ietf-6tisch-terminology] 1566 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1567 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 1568 draft-ietf-6tisch-terminology-10 (work in progress), March 1569 2018. 1571 [I-D.ietf-cbor-cddl] 1572 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 1573 definition language (CDDL): a notational convention to 1574 express CBOR data structures", draft-ietf-cbor-cddl-02 1575 (work in progress), February 2018. 1577 [IEEE802.15.4] 1578 IEEE standard for Information Technology, ., "IEEE Std 1579 802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 1581 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1582 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1583 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1584 . 1586 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1587 "Transmission of IPv6 Packets over IEEE 802.15.4 1588 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1589 . 1591 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1592 Key Derivation Function (HKDF)", RFC 5869, 1593 DOI 10.17487/RFC5869, May 2010, . 1596 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1597 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1598 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1599 Low-Power and Lossy Networks", RFC 6550, 1600 DOI 10.17487/RFC6550, March 2012, . 1603 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1604 Bormann, "Neighbor Discovery Optimization for IPv6 over 1605 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1606 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1607 . 1609 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1610 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1611 Internet of Things (IoT): Problem Statement", RFC 7554, 1612 DOI 10.17487/RFC7554, May 2015, . 1615 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1616 Considerations for IPv6 Address Generation Mechanisms", 1617 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1618 . 1620 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 1621 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 1622 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 1623 May 2017, . 1625 Appendix A. Example 1627 Figure 4 illustrates a successful join protocol exchange. The pledge 1628 instantiates the OSCORE context and derives the traffic keys and 1629 nonces from the PSK. It uses the instantiated context to protect the 1630 Join Request addressed with a Proxy-Scheme option, the well-known 1631 host name of the JRC in the Uri-Host option, and its EUI-64 as pledge 1632 identifier and OSCORE kid context. Triggered by the presence of a 1633 Proxy-Scheme option, the JP forwards the request to the JRC and adds 1634 the Stateless-Proxy option with value set to the internally needed 1635 state. The JP has learned the IPv6 address of the JRC when it acted 1636 as a pledge and joined the network. Once the JRC receives the 1637 request, it looks up the correct context based on the kid context 1638 parameter. OSCORE data authenticity verification ensures that the 1639 request has not been modified in transit. In addition, replay 1640 protection is ensured through persistent handling of mutable context 1641 parameters. 1643 Once the JP receives the Join Response, it authenticates the 1644 Stateless-Proxy option before deciding where to forward. The JP sets 1645 its internal state to that found in the Stateless-Proxy option, and 1646 forwards the Join Response to the correct pledge. Note that the JP 1647 does not possess the key to decrypt the CBOR object (configuration) 1648 present in the payload. The Join Response is matched to the Join 1649 Request and verified for replay protection at the pledge using OSCORE 1650 processing rules. In this example, the Join Response does not 1651 contain the IPv6 address of the JRC, the pledge hence understands the 1652 JRC is co-located with the 6LBR. 1654 <---E2E OSCORE--> 1655 Client Proxy Server 1656 Pledge JP JRC 1657 | | | 1658 | Join | | Code: { 0.02 } (POST) 1659 | Request | | Token: 0x8c 1660 +--------->| | Proxy-Scheme: [ coap ] 1661 | POST | | Uri-Host: [ 6tisch.arpa ] 1662 | | | Object-Security: [ kid: 0 ] 1663 | | | Payload: kid_context: EUI-64 1664 | | | [ Partial IV: 1, 1665 | | | { Uri-Path:"j", 1666 | | | join_request }, 1667 | | | ] 1668 | | | 1669 | | Join | Code: { 0.01 } (GET) 1670 | | Request | Token: 0x7b 1671 | +--------->| Uri-Host: [ 6tisch.arpa ] 1672 | | POST | Object-Security: [ kid: 0 ] 1673 | | | Stateless-Proxy: opaque state 1674 | | | Payload: kid_context: EUI-64 1675 | | | [ Partial IV: 1, 1676 | | | { Uri-Path:"j", 1677 | | | join_request }, 1678 | | | ] 1679 | | | 1680 | | Join | Code: { 2.05 } (Content) 1681 | | Response | Token: 0x7b 1682 | |<---------+ Object-Security: - 1683 | | 2.04 | Stateless-Proxy: opaque state 1684 | | | Payload: [ { configuration }, ] 1685 | | | 1686 | Join | | Code: { 2.05 } (Content) 1687 | Response | | Token: 0x8c 1688 |<---------+ | Object-Security: - 1689 | 2.04 | | Payload: [ { configuration }, ] 1690 | | | 1692 Figure 4: Example of a successful join protocol exchange. { ... } 1693 denotes encryption and authentication, [ ... ] denotes 1694 authentication. 1696 Where the join_request object is: 1698 join_request: 1699 { 1700 5 : h'cafe' / PAN ID of the network pledge is attempting to join / 1701 } 1703 Since the role parameter is not present, the default role of "6TiSCH 1704 Node" is implied. 1706 The join_request object encodes to h'a10542cafe' with a size of 5 1707 bytes. 1709 And the configuration object is: 1711 configuration: 1712 { 1713 2 : [ / link-layer key set / 1714 1, / key_index / 1715 h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / 1716 ], 1717 3 : [ / link-layer short address / 1718 h'af93' / assigned short address / 1719 ] 1720 } 1722 Since the key_usage parameter is not present in the link-layer key 1723 set object, the default value of "6TiSCH-K1K2-ENC-MIC-32" is implied. 1724 Similarly, since the lease_time parameter is not present in the link- 1725 layer short address object, the default value of positive infinity is 1726 implied. 1728 The configuration object encodes to 1730 h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size 1731 of 26 bytes. 1733 Authors' Addresses 1735 Malisa Vucinic (editor) 1736 University of Montenegro 1737 Dzordza Vasingtona bb 1738 Podgorica 81000 1739 Montenegro 1741 Email: malisav@ac.me 1742 Jonathan Simon 1743 Analog Devices 1744 32990 Alvarado-Niles Road, Suite 910 1745 Union City, CA 94587 1746 USA 1748 Email: jonathan.simon@analog.com 1750 Kris Pister 1751 University of California Berkeley 1752 512 Cory Hall 1753 Berkeley, CA 94720 1754 USA 1756 Email: pister@eecs.berkeley.edu 1758 Michael Richardson 1759 Sandelman Software Works 1760 470 Dawson Avenue 1761 Ottawa, ON K1Z5V7 1762 Canada 1764 Email: mcr+ietf@sandelman.ca