idnits 2.17.1 draft-ietf-6tisch-minimal-security-10.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 (April 05, 2019) is 1847 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-20 == Outdated reference: A later version (-08) exists of draft-ietf-core-stateless-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Working Group M. Vucinic, Ed. 3 Internet-Draft Inria 4 Intended status: Standards Track J. Simon 5 Expires: October 7, 2019 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 April 05, 2019 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-10 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 October 7, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Provisioning Phase . . . . . . . . . . . . . . . . . . . . . 5 70 4. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 72 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 73 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 74 4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 75 5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 76 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) . . . . . . . . . . . . . . 17 83 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 19 84 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 20 85 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 21 86 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 24 87 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 36 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 89 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 90 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 91 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 39 92 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 40 93 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 41 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 96 13.1. Normative References . . . . . . . . . . . . . . . . . . 42 97 13.2. Informative References . . . . . . . . . . . . . . . . . 43 98 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 44 99 Appendix B. Lightweight Implementation Option . . . . . . . . . 47 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 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 o 6LoWPAN Node (6LN) 203 The term "6LBR" is used interchangeably with the term "DODAG root" 204 defined in [RFC6550], assuming the two entities are co-located, as 205 recommended by [I-D.ietf-6tisch-architecture]. 207 The term "pledge", as used throughout the document, explicitly 208 denotes non-6LBR devices attempting to join the network using their 209 IEEE Std 802.15.4 network interface. The device that attempts to 210 join as the 6LBR of the network and does so over another network 211 interface is explicitly denoted as the "6LBR pledge". When the text 212 equally applies to the pledge and the 6LBR pledge, the "(6LBR) 213 pledge" form is used. 215 In addition, we use generic terms "pledge identifier" and "network 216 identifier". See Section 3. 218 The terms "secret key" and "symmetric key" are used interchangeably. 220 3. Provisioning Phase 222 The (6LBR) pledge is provisioned with certain parameters before 223 attempting to join the network, and the same parameters are 224 provisioned to the JRC. There are many ways by which this 225 provisioning can be done. Physically, the parameters can be written 226 into the (6LBR) pledge using a number of mechanisms, such as a JTAG 227 interface, a serial (craft) console interface, pushing buttons 228 simultaneously on different devices, over-the-air configuration in a 229 Faraday cage, etc. The provisioning can be done by the vendor, the 230 manufacturer, the integrator, etc. 232 Details of how this provisioning is done is out of scope of this 233 document. What is assumed is that there can be a secure, private 234 conversation between the JRC and the (6LBR) pledge, and that the two 235 devices can exchange the parameters. 237 Parameters that are provisioned to the (6LBR) pledge include: 239 o pledge identifier. The pledge identifier identifies the (6LBR) 240 pledge. The pledge identifier MUST be unique in the set of all 241 pledge identifiers managed by a JRC. The pledge identifier 242 uniqueness is an important security requirement, as discussed in 243 Section 9. The pledge identifier is typically the globally unique 244 64-bit Extended Unique Identifier (EUI-64) of the IEEE Std 245 802.15.4 device, in which case it is provisioned by the hardware 246 manufacturer. The pledge identifier is used to generate the IPv6 247 addresses of the (6LBR) pledge and to identify it during the 248 execution of the join protocol. For privacy reasons (see 249 Section 10), it is possible to use a pledge identifier different 250 from the EUI-64. For example, a pledge identifier may be a random 251 byte string, but care needs to be taken that such a string meets 252 the uniqueness requirement. 254 o Pre-Shared Key (PSK). A secret cryptographic key shared between 255 the (6LBR) pledge and the JRC. The JRC additionally needs to 256 store the pledge identifier bound to the given PSK. Each (6LBR) 257 pledge MUST be provisioned with a unique PSK. The PSK SHOULD be a 258 cryptographically strong key, at least 128 bits in length, 259 indistinguishable by feasible computation from a random uniform 260 string of the same length. How the PSK is generated and/or 261 provisioned is out of scope of this specification. This could be 262 done during a provisioning step or companion documents can specify 263 the use of a key agreement protocol. Common pitfalls when 264 generating PSKs are discussed in Section 9. 266 o Optionally, a network identifier. The network identifier 267 identifies the 6TiSCH network. The network identifier MUST be 268 carried within Enhanced Beacon (EB) frames. Typically, the 16-bit 269 Personal Area Network Identifier (PAN ID) defined in 270 [IEEE802.15.4] is used as the network identifier. However, PAN ID 271 is not considered a stable network identifier as it may change 272 during network lifetime if a collision with another network is 273 detected. Companion documents can specify the use of a different 274 network identifier for join purposes, but this is out of scope of 275 this specification. Provisioning the network identifier is 276 RECOMMENDED. However, due to operational constraints, the network 277 identifier may not be known at the time when the provisioning is 278 done. In case this parameter is not provisioned to the pledge, 279 the pledge attempts to join one advertised network at a time, 280 which significantly prolongs the join process. This parameter 281 MUST be provisioned to the 6LBR pledge. 283 o Optionally, any non-default algorithms. The default algorithms 284 are specified in Section 7.3.3. When algorithm identifiers are 285 not exchanged, the use of these default algorithms is implied. 287 Additionally, the 6LBR pledge that is not co-located with the JRC 288 needs to be provisioned with: 290 o Global IPv6 address of the JRC. This address is used by the 6LBR 291 pledge to address the JRC during the join process. The 6LBR 292 pledge may also obtain the IPv6 address of the JRC through other 293 available mechanisms, such as DHCPv6, GRASP, mDNS, the use of 294 which is out of scope of this document. Pledges do not need to be 295 provisioned with this address as they discover it dynamically 296 through CoJP. 298 4. Join Process Overview 300 This section describes the steps taken by a pledge in a 6TiSCH 301 network. When a pledge seeks admission to a 6TiSCH network, the 302 following exchange occurs: 304 1. The pledge listens for an Enhanced Beacon (EB) frame 305 [IEEE802.15.4]. This frame provides network synchronization 306 information, and tells the device when it can send a frame to the 307 node sending the beacons, which acts as a Join Proxy (JP) for the 308 pledge, and when it can expect to receive a frame. The Enhanced 309 Beacon provides the L2 address of the JP and it may also provide 310 its link-local IPv6 address. 312 2. The pledge configures its link-local IPv6 address and advertises 313 it to the JP using Neighbor Discovery. This step may be omitted 314 if the link-local address has been derived from a known unique 315 interface identifier, such as an EUI-64 address. 317 3. The pledge sends a Join Request to the JP in order to securely 318 identify itself to the network. The Join Request is forwarded to 319 the JRC. 321 4. In case of successful processing of the request, the pledge 322 receives a Join Response from the JRC (via the JP). The Join 323 Response contains configuration parameters necessary for the 324 pledge to join the network. 326 From the pledge's perspective, joining is a local phenomenon - the 327 pledge only interacts with the JP, and it needs not know how far it 328 is from the 6LBR, or how to route to the JRC. Only after 329 establishing one or more link-layer keys does it need to know about 330 the particulars of a 6TiSCH network. 332 The join process is shown as a transaction diagram in Figure 1: 334 +--------+ +-------+ +--------+ 335 | pledge | | JP | | JRC | 336 | | | | | | 337 +--------+ +-------+ +--------+ 338 | | | 339 |<---Enhanced Beacon (1)---| | 340 | | | 341 |<-Neighbor Discovery (2)->| | 342 | | | 343 |-----Join Request (3a)----|----Join Request (3a)---->| \ 344 | | | | CoJP 345 |<----Join Response (3b)---|----Join Response (3b)----| / 346 | | | 348 Figure 1: Overview of a successful join process. 350 As other nodes in the network, the 6LBR node may act as the JP. The 351 6LBR may in addition be co-located with the JRC. 353 The details of each step are described in the following sections. 355 4.1. Step 1 - Enhanced Beacon 357 The pledge synchronizes to the network by listening for, and 358 receiving, an Enhanced Beacon (EB) sent by a node already in the 359 network. This process is entirely defined by [IEEE802.15.4], and 360 described in [RFC7554]. 362 Once the pledge hears an EB, it synchronizes to the joining schedule 363 using the cells contained in the EB. The pledge can hear multiple 364 EBs; the selection of which EB to use is out of the scope for this 365 document, and is discussed in [RFC7554]. Implementers should make 366 use of information such as: what network identifier the EB contains, 367 the value of the Join Metric field within EBs, whether the source 368 link-layer address of the EB has been tried before, what signal 369 strength the different EBs were received at, etc. In addition, the 370 pledge may be pre-configured to search for EBs with a specific 371 network identifier. 373 If the pledge is not provisioned with the network identifier, it 374 attempts to join one network at a time, as described in 375 Section 8.1.1. 377 Once the pledge selects the EB, it synchronizes to it and transitions 378 into a low-power mode. It follows the schedule information contained 379 in the EB which indicates the slots that the pledge may use for the 380 join process. During the remainder of the join process, the node 381 that has sent the EB to the pledge acts as the JP. 383 At this point, the pledge may proceed to step 2, or continue to 384 listen for additional EBs. 386 4.2. Step 2 - Neighbor Discovery 388 The pledge forms its link-local IPv6 address based on the interface 389 identifier, as per [RFC4944]. The pledge MAY perform the Neighbor 390 Solicitation / Neighbor Advertisement exchange with the JP, as per 391 Section 5.5.1 of [RFC6775]. The pledge and the JP use their link- 392 local IPv6 addresses for all subsequent communication during the join 393 process. 395 Note that Neighbor Discovery exchanges at this point are not 396 protected with link-layer security as the pledge is not in possession 397 of the keys. How JP accepts these unprotected frames is discussed in 398 Section 5. 400 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution 402 The pledge triggers the join exchange of the Constrained Join 403 Protocol (CoJP). The join exchange consists of two messages: the 404 Join Request message (Step 3a), and the Join Response message 405 conditioned on the successful security processing of the request 406 (Step 3b). 408 All CoJP messages are exchanged over a secure end-to-end channel that 409 provides confidentiality, data authenticity and replay protection. 410 Frames carrying CoJP messages are not protected with link-layer 411 security when exchanged between the pledge and the JP as the pledge 412 is not in possession of the link-layer keys in use. How JP and 413 pledge accept these unprotected frames is discussed in Section 5. 414 When frames carrying CoJP messages are exchanged between nodes that 415 have already joined the network, the link-layer security is applied 416 according to the security configuration used in the network. 418 4.3.1. Step 3a - Join Request 420 The Join Request is a message sent from the pledge to the JP, and 421 which the JP forwards to the JRC. The pledge indicates in the Join 422 Request the role it requests to play in the network, as well as the 423 identifier of the network it requests to join. The JP forwards the 424 Join Request to the JRC on the existing links. How exactly this 425 happens is out of scope of this document; some networks may wish to 426 dedicate specific link layer resources for this join traffic. 428 4.3.2. Step 3b - Join Response 430 The Join Response is sent by the JRC to the pledge, and is forwarded 431 through the JP. The packet containing the Join Response travels from 432 the JRC to the JP using the operating routes in the network. The JP 433 delivers it to the pledge. The JP operates as the application-layer 434 proxy. 436 The Join Response contains different parameters needed by the pledge 437 to become a fully operational network node. These parameters include 438 the link-layer key(s) currently in use in the network, the short 439 address assigned to the pledge, the IPv6 address of the JRC needed by 440 the pledge to operate as the JP, among others. 442 4.4. The Special Case of the 6LBR Pledge Joining 444 The 6LBR pledge performs Section 4.3 of the join process described 445 above, just as any other pledge, albeit over a different network 446 interface. There is no JP intermediating the communication between 447 the 6LBR pledge and the JRC, as described in Section 6. The other 448 steps of the described join process do not apply to the 6LBR pledge. 449 How the 6LBR pledge obtains an IPv6 address and triggers the 450 execution of the CoJP protocol is out of scope of this document. 452 5. Link-layer Configuration 454 In an operational 6TiSCH network, all frames MUST use link-layer 455 frame security [RFC8180]. The IEEE Std 802.15.4 security attributes 456 MUST include frame authenticity, and MAY include frame 457 confidentiality (i.e. encryption). 459 The pledge does not initially do any authenticity check of the EB 460 frames, as it does not possess the link-layer key(s) in use. The 461 pledge is still able to parse the contents of the received EBs and 462 synchronize to the network, as EBs are not encrypted [RFC8180]. 464 When sending frames during the join process, the pledge sends 465 unencrypted and unauthenticated frames. The JP accepts these 466 unsecured frames for the duration of the join process. This behavior 467 may be implemented by setting the "secExempt" attribute in the IEEE 468 Std 802.15.4 security configuration tables. How the JP learns 469 whether the join process is ongoing is out of scope of this 470 specification. 472 As the EB itself cannot be authenticated by the pledge, an attacker 473 may craft a frame that appears to be a valid EB, since the pledge can 474 neither verify the freshness nor verify the address of the JP. This 475 opens up a DoS vector, as discussed in Section 9. 477 6. Network-layer Configuration 479 The pledge and the JP SHOULD keep a separate neighbor cache for 480 untrusted entries and use it to store each other's information during 481 the join process. Mixing neighbor entries belonging to pledges and 482 nodes that are part of the network opens up the JP to a DoS attack, 483 as the attacker may fill JP's neighbor table and prevent the 484 discovery of legitimate neighbors. 486 Once the pledge obtains link-layer keys and becomes a joined node, it 487 is able to securely communicate with its neighbors, obtain the 488 network IPv6 prefix and form its global IPv6 address. The joined 489 node then undergoes an independent process to bootstrap its neighbor 490 cache entries, possibly with a node that formerly acted as a JP, 491 following [RFC6775]. From the point of view of the JP, there is no 492 relationship between the neighbor cache entry belonging to a pledge 493 and the joined node that formerly acted as a pledge. 495 The pledge does not communicate with the JRC at the network layer. 496 This allows the pledge to join without knowing the IPv6 address of 497 the JRC. Instead, the pledge communicates with the JP at the network 498 layer using link-local addressing, and with the JRC at the 499 application layer, as specified in Section 7. 501 The JP communicates with the JRC over global IPv6 addresses. The JP 502 discovers the network IPv6 prefix and configures its global IPv6 503 address upon successful completion of the join process and the 504 obtention of link-layer keys. The pledge learns the IPv6 address of 505 the JRC from the Join Response, as specified in Section 8.1.2; it 506 uses it once joined in order to operate as a JP. 508 As a special case, the 6LBR pledge is expected to have an additional 509 network interface that it uses in order to obtain the configuration 510 parameters from the JRC and start advertising the 6TiSCH network. 511 This additional interface needs to be configured with a global IPv6 512 address, by a mechanism that is out of scope of this document. The 513 6LBR pledge uses this interface to directly communicate with the JRC 514 using global IPv6 addressing. 516 The JRC can be co-located on the 6LBR. In this special case, the 517 IPv6 address of the JRC can be omitted from the Join Response message 518 for space optimization. The 6LBR then MUST set the DODAGID field in 519 the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the 520 address of the JRC once joined and upon the reception of the first 521 RPL DIO message, and uses it to operate as a JP. 523 6.1. Identification of Unauthenticated Traffic 525 The traffic that is proxied by the Join Proxy (JP) comes from 526 unauthenticated pledges, and there may be an arbitrary amount of it. 527 In particular, an attacker may send fraudulent traffic in an attempt 528 to overwhelm the network. 530 When operating as part of a [RFC8180] 6TiSCH minimal network using 531 distributed scheduling algorithms, the traffic from unauthenticated 532 pledges may cause intermediate nodes to request additional bandwidth. 533 An attacker could use this property to cause the network to 534 overcommit bandwidth (and energy) to the join process. 536 The Join Proxy is aware of what traffic originates from 537 unauthenticated pledges, and so can avoid allocating additional 538 bandwidth itself. The Join Proxy implements a data cap on outgoing 539 join traffic through CoAP's congestion control mechanism. This cap 540 will not protect intermediate nodes as they can not tell join traffic 541 from regular traffic. Despite the data cap implemented separately on 542 each Join Proxy, the aggregate join traffic from many Join Proxies 543 may cause intermediate nodes to decide to allocate additional cells. 544 It is undesirable to do so in response to the traffic originated at 545 unauthenticated pledges. In order to permit the intermediate nodes 546 to avoid this, the traffic needs to be tagged. [RFC2597] defines a 547 set of per-hop behaviors that may be encoded into the Diffserv Code 548 Points (DSCPs). Based on the DSCP, intermediate nodes can decide 549 whether to act on a given packet. 551 6.1.1. Traffic from JP to JRC 553 The Join Proxy SHOULD set the DSCP of packets that it produces as 554 part of the forwarding process to AF43 code point (See Section 6 of 555 [RFC2597]). A Join Proxy that does not set the DSCP on traffic 556 forwarded should set it to zero so that it is compressed out. 558 A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT 559 allocate additional cells as a result of traffic with code point 560 AF43. Companion SF documents SHOULD specify how this recommended 561 behavior is achieved. 563 6.1.2. Traffic from JRC to JP 565 The JRC SHOULD set the DSCP of join response packets addressed to the 566 Join Proxy to AF42 code point. AF42 has lower drop probability than 567 AF43, giving this traffic priority in buffers over the traffic going 568 towards the JRC. 570 Due to the convergecast nature of the DODAG, the 6LBR links are often 571 the most congested, and from that point down there is progressively 572 less (or equal) congestion. If the 6LBR paces itself when sending 573 join response traffic then it ought to never exceed the bandwidth 574 allocated to the best effort traffic cells. If the 6LBR has the 575 capacity (if it is not constrained) then it should provide some 576 buffers in order to satisfy the Assured Forwarding behavior. 578 Companion SF documents SHOULD specify how traffic with code point 579 AF42 is handled with respect to cell allocation. 581 7. Application-level Configuration 583 The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and 584 the secure channel provided by OSCORE 585 [I-D.ietf-core-object-security]. The (6LBR) pledge acts as a CoAP 586 client; the JRC acts as a CoAP server. The JP implements CoAP 587 forward proxy functionality [RFC7252]. Because the JP can also be a 588 constrained device, it cannot implement a cache. 590 The pledge designates a JP as a proxy by including the Proxy-Scheme 591 option in CoAP requests it sends to the JP. The pledge also includes 592 in the requests the Uri-Host option with its value set to the well- 593 known JRC's alias, as specified in Section 8.1.1. 595 The JP resolves the alias to the IPv6 address of the JRC that it 596 learned when it acted as a pledge, and joined the network. This 597 allows the JP to reach the JRC at the network layer and forward the 598 requests on behalf of the pledge. 600 7.1. Statelessness of the JP 602 The CoAP proxy defined in [RFC7252] keeps per-client state 603 information in order to forward the response towards the originator 604 of the request. This state information includes at least the CoAP 605 token, the IPv6 address of the client, and the UDP source port 606 number. Since the JP can be a constrained device that acts as a CoAP 607 proxy, memory limitations make it prone to a Denial-of-Service (DoS) 608 attack. 610 This DoS vector on the JP can be mitigated by making the JP act as a 611 stateless CoAP proxy, where "state" encompasses the information 612 related individual pledges. The JP can wrap the state it needs to 613 keep for a given pledge throughout the network stack in a "state 614 object" and include it as a CoAP token in the forwarded request to 615 the JRC. The JP may use the CoAP token as defined in [RFC7252], if 616 the size of the serialized state object permits, or use the extended 617 CoAP token defined in [I-D.ietf-core-stateless], to transport the 618 state object. Since the CoAP token is echoed back in the response, 619 the JP is able to decode the state object and configure the state 620 needed to forward the response to the pledge. The information that 621 the JP needs to encode in the state object to operate in a fully 622 stateless manner with respect to a given pledge is implementation 623 specific. 625 It is RECOMMENDED that the JP operates in a stateless manner and 626 signals the per-pledge state within the CoAP token, for every request 627 it forwards into the network on behalf of unauthenticated pledges. 628 When operating in a stateless manner, the security considerations 629 from [I-D.ietf-core-stateless] apply and the type of the CoAP message 630 that the JP forwards on behalf of the pledge MUST be non-confirmable 631 (NON), regardless of the message type received from the pledge. The 632 use of a non-confirmable message by the JP alleviates the JP from 633 keeping CoAP message exchange state. The retransmission burden is 634 then entirely shifted to the pledge. A JP that operates in a 635 stateless manner still needs to keep congestion control state with 636 the JRC, see Section 9. Recommended values of CoAP settings for use 637 during the join process, both by the pledge and the JP, are given in 638 Section 7.2. 640 Note that in some networking stack implementations, a fully (per- 641 pledge) stateless operation of the JP may be challenging from the 642 implementation's point of view. In those cases, the JP may operate 643 as a statefull proxy that stores the per-pledge state until the 644 response is received or timed out, but this comes at a price of a DoS 645 vector. 647 7.2. Recommended Settings 649 This section gives RECOMMENDED values of CoAP settings during the 650 join process. 652 +-------------------+-----------------------+-------------------+ 653 | Name | Default Value: Pledge | Default Value: JP | 654 +-------------------+-----------------------+-------------------+ 655 | ACK_TIMEOUT | 10 seconds | (10 seconds) | 656 | | | | 657 | ACK_RANDOM_FACTOR | 1.5 | (1.5) | 658 | | | | 659 | MAX_RETRANSMIT | 4 | (4) | 660 +-------------------+-----------------------+-------------------+ 662 Recommended CoAP settings. Values enclosed in () have no effect when 663 JP operates in a stateless manner. 665 These values may be configured to values specific to the deployment. 666 The default values have been chosen to accommodate a wide range of 667 deployments, taking into account dense networks. 669 The PROBING_RATE value at the JP is controlled by the join rate 670 parameter, see Section 8.4.2. Following [RFC7252], the average data 671 rate in sending to the JRC must not exceed PROBING_RATE. For 672 security reasons, the average data rate SHOULD be measured over a 673 rather short window, e.g. ACK_TIMEOUT, see Section 9. 675 7.3. OSCORE 677 Before the (6LBR) pledge and the JRC start exchanging CoAP messages 678 protected with OSCORE, they need to derive the OSCORE security 679 context from the provisioned parameters, as discussed in Section 3. 681 The OSCORE security context MUST be derived as per Section 3 of 682 [I-D.ietf-core-object-security]. 684 o the Master Secret MUST be the PSK. 686 o the Master Salt MUST be the empty byte string. 688 o the ID Context MUST be set to the pledge identifier. 690 o the ID of the pledge MUST be set to the empty byte string. This 691 identifier is used as the OSCORE Sender ID of the pledge in the 692 security context derivation, since the pledge initially acts as a 693 CoAP client. 695 o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" 696 in ASCII). This identifier is used as the OSCORE Recipient ID of 697 the pledge in the security context derivation, as the JRC 698 initially acts as a CoAP server. 700 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 701 of-band by the same mechanism used to provision the PSK. The 702 default is AES-CCM-16-64-128. 704 o the Key Derivation Function MUST be agreed out-of-band by the same 705 mechanism used to provision the PSK. Default is HKDF SHA-256 706 [RFC5869]. 708 Since the pledge's OSCORE Sender ID is the empty byte string, when 709 constructing the OSCORE option, the pledge sets the k bit in the 710 OSCORE flag byte, but indicates a 0-length kid. The pledge 711 transports its pledge identifier within the kid context field of the 712 OSCORE option. The derivation in [I-D.ietf-core-object-security] 713 results in OSCORE keys and a common IV for each side of the 714 conversation. Nonces are constructed by XOR'ing the common IV with 715 the current sequence number. For details on nonce and OSCORE option 716 construction, refer to [I-D.ietf-core-object-security]. 718 Implementations MUST ensure that multiple CoAP requests, including to 719 different JRCs, are properly incrementing the sequence numbers, so 720 that the same sequence number is never reused in distinct requests. 721 The pledge typically sends requests to different JRCs if it is not 722 provisioned with the network identifier and attempts to join one 723 network at a time. Failure to comply will break the security 724 guarantees of the Authenticated Encryption with Associated Data 725 (AEAD) algorithm because of nonce reuse. 727 This OSCORE security context is used for initial joining of the 728 (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well 729 as for any later parameter updates, where the JRC acts as a CoAP 730 client and the joined node as a CoAP server, as discussed in 731 Section 8.2. Note that when the (6LBR) pledge and the JRC change 732 roles between CoAP client and CoAP server, the same OSCORE security 733 context as initially derived remains in use and the derived 734 parameters are unchanged, for example Sender ID when sending and 735 Recipient ID when receiving (see Section 3.1 of 736 [I-D.ietf-core-object-security]). A (6LBR) pledge is expected to 737 have exactly one OSCORE security context with the JRC. 739 7.3.1. Replay Window and Persistency 741 Both (6LBR) pledge and the JRC MUST implement a replay protection 742 mechanism. The use of the default OSCORE replay protection mechanism 743 specified in Section 3.2.2 of [I-D.ietf-core-object-security] is 744 RECOMMENDED. 746 Implementations MUST ensure that mutable OSCORE context parameters 747 (Sender Sequence Number, Replay Window) are stored in persistent 748 memory. A technique that prevents reuse of sequence numbers, 749 detailed in Appendix B.1.1 of [I-D.ietf-core-object-security], MUST 750 be implemented. Each update of the OSCORE Replay Window MUST be 751 written to persistent memory. 753 This is an important security requirement in order to guarantee nonce 754 uniqueness and resistance to replay attacks across reboots and 755 rejoins. Traffic between the (6LBR) pledge and the JRC is rare, 756 making security outweigh the cost of writing to persistent memory. 758 7.3.2. OSCORE Error Handling 760 Errors raised by OSCORE during the join process MUST be silently 761 dropped, with no error response being signaled. The pledge MUST 762 silently discard any response not protected with OSCORE, including 763 error codes. 765 Such errors may happen for a number of reasons, including failed 766 lookup of an appropriate security context (e.g. the pledge attempting 767 to join a wrong network), failed decryption, positive replay window 768 lookup, formatting errors (possibly due to malicious alterations in 769 transit). Silently dropping OSCORE messages prevents a DoS attack on 770 the pledge where the attacker could send bogus error responses, 771 forcing the pledge to attempt joining one network at a time, until 772 all networks have been tried. 774 7.3.3. Mandatory to Implement Algorithms 776 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 777 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 778 securing IEEE Std 802.15.4 frames, and hardware acceleration for it 779 is present in virtually all compliant radio chips. With this choice, 780 CoAP messages are protected with an 8-byte CCM authentication tag, 781 and the algorithm uses 13-byte long nonces. 783 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The 784 mandatory to implement key derivation function is HKDF [RFC5869], 785 instantiated with a SHA-256 hash. See Appendix B for implementation 786 guidance when code footprint is important. 788 8. Constrained Join Protocol (CoJP) 790 The Constrained Join Protocol (CoJP) is a lightweight protocol over 791 CoAP [RFC7252] and a secure channel provided by OSCORE 792 [I-D.ietf-core-object-security]. CoJP allows the (6LBR) pledge to 793 request admission into a network managed by the JRC, and for the JRC 794 to configure the pledge with the parameters necessary for joining the 795 network, or advertising it in the case of 6LBR pledge. The JRC may 796 update the parameters at any time, by reaching out to the joined node 797 that formerly acted as a (6LBR) pledge. For example, network-wide 798 rekeying can be implemented by updating the keying material on each 799 node. 801 This section specifies how the CoJP messages are mapped to CoAP and 802 OSCORE, CBOR data structures carrying different parameters, 803 transported within CoAP payload, and the parameter semantics and 804 processing rules. 806 CoJP relies on the security properties provided by OSCORE. This 807 includes end-to-end confidentiality, data authenticity, replay 808 protection, and a secure binding of responses to requests. 810 +-----------------------------------+ 811 | Constrained Join Protocol (CoJP) | 812 +-----------------------------------+ 813 +-----------------------------------+ \ 814 | Requests / Responses | | 815 |-----------------------------------| | 816 | OSCORE | | CoAP 817 |-----------------------------------| | 818 | Messaging Layer | | 819 +-----------------------------------+ / 820 +-----------------------------------+ 821 | UDP | 822 +-----------------------------------+ 824 Figure 2: Abstract layering of CoJP. 826 When a (6LBR) pledge requests admission to a given network, it 827 undergoes the CoJP join exchange that consists of: 829 o the Join Request message, sent by the (6LBR) pledge to the JRC, 830 potentially proxied by the JP. The Join Request message and its 831 mapping to CoAP is specified in Section 8.1.1. 833 o the Join Response message, sent by the JRC to the (6LBR) pledge, 834 if the JRC successfully processes the Join Request using OSCORE 835 and it determines through a mechanism that is out of scope of this 836 specification that the (6LBR) pledge is authorized to join the 837 network. The Join Response message is potentially proxied by the 838 JP. The Join Response message and its mapping to CoAP is 839 specified in Section 8.1.2. 841 When the JRC needs to update the parameters of a joined node that 842 formerly acted as a (6LBR) pledge, it executes the CoJP parameter 843 update exchange that consists of: 845 o the Parameter Update message, sent by the JRC to the joined node 846 that formerly acted as a (6LBR) pledge. The Parameter Update 847 message and its mapping to CoAP is specified in Section 8.2.1. 849 o the Parameter Update Response message, sent by the joined node to 850 the JRC in response to the Parameter Update message to signal 851 successful reception of the updated parameters. The Parameter 852 Update Response message and its mapping to CoAP is specified in 853 Section 8.2.2. 855 The payload of CoJP messages is encoded with CBOR [RFC7049]. The 856 CBOR data structures that may appear as the payload of different CoJP 857 messages are specified in Section 8.4. 859 8.1. Join Exchange 861 This section specifies the messages exchanged when the (6LBR) pledge 862 requests admission and configuration parameters from the JRC. 864 8.1.1. Join Request Message 866 The Join Request message that the (6LBR) pledge sends SHALL be mapped 867 to a CoAP request: 869 o The request method is POST. 871 o The type is Confirmable (CON). 873 o The Proxy-Scheme option is set to "coap". 875 o The Uri-Host option is set to "6tisch.arpa". This is an anycast 876 type of identifier of the JRC that is resolved to its IPv6 address 877 by the JP or the 6LBR pledge. 879 o The Uri-Path option is set to "j". 881 o The OSCORE option SHALL be set according to 882 [I-D.ietf-core-object-security]. The OSCORE security context used 883 is the one derived in Section 7.3. The OSCORE kid context allows 884 the JRC to retrieve the security context for a given pledge. 886 o The payload is a Join_Request CBOR object, as defined in 887 Section 8.4.1. 889 Since the Join Request is a confirmable message, the transmission at 890 (6LBR) pledge will be controlled by CoAP's retransmission mechanism. 891 The JP, when operating in a stateless manner, forwards this Join 892 Request as a non-confirmable (NON) CoAP message, as specified in 893 Section 7. If the CoAP at (6LBR) pledge declares the message 894 transmission as failure, the (6LBR) pledge SHOULD attempt to join the 895 next advertised 6TiSCH network. See Section 7.2 for recommended 896 values of CoAP settings to use during the join exchange. 898 If all join attempts to advertised networks have failed, the (6LBR) 899 pledge SHOULD signal to the user the presence of an error condition, 900 through some out-of-band mechanism. 902 8.1.2. Join Response Message 904 The Join Response message that the JRC sends SHALL be mapped to a 905 CoAP response: 907 o The response Code is 2.04 (Changed). 909 o The payload is a Configuration CBOR object, as defined in 910 Section 8.4.2. 912 8.2. Parameter Update Exchange 914 During the network lifetime, parameters returned as part of the Join 915 Response may need to be updated. One typical example is the update 916 of link-layer keying material for the network, a process known as 917 rekeying. This section specifies a generic mechanism when this 918 parameter update is initiated by the JRC. 920 At the time of the join, the (6LBR) pledge acts as a CoAP client and 921 requests the network parameters through a representation of the "/j" 922 resource, exposed by the JRC. In order for the update of these 923 parameters to happen, the JRC needs to asynchronously contact the 924 joined node. The use of the CoAP Observe option for this purpose is 925 not feasible due to the change in the IPv6 address when the pledge 926 becomes the joined node and obtains a global address. 928 Instead, once the (6LBR) pledge receives and successfully validates 929 the Join Response and so becomes a joined node, it becomes a CoAP 930 server. The joined node exposes the "/j" resource that is used by 931 the JRC to update the parameters. Consequently, the JRC operates as 932 a CoAP client when updating the parameters. The request/response 933 exchange between the JRC and the (6LBR) pledge happens over the 934 already-established OSCORE secure channel. 936 8.2.1. Parameter Update Message 938 The Parameter Update message that the JRC sends to the joined node 939 SHALL be mapped to a CoAP request: 941 o The request method is POST. 943 o The type is Confirmable (CON). 945 o The Uri-Path option is set to "j". 947 o The OSCORE option SHALL be set according to 948 [I-D.ietf-core-object-security]. The OSCORE security context used 949 is the one derived in Section 7.3. When a joined node receives a 950 request with the Sender ID set to 0x4a5243 (ID of the JRC), it is 951 able to correctly retrieve the security context with the JRC. 953 o The payload is a Configuration CBOR object, as defined in 954 Section 8.4.2. 956 The JRC has implicit knowledge on the global IPv6 address of the 957 joined node, as it knows the pledge identifier that the joined node 958 used when it acted as a pledge, and the IPv6 network prefix. The JRC 959 uses this implicitly derived IPv6 address of the joined node to 960 directly address CoAP messages to it. 962 In case the JRC does not receive a response to a Parameter Update 963 message, it attempts multiple retransmissions, as configured by the 964 underlying CoAP retransmission mechanism triggered for confirmable 965 messages. Finally, if the CoAP implementation declares the 966 transmission as failure, the JRC may consider this as a hint that the 967 joined node is no longer in the network. How the JRC decides when to 968 stop attempting to contact a previously joined node is out of scope 969 of this specification but security considerations on the reuse of 970 assigned resources apply, as discussed in Section 9. 972 8.2.2. Parameter Update Response Message 974 The Parameter Update Response message that the joined node sends to 975 the JRC SHALL be mapped to a CoAP response: 977 o The response Code is 2.04 (Changed). 979 o The payload is empty. 981 8.3. Error Handling 983 8.3.1. CoJP CBOR Object Processing 985 CoJP CBOR objects are transported within both CoAP requests and 986 responses. This section describes handling in case certain CoJP CBOR 987 object parameters are not supported by the implementation or their 988 processing fails. See Section 7.3.2 for the handling of errors that 989 may be raised by the underlying OSCORE implementation. 991 When such a parameter is detected in a CoAP request (Join Request 992 message, Parameter Update message), a Diagnostic Response message 993 MUST be returned. A Diagnostic Response message maps to a CoAP 994 response and is specified in Section 8.3.2. 996 When a parameter that cannot be acted upon is encountered while 997 processing a CoJP object in a CoAP response (Join Response message), 998 a (6LBR) pledge SHOULD reattempt to join. In this case, the (6LBR) 999 pledge SHOULD include the Unsupported Configuration CBOR object 1000 within the Join Request object in the following Join Request message. 1001 The Unsupported Configuration CBOR object is self-contained and 1002 enables the (6LBR) pledge to signal any parameters that the 1003 implementation of the networking stack may not support. A (6LBR) 1004 pledge MUST NOT attempt more than MAX_RETRANSMIT number of attempts 1005 to join if the processing of the Join Response message fails each 1006 time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached 1007 without success, the (6LBR) pledge SHOULD signal to the user the 1008 presence of an error condition, through some out-of-band mechanism. 1010 8.3.2. Diagnostic Response Message 1012 The Diagnostic Response message is returned for any CoJP request when 1013 the processing of the payload failed. The Diagnostic Response 1014 message is protected by OSCORE as any other CoJP protocol message. 1016 The Diagnostic Response message SHALL be mapped to a CoAP response: 1018 o The response Code is 4.00 (Bad Request). 1020 o The payload is an Unsupported Configuration CBOR object, as 1021 defined in Section 8.4.5, containing more information about the 1022 parameter that triggered the sending of this message. 1024 8.3.3. Failure Handling 1026 The Parameter Update exchange may be triggered at any time during the 1027 network lifetime, which may span several years. During this period, 1028 it may occur that a joined node or the JRC experience unexpected 1029 events such as reboots or complete failures. 1031 This document mandates that the mutable parameters in the security 1032 context are written to persistent memory (see Section 7.3.1) by both 1033 the JRC and pledges (joined nodes). As the joined node (pledge) is 1034 typically a constrained device that handles the write operations to 1035 persistent memory in a predictable manner, the retrieval of mutable 1036 security context parameters is feasible across reboots such that 1037 there is no risk of AEAD nonce reuse due to reinitialized Sender 1038 Sequence numbers, or of a replay attack due to the reinitialized 1039 replay window. JRC may be hosted on a generic machine where the 1040 write operation to persistent memory may lead to unpredictable delays 1041 due to caching. In case of a reboot event at JRC occurring before 1042 the cached data is written to persistent memory, the loss of mutable 1043 security context parameters is likely which consequently poses the 1044 risk of AEAD nonce reuse. 1046 In the event of a complete device failure, where the mutable security 1047 context parameters cannot be retrieved, it is expected that a failed 1048 joined node is replaced with a new physical device, using a new 1049 pledge identifier and a PSK. When such a failure event occurs at the 1050 JRC, it is possible that the static information on provisioned 1051 pledges, like PSKs and pledge identifiers, can be retrieved through 1052 available backups. However, it is likely that the information about 1053 joined nodes, their assigned short identifiers and mutable security 1054 context parameters is lost. If this is the case, during the process 1055 of JRC reinitialization, the network administrator MUST force through 1056 out-of-band means all the networks managed by the failed JRC to 1057 rejoin, through e.g. the reinitialization of the 6LBR nodes and 1058 freshly generated dynamic cryptographic keys and other parameters 1059 that have influence on the security properties of the network. 1061 In order to recover from such a failure event, the reinitialized JRC 1062 can trigger the renegotiation of the OSCORE security context through 1063 the procedure described in Appendix B.2 of 1064 [I-D.ietf-core-object-security]. Aware of the failure event, the 1065 reinitialized JRC responds to the first join request of each pledge 1066 it is managing with a 4.01 Unauthorized error and a random nonce. 1067 The pledge verifies the error response and then initiates the CoJP 1068 join exchange using a new OSCORE security context derived from an ID 1069 Context consisting of the concatenation of two nonces, one that it 1070 received from the JRC and the other that the pledge generates 1071 locally. After verifying the join request with the new ID Context 1072 and the derived OSCORE security context, the JRC should consequently 1073 take action in mapping the new ID Context with the previously used 1074 pledge identifier. How JRC handles this mapping is implementation 1075 specific. 1077 The described procedure is specified in Appendix B.2 of 1078 [I-D.ietf-core-object-security] and is RECOMMENDED in order to handle 1079 the failure events or any other event that may lead to the loss of 1080 mutable security context parameters. The length of nonces exchanged 1081 using this procedure SHOULD be at least 8 bytes. 1083 The procedure does require both the pledge and the JRC to have good 1084 sources of randomness. While this is typically not an issue at the 1085 JRC side, the constrained device hosting the pledge may pose 1086 limitations in this regard. If the procedure outlined in 1087 Appendix B.2 of [I-D.ietf-core-object-security] is not supported by 1088 the pledge, the network administrator MUST take action in 1089 reprovisioning the concerned devices with freshly generated 1090 parameters, through out-of-band means. 1092 8.4. CoJP Objects 1094 This section specifies the structure of CoJP CBOR objects that may be 1095 carried as the payload of CoJP messages. Some of these objects may 1096 be received both as part of the CoJP join exchange when the device 1097 operates as a (CoJP) pledge, or the parameter update exchange, when 1098 the device operates as a joined (6LBR) node. 1100 8.4.1. Join Request Object 1102 The Join_Request structure is built on a CBOR map object. 1104 The set of parameters that can appear in a Join_Request object is 1105 summarized below. The labels can be found in the "CoJP Parameters" 1106 registry Section 11.1. 1108 o role: The identifier of the role that the pledge requests to play 1109 in the network once it joins, encoded as an unsigned integer. 1110 Possible values are specified in Table 1. This parameter MAY be 1111 included. In case the parameter is omitted, the default value of 1112 0, i.e. the role "6TiSCH Node", MUST be assumed. 1114 o network identifier: The identifier of the network, as discussed in 1115 Section 3, encoded as a CBOR byte string. When present in the 1116 Join_Request, it hints to the JRC the network that the pledge is 1117 requesting to join, enabling the JRC to manage multiple networks. 1118 The pledge obtains the value of the network identifier from the 1119 received EB frames. This parameter MUST be included in a 1120 Join_Request object regardless of the role parameter value. 1122 o unsupported configuration: The identifier of the parameters that 1123 are not supported by the implementation, encoded as an 1124 Unsupported_Configuration object described in Section 8.4.5. This 1125 parameter MAY be included. If a (6LBR) pledge previously 1126 attempted to join and received a valid Join Response message over 1127 OSCORE, but failed to act on its payload (Configuration object), 1128 it SHOULD include this parameter to facilitate the recovery and 1129 debugging. 1131 The CDDL fragment that represents the text above for the Join_Request 1132 follows. 1134 Join_Request = { 1135 ? 1 : uint, ; role 1136 ? 5 : bstr, ; network identifier 1137 ? 8 : Unsupported_Configuration ; unsupported configuration 1138 } 1139 +--------+-------+-------------------------------------+------------+ 1140 | Name | Value | Description | Reference | 1141 +--------+-------+-------------------------------------+------------+ 1142 | 6TiSCH | 0 | The pledge requests to play the | [[this | 1143 | Node | | role of a regular 6TiSCH node, i.e. | document]] | 1144 | | | non-6LBR node. | | 1145 | | | | | 1146 | 6LBR | 1 | The pledge requests to play the | [[this | 1147 | | | role of 6LoWPAN Border Router | document]] | 1148 | | | (6LBR). | | 1149 +--------+-------+-------------------------------------+------------+ 1151 Table 1: Role values. 1153 8.4.2. Configuration Object 1155 The Configuration structure is built on a CBOR map object. The set 1156 of parameters that can appear in a Configuration object is summarized 1157 below. The labels can be found in "CoJP Parameters" registry 1158 Section 11.1. 1160 o link-layer key set: An array encompassing a set of cryptographic 1161 keys and their identifiers that are currently in use in the 1162 network, or that are scheduled to be used in the future. The 1163 encoding of individual keys is described in Section 8.4.3. The 1164 link-layer key set parameter MAY be included in a Configuration 1165 object. When present, the link-layer key set parameter MUST 1166 contain at least one key. When a pledge is joining for the first 1167 time and receives this parameter, before sending the first 1168 outgoing frame secured with a received key, the pledge needs to 1169 successfully complete the security processing of an incoming 1170 frame. To do so, the pledge can wait to receive a new frame, or 1171 it can store an EB frame that it used to find the JP and use it 1172 for immediate security processing upon reception of the key set. 1173 This parameter is also used to implement rekeying in the network. 1174 How the keys are installed and used differs for the 6LBR and other 1175 (regular) nodes, and this is explained in Section 8.4.3.1 and 1176 Section 8.4.3.2. 1178 o short identifier: a compact identifier assigned to the pledge. 1179 The short identifier structure is described in Section 8.4.4. The 1180 short identifier parameter MAY be included in a Configuration 1181 object. 1183 o JRC address: the IPv6 address of the JRC, encoded as a byte 1184 string, with the length of 16 bytes. If the length of the byte 1185 string is different from 16, the parameter MUST be discarded. If 1186 the JRC is not co-located with the 6LBR and has a different IPv6 1187 address than the 6LBR, this parameter MUST be included. In the 1188 special case where the JRC is co-located with the 6LBR and has the 1189 same IPv6 address as the 6LBR, this parameter MAY be included. If 1190 the JRC address parameter is not present in the Configuration 1191 object, this indicates that the JRC has the same IPv6 address as 1192 the 6LBR. The joined node can then discover the IPv6 address of 1193 the JRC through network control traffic. See Section 6. 1195 o blacklist: An array encompassing a list of pledge identifiers that 1196 are blacklisted by the JRC, with each pledge identifier encoded as 1197 a byte string. The blacklist parameter MAY be included in a 1198 Configuration object. When present, the array MUST contain zero 1199 or more byte strings encoding pledge identifiers. The joined node 1200 MUST silently drop any link-layer frames originating from the 1201 pledge identifiers enclosed in the blacklist parameter. When this 1202 parameter is received, its value MUST overwrite any previously set 1203 values. This parameter allows the JRC to configure the node 1204 acting as a JP to filter out traffic from misconfigured or 1205 malicious pledges before their traffic is forwarded into the 1206 network. If the JRC decides to remove a given pledge identifier 1207 from a blacklist, it omits the pledge identifier in the blacklist 1208 parameter value it sends next. 1210 o join rate: Average data rate of join traffic forwarded into the 1211 network that should not be exceeded when a joined node operates as 1212 a JP, encoded as an unsigned integer in bytes per second. The 1213 join rate parameter MAY be included in a Configuration object. 1214 This parameter allows the JRC to configure different nodes in the 1215 network to operate as JP, and act in case of an attack by 1216 throttling the rate at which JP forwards unauthenticated traffic 1217 into the network. When this parameter is present in a 1218 Configuration object, the value MUST be used to set the 1219 PROBING_RATE of CoAP at the joined node for communication with the 1220 JRC. In case this parameter is set to zero, a joined node MUST 1221 silently drop any join traffic coming from unauthenticated 1222 pledges. In case this parameter is omitted, the value of positive 1223 infinity SHOULD be assumed. Node operating as a JP MAY use 1224 another mechanism that is out of scope of this specification to 1225 configure PROBING_RATE of CoAP in the absence of join rate 1226 parameter from the Configuration object. 1228 The CDDL fragment that represents the text above for the 1229 Configuration follows. Structures Link_Layer_Key and 1230 Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. 1232 Configuration = { 1233 ? 2 : [ +Link_Layer_Key ], ; link-layer key set 1234 ? 3 : Short_Identifier, ; short identifier 1235 ? 4 : bstr, ; JRC address 1236 ? 6 : [ *bstr ], ; blacklist 1237 ? 7 : uint ; join rate 1238 } 1239 +---------------+-------+----------+-------------------+------------+ 1240 | Name | Label | CBOR | Description | Reference | 1241 | | | type | | | 1242 +---------------+-------+----------+-------------------+------------+ 1243 | role | 1 | unsigned | Identifies the | [[this | 1244 | | | integer | role parameter | document]] | 1245 | | | | | | 1246 | link-layer | 2 | array | Identifies the | [[this | 1247 | key set | | | array carrying | document]] | 1248 | | | | one or more link- | | 1249 | | | | level | | 1250 | | | | cryptographic | | 1251 | | | | keys | | 1252 | | | | | | 1253 | short | 3 | array | Identifies the | [[this | 1254 | identifier | | | assigned short | document]] | 1255 | | | | identifier | | 1256 | | | | | | 1257 | JRC address | 4 | byte | Identifies the | [[this | 1258 | | | string | IPv6 address of | document]] | 1259 | | | | the JRC | | 1260 | | | | | | 1261 | network | 5 | byte | Identifies the | [[this | 1262 | identifier | | string | network | document]] | 1263 | | | | identifier | | 1264 | | | | parameter | | 1265 | | | | | | 1266 | blacklist | 6 | array | Identifies the | [[this | 1267 | | | | blacklist | document]] | 1268 | | | | parameter | | 1269 | | | | | | 1270 | join rate | 7 | unsigned | Identifier the | [[this | 1271 | | | integer | join rate | document]] | 1272 | | | | parameter | | 1273 | | | | | | 1274 | unsupported | 8 | array | Identifies the | [[this | 1275 | configuration | | | unsupported | document]] | 1276 | | | | configuration | | 1277 | | | | parameter | | 1278 +---------------+-------+----------+-------------------+------------+ 1280 Table 2: CoJP parameters map labels. 1282 8.4.3. Link-Layer Key 1284 The Link_Layer_Key structure encompasses the parameters needed to 1285 configure the link-layer security module: the key identifier; the 1286 value of the cryptographic key; the link-layer algorithm identifier 1287 and the security level and the frame types that it should be used 1288 with, both for outgoing and incoming security operations; and any 1289 additional information that may be needed to configure the key. 1291 For encoding compactness, the Link_Layer_Key object is not enclosed 1292 in a top-level CBOR object. Rather, it is transported as a sequence 1293 of CBOR elements, some being optional. 1295 The set of parameters that can appear in a Link_Layer_Key object is 1296 summarized below, in order: 1298 o key_id: The identifier of the key, encoded as a CBOR unsigned 1299 integer. This parameter MUST be included. If the decoded CBOR 1300 unsigned integer value is larger than the maximum link-layer key 1301 identifier, the key is considered invalid. In case the key is 1302 considered invalid, the key MUST be discarded and the 1303 implementation MUST signal the error as specified in 1304 Section 8.3.1. 1306 o key_usage: The identifier of the link-layer algorithm, security 1307 level and link-layer frame types that can be used with the key, 1308 encoded as an integer. This parameter MAY be included. Possible 1309 values and the corresponding link-layer settings are specified in 1310 IANA "CoJP Key Usage" registry (Section 11.2). In case the 1311 parameter is omitted, the default value of 0 from Table 3 MUST be 1312 assumed. 1314 o key_value: The value of the cryptographic key, encoded as a byte 1315 string. This parameter MUST be included. If the length of the 1316 byte string is different than the corresponding key length for a 1317 given algorithm specified by the key_usage parameter, the key MUST 1318 be discarded and the implementation MUST signal the error as 1319 specified in Section 8.3.1. 1321 o key_addinfo: Additional information needed to configure the link- 1322 layer key, encoded as a byte string. This parameter MAY be 1323 included. The processing of this parameter is dependent on the 1324 link-layer technology in use and a particular keying mode. 1326 To be able to decode the keys that are present in the link-layer key 1327 set, and to identify individual parameters of a single Link_Layer_Key 1328 object, the CBOR decoder needs to differentiate between elements 1329 based on the CBOR type. For example, a uint that follows a byte 1330 string signals to the decoder that a new Link_Layer_Key object is 1331 being processed. 1333 The CDDL fragment that represents the text above for the 1334 Link_Layer_Key follows. 1336 Link_Layer_Key = ( 1337 key_id : uint, 1338 ? key_usage : int, 1339 key_value : bstr, 1340 ? key_addinfo : bstr, 1341 ) 1343 +-----------------+-----+------------------+-------------+----------+ 1344 | Name | Val | Algorithm | Description | Referenc | 1345 | | ue | | | e | 1346 +-----------------+-----+------------------+-------------+----------+ 1347 | 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | 1348 | -ENC-MIC32 | | CCM-128 | for EBs, | ocument] | 1349 | | | | ENC-MIC-32 | ] | 1350 | | | | for DATA | | 1351 | | | | and ACKNOWL | | 1352 | | | | EDGMENT. | | 1353 | | | | | | 1354 | 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | 1355 | -ENC-MIC64 | | CCM-128 | for EBs, | ocument] | 1356 | | | | ENC-MIC-64 | ] | 1357 | | | | for DATA | | 1358 | | | | and ACKNOWL | | 1359 | | | | EDGMENT. | | 1360 | | | | | | 1361 | 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | 1362 | -ENC-MIC128 | | CCM-128 | for EBs, | ocument] | 1363 | | | | ENC-MIC-128 | ] | 1364 | | | | for DATA | | 1365 | | | | and ACKNOWL | | 1366 | | | | EDGMENT. | | 1367 | | | | | | 1368 | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | 1369 | K1K2-MIC32 | | CCM-128 | for EBs, | ocument] | 1370 | | | | DATA and AC | ] | 1371 | | | | KNOWLEDGMEN | | 1372 | | | | T. | | 1373 | | | | | | 1374 | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | 1375 | K1K2-MIC64 | | CCM-128 | for EBs, | ocument] | 1376 | | | | DATA and AC | ] | 1377 | | | | KNOWLEDGMEN | | 1378 | | | | T. | | 1379 | | | | | | 1380 | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | 1381 | K1K2-MIC128 | | CCM-128 | for EBs, | ocument] | 1382 | | | | DATA and AC | ] | 1383 | | | | KNOWLEDGMEN | | 1384 | | | | T. | | 1385 | | | | | | 1386 | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | 1387 | | | CCM-128 | for EBs. | ocument] | 1388 | | | | | ] | 1389 | | | | | | 1390 | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | 1391 | | | CCM-128 | for EBs. | ocument] | 1392 | | | | | ] | 1393 | | | | | | 1394 | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | 1395 | 8 | | CCM-128 | for EBs. | ocument] | 1396 | | | | | ] | 1397 | | | | | | 1398 | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | 1399 | | | CCM-128 | for DATA | ocument] | 1400 | | | | and ACKNOWL | ] | 1401 | | | | EDGMENT. | | 1402 | | | | | | 1403 | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | 1404 | | | CCM-128 | for DATA | ocument] | 1405 | | | | and ACKNOWL | ] | 1406 | | | | EDGMENT. | | 1407 | | | | | | 1408 | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | 1409 | 8 | | CCM-128 | for DATA | ocument] | 1410 | | | | and ACKNOWL | ] | 1411 | | | | EDGMENT. | | 1412 | | | | | | 1413 | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | 1414 | MIC32 | | CCM-128 | MIC-32 for | ocument] | 1415 | | | | DATA and AC | ] | 1416 | | | | KNOWLEDGMEN | | 1417 | | | | T. | | 1418 | | | | | | 1419 | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | 1420 | MIC64 | | CCM-128 | MIC-64 for | ocument] | 1421 | | | | DATA and AC | ] | 1422 | | | | KNOWLEDGMEN | | 1423 | | | | T. | | 1424 | | | | | | 1425 | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | 1426 | MIC128 | | CCM-128 | MIC-128 for | ocument] | 1427 | | | | DATA and AC | ] | 1428 | | | | KNOWLEDGMEN | | 1429 | | | | T. | | 1430 +-----------------+-----+------------------+-------------+----------+ 1431 Table 3: Key Usage values. 1433 8.4.3.1. Rekeying of (6LoWPAN) Border Routers (6LBR) 1435 When the 6LoWPAN Border Router (6LBR) receives the Configuration 1436 object containing a link-layer key set, it MUST immediately install 1437 and start using the new keys for all outgoing traffic, and remove any 1438 old keys it has installed from the previous key set after a delay of 1439 COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the 1440 JRC to force the 6LBR to start sending traffic with the new key. The 1441 decision is taken by the JRC when it has determined that the new key 1442 has been made available to all (or some overwhelming majority) of 1443 nodes. Any node that the JRC has not yet reached at that point is 1444 either non-functional or in extended sleep such that it will not be 1445 reached. To get the key update, such node needs to go through the 1446 join process anew. 1448 8.4.3.2. Rekeying of regular (6LoWPAN) Nodes (6LN) 1450 When a regular 6LN node receives the Configuration object with a 1451 link-layer key set, it MUST install the new keys. The 6LN will use 1452 both the old and the new keys to decrypt and authenticate any 1453 incoming traffic that arrives based upon the key identifier in the 1454 packet. It MUST continue to use the old keys for all outgoing 1455 traffic until it has detected that the network has switched to the 1456 new key set. 1458 The detection of network switch is based upon the receipt of traffic 1459 secured with the new keys. Upon reception and successful security 1460 processing of a link-layer frame secured with a key from the new key 1461 set, a 6LN node MUST then switch to sending outgoing traffic using 1462 the keys from the new set for all outgoing traffic. The 6LN node 1463 MUST remove any old keys it has installed from the previous key set 1464 after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts 1465 using the new key set. 1467 Sending of traffic with the new keys signals to other downstream 1468 nodes to switch to their new key, and the affect is that there is a 1469 ripple of key updates in outward concentric circles around each 6LBR. 1471 8.4.3.3. Use in IEEE Std 802.15.4 1473 When Link_Layer_Key is used in the context of [IEEE802.15.4], the 1474 following considerations apply. 1476 Signaling of different keying modes of [IEEE802.15.4] is done based 1477 on the parameter values present in a Link_Layer_Key object. 1479 o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be 1480 set to 0. key_addinfo parameter MUST be present. key_addinfo 1481 parameter MUST be set to the link-layer address(es) of a single 1482 peer with whom the key should be used. Depending on the 1483 configuration of the network, key_addinfo may carry the peer's 1484 long link-layer address (i.e. pledge identifier), short link-layer 1485 address, or their concatenation with the long address being 1486 encoded first. Which address is carried is determined from the 1487 length of the byte string. 1489 o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a 1490 value different than 0. key_addinfo parameter MUST NOT be 1491 present. 1493 o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter 1494 MUST be set to a value different than 0. key_addinfo parameter 1495 MUST be present. key_addinfo parameter MUST be set to a byte 1496 string, exactly 4 bytes long. key_addinfo parameter carries the 1497 Key Source parameter used to configure [IEEE802.15.4]. 1499 o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter 1500 MUST be set to a value different than 0. key_addinfo parameter 1501 MUST be present. key_addinfo parameter MUST be set to a byte 1502 string, exactly 8 bytes long. key_addinfo parameter carries the 1503 Key Source parameter used to configure [IEEE802.15.4]. 1505 In all cases, key_usage parameter determines how a particular key 1506 should be used in respect to incoming and outgoing security policies. 1508 For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" 1509 parameter of {{IEEE802.15.4} that is signaled in all outgoing frames 1510 secured with a given key. The maximum value key_id can have is 254. 1511 The value of 255 is reserved in {{IEEE802.15.4} and is therefore 1512 considered invalid. 1514 Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a 1515 trusted third party and assign pairwise keys between nodes in the 1516 network. How JRC learns about the network topology is out of scope 1517 of this specification, but could be done through 6LBR - JRC signaling 1518 for example. Pairwise keys could also be derived through a key 1519 agreement protocol executed between the peers directly, where the 1520 authentication is based on the symmetric cryptographic material 1521 provided to both peers by the JRC. Such a protocol is out of scope 1522 of this specification. 1524 8.4.4. Short Identifier 1526 The Short_Identifier object represents an identifier assigned to the 1527 pledge. It is encoded as a CBOR array object, containing, in order: 1529 o identifier: The short identifier assigned to the pledge, encoded 1530 as a byte string. This parameter MUST be included. The 1531 identifier MUST be unique in the set of all identifiers assigned 1532 in a network that is managed by a JRC. In case the identifier is 1533 invalid, the decoder MUST silently ignore the Short_Identifier 1534 object. 1536 o lease_time: The validity of the identifier in hours after the 1537 reception of the CBOR object, encoded as a CBOR unsigned integer. 1538 This parameter MAY be included. The node MUST stop using the 1539 assigned short identifier after the expiry of the lease_time 1540 interval. It is up to the JRC to renew the lease before the 1541 expiry of the previous interval. The JRC updates the lease by 1542 executing the Parameter Update exchange with the node and 1543 including the Short_Identifier in the Configuration object, as 1544 described in Section 8.2. In case the lease expires, the node 1545 SHOULD initiate a new join exchange, as described in Section 8.1. 1546 In case this parameter is omitted, the value of positive infinity 1547 MUST be assumed, meaning that the identifier is valid for as long 1548 as the node participates in the network. 1550 The CDDL fragment that represents the text above for the 1551 Short_Identifier follows. 1553 Short_Identifier = [ 1554 identifier : bstr, 1555 ? lease_time : uint 1556 ] 1558 8.4.4.1. Use in IEEE Std 802.15.4 1560 When Short_Identifier is used in the context of [IEEE802.15.4], the 1561 following considerations apply. 1563 The identifier MUST be used to set the short address of IEEE Std 1564 802.15.4 module. When operating in TSCH mode, the identifier MUST be 1565 unique in the set of all identifiers assigned in multiple networks 1566 that share link-layer key(s). If the length of the byte string 1567 corresponding to the identifier parameter is different than 2, the 1568 identifier is considered invalid. The values 0xfffe and 0xffff are 1569 reserved by [IEEE802.15.4] and their use is considered invalid. 1571 The security properties offered by the [IEEE802.15.4] link-layer in 1572 TSCH mode are conditioned on the uniqueness requirement of the short 1573 identifier (i.e. short address). The short address is one of the 1574 inputs in the construction of the nonce, which is used to protect 1575 link-layer frames. If a misconfiguration occurs, and the same short 1576 address is assigned twice under the same link-layer key, the loss of 1577 security properties is eminent. For this reason, practices where the 1578 pledge generates the short identifier locally are not safe and are 1579 likely to result in the loss of link-layer security properties. 1581 The JRC MUST ensure that at any given time there are never two same 1582 short identifiers being used under the same link-layer key. If the 1583 lease_time parameter of a given Short_Identifier object is set to 1584 positive infinity, care needs to be taken that the corresponding 1585 identifier is not assigned to another node until the JRC is certain 1586 that it is no longer in use, potentially through out-of-band 1587 signaling. If the lease_time parameter expires for any reason, the 1588 JRC should take into consideration potential ongoing transmissions by 1589 the joined node, which may be hanging in the queues, before assigning 1590 the same identifier to another node. 1592 8.4.5. Unsupported Configuration Object 1594 The Unsupported_Configuration object is encoded as a CBOR array, 1595 containing at least one Unsupported_Parameter object. Each 1596 Unsupported_Parameter object is a sequence of CBOR elements without 1597 an enclosing top-level CBOR object for compactness. The set of 1598 parameters that appear in an Unsupported_Parameter object is 1599 summarized below, in order: 1601 o code: Indicates the capability of acting on the parameter signaled 1602 by parameter_label, encoded as an integer. This parameter MUST be 1603 included. Possible values of this parameter are specified in the 1604 IANA "CoJP Unsupported Configuration Code Registry" 1605 (Section 11.3). 1607 o parameter_label: Indicates the parameter. This parameter MUST be 1608 included. Possible values of this parameter are specified in the 1609 label column of the IANA "CoJP Parameters" registry 1610 (Section 11.1). 1612 o parameter_addinfo: Additional information about the parameter that 1613 cannot be acted upon. This parameter MUST be included. In case 1614 the code is set to "Unsupported", parameter_addinfo gives 1615 additional information to the JRC. If the parameter indicated by 1616 parameter_label cannot be acted upon regardless of its value, 1617 parameter_addinfo MUST be set to null, signaling to the JRC that 1618 it SHOULD NOT attempt to configure the parameter again. If the 1619 pledge can act on the parameter, but cannot configure the setting 1620 indicated by the parameter value, the pledge can hint this to the 1621 JRC. In this case, parameter_addinfo MUST be set to the value of 1622 the parameter that cannot be acted upon following the normative 1623 parameter structure specified in this document. For example, it 1624 is possible to include only a subset of the link-layer key set 1625 object, signaling the keys that cannot be acted upon, or the 1626 entire key set that was received. In case the code is set to 1627 "Malformed", parameter_addinfo MUST be set to null, signaling to 1628 the JRC that it SHOULD NOT attempt to configure the parameter 1629 again. 1631 The CDDL fragment that represents the text above for 1632 Unsupported_Configuration and Unsupported_Parameter objects follows. 1634 Unsupported_Configuration = [ 1635 + parameter : Unsupported_Parameter 1636 ] 1638 Unsupported_Parameter = ( 1639 code : int, 1640 parameter_label : int, 1641 parameter_addinfo : nil / any 1642 ) 1644 +-------------+-------+--------------------------------+------------+ 1645 | Name | Value | Description | Reference | 1646 +-------------+-------+--------------------------------+------------+ 1647 | Unsupported | 0 | The indicated setting is not | [[this | 1648 | | | supported by the networking | document]] | 1649 | | | stack implementation. | | 1650 | | | | | 1651 | Malformed | 1 | The indicated parameter value | [[this | 1652 | | | is malformed. | document]] | 1653 +-------------+-------+--------------------------------+------------+ 1655 Table 4: Unsupported Configuration code values. 1657 8.5. Recommended Settings 1659 This section gives RECOMMENDED values of CoJP settings. 1661 +--------------------------+---------------+ 1662 | Name | Default Value | 1663 +--------------------------+---------------+ 1664 | COJP_MAX_JOIN_ATTEMPTS | 4 | 1665 | | | 1666 | COJP_REKEYING_GUARD_TIME | 12 seconds | 1667 +--------------------------+---------------+ 1669 Recommended CoJP settings. 1671 The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible 1672 retransmissions at the link layer due to imperfect wireless links. 1674 9. Security Considerations 1676 Since this document uses the pledge identifier to set the ID Context 1677 parameter of OSCORE, an important security requirement is that the 1678 pledge identifier is unique in the set of all pledge identifiers 1679 managed by a JRC. The uniqueness of the pledge identifier ensures 1680 unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also 1681 allows the JRC to retrieve the correct security context, upon the 1682 reception of a Join Request message. The management of pledge 1683 identifiers is simplified if the globally unique EUI-64 is used, but 1684 this comes with privacy risks, as discussed in Section 10. 1686 This document further mandates that the (6LBR) pledge and the JRC are 1687 provisioned with unique PSKs. The PSK is used to set the OSCORE 1688 Master Secret during security context derivation. This derivation 1689 process results in OSCORE keys that are important for mutual 1690 authentication of the (6LBR) pledge and the JRC. Should an attacker 1691 come to know the PSK, then a man-in-the-middle attack is possible. 1693 Many vendors are known to use unsafe practices when generating and 1694 provisioning PSKs. The use of a single PSK shared among a group of 1695 devices is a common pitfall that results in poor security. In this 1696 case, the compromise of a single device is likely to lead to a 1697 compromise of the entire batch, with the attacker having the ability 1698 to impersonate a legitimate device and join the network, generate 1699 bogus data and disturb the network operation. As a reminder, recall 1700 the well-known problem with Bluetooth headsets with a "0000" pin. 1701 Additionally, some vendors use methods such as scrambling or hashing 1702 of device serial numbers or their EUI-64 to generate "unique" PSKs. 1703 Without any secret information involved, the effort that the attacker 1704 needs to invest into breaking these unsafe derivation methods is 1705 quite low, resulting in the possible impersonation of any device from 1706 the batch, without even needing to compromise a single device. The 1707 use of cryptographically secure random number generators to generate 1708 the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms 1709 using deterministic methods. 1711 The JP forwards the unauthenticated join traffic into the network. A 1712 data cap on the JP prevents it from forwarding more traffic than the 1713 network can handle. The data cap can be configured by the JRC by 1714 including a join rate parameter in the Join Response and it is 1715 implemented through the CoAP's PROBING_RATE setting. The use of a 1716 data cap at a JP forces attackers to use more than one JP if they 1717 wish to overwhelm the network. Marking the join traffic packets with 1718 a non-zero DSCP allows the network to carry the traffic if it has 1719 capacity, but encourages the network to drop the extra traffic rather 1720 than add bandwidth due to that traffic. 1722 The shared nature of the "minimal" cell used for the join traffic 1723 makes the network prone to a DoS attack by congesting the JP with 1724 bogus traffic. Such an attacker is limited by its maximum transmit 1725 power. The redundancy in the number of deployed JPs alleviates the 1726 issue and also gives the pledge a possibility to use the best 1727 available link for joining. How a network node decides to become a 1728 JP is out of scope of this specification. 1730 At the beginning of the join process, the pledge has no means of 1731 verifying the content in the EB, and has to accept it at "face 1732 value". In case the pledge tries to join an attacker's network, the 1733 Join Response message will either fail the security check or time 1734 out. The pledge may implement a temporary blacklist in order to 1735 filter out undesired EBs and try to join using the next seemingly 1736 valid EB. This blacklist alleviates the issue, but is effectively 1737 limited by the node's available memory. Note that this temporary 1738 blacklist is different from the one communicated as part of the CoJP 1739 Configuration object as it helps pledge fight a DoS attack. These 1740 bogus beacons prolong the join time of the pledge, and so the time 1741 spent in "minimal" [RFC8180] duty cycle mode. The blacklist 1742 communicated as part of the CoJP Configuration object helps JP fight 1743 a DoS attack by a malicious pledge. 1745 10. Privacy Considerations 1747 The join solution specified in this document relies on the uniqueness 1748 of the pledge identifier in the set of all pledge identifiers managed 1749 by a JRC. This identifier is transferred in clear as an OSCORE kid 1750 context. The use of the globally unique EUI-64 as pledge identifier 1751 simplifies the management but comes with certain privacy risks. The 1752 implications are thoroughly discussed in [RFC7721] and comprise 1753 correlation of activities over time, location tracking, address 1754 scanning and device-specific vulnerability exploitation. Since the 1755 join process occurs rarely compared to the network lifetime, long- 1756 term threats that arise from using EUI-64 as the pledge identifier 1757 are minimal. In addition, the Join Response message contains a short 1758 address which is assigned by the JRC to the (6LBR) pledge. The 1759 assigned short address SHOULD be uncorrelated with the long-term 1760 pledge identifier. The short address is encrypted in the response. 1761 Once the join process completes, the new node uses the short 1762 addresses for all further layer 2 (and layer-3) operations. This 1763 reduces the aforementioned privacy risks as the short layer-2 address 1764 (visible even when the network is encrypted) is not traceable between 1765 locations and does not disclose the manufacturer, as is the case of 1766 EUI-64. However, an eavesdropper with access to the radio medium 1767 during the join process may be able to correlate the assigned short 1768 address with the extended address based on timing information with a 1769 non-negligible probability. This probability decreases with an 1770 increasing number of pledges joining concurrently. 1772 11. IANA Considerations 1774 Note to RFC Editor: Please replace all occurrences of "[[this 1775 document]]" with the RFC number of this specification. 1777 This document allocates a well-known name under the .arpa name space 1778 according to the rules given in [RFC3172]. The name "6tisch.arpa" is 1779 requested. No subdomains are expected. No A, AAAA or PTR record is 1780 requested. 1782 11.1. CoJP Parameters Registry 1784 This section defines a sub-registries within the "IPv6 over the TSCH 1785 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1786 "Constrained Join Protocol Parameters Registry". 1788 The columns of the registry are: 1790 Name: This is a descriptive name that enables an easier reference to 1791 the item. It is not used in the encoding. 1793 Label: The value to be used to identify this parameter. The label is 1794 an integer. 1796 CBOR type: This field contains the CBOR type for the field. 1798 Description: This field contains a brief description for the field. 1800 Reference: This field contains a pointer to the public specification 1801 for the field, if one exists. 1803 This registry is to be populated with the values in Table 2. 1805 The amending formula for this sub-registry is: Different ranges of 1806 values use different registration policies [RFC8126]. Integer values 1807 from -256 to 255 are designated as Standards Action. Integer values 1808 from -65536 to -257 and from 256 to 65535 are designated as 1809 Specification Required. Integer values greater than 65535 are 1810 designated as Expert Review. Integer values less than -65536 are 1811 marked as Private Use. 1813 11.2. CoJP Key Usage Registry 1815 This section defines a sub-registries within the "IPv6 over the TSCH 1816 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1817 "Constrained Join Protocol Key Usage Registry". 1819 The columns of this registry are: 1821 Name: This is a descriptive name that enables easier reference to the 1822 item. The name MUST be unique. It is not used in the encoding. 1824 Value: This is the value used to identify the key usage setting. 1825 These values MUST be unique. The value is an integer. 1827 Algorithm: This is a descriptive name of the link-layer algorithm in 1828 use and uniquely determines the key length. The name is not used in 1829 the encoding. 1831 Description: This field contains a description of the key usage 1832 setting. The field should describe in enough detail how the key is 1833 to be used with different frame types, specific for the link-layer 1834 technology in question. 1836 Reference: This contains a pointer to the public specification for 1837 the field, if one exists. 1839 This registry is to be populated with the values in Table 3. 1841 The amending formula for this sub-registry is: Different ranges of 1842 values use different registration policies [RFC8126]. Integer values 1843 from -256 to 255 are designated as Standards Action. Integer values 1844 from -65536 to -257 and from 256 to 65535 are designated as 1845 Specification Required. Integer values greater than 65535 are 1846 designated as Expert Review. Integer values less than -65536 are 1847 marked as Private Use. 1849 11.3. CoJP Unsupported Configuration Code Registry 1851 This section defines a sub-registries within the "IPv6 over the TSCH 1852 mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name 1853 "Constrained Join Protocol Unsupported Configuration Code Registry". 1855 The columns of this registry are: 1857 Name: This is a descriptive name that enables easier reference to the 1858 item. The name MUST be unique. It is not used in the encoding. 1860 Value: This is the value used to identify the diagnostic code. These 1861 values MUST be unique. The value is an integer. 1863 Description: This is a descriptive human-readable name. The 1864 description MUST be unique. It is not used in the encoding. 1866 Reference: This contains a pointer to the public specification for 1867 the field, if one exists. 1869 This registry is to be populated with the values in Table 4. 1871 The amending formula for this sub-registry is: Different ranges of 1872 values use different registration policies [RFC8126]. Integer values 1873 from -256 to 255 are designated as Standards Action. Integer values 1874 from -65536 to -257 and from 256 to 65535 are designated as 1875 Specification Required. Integer values greater than 65535 are 1876 designated as Expert Review. Integer values less than -65536 are 1877 marked as Private Use. 1879 12. Acknowledgments 1881 The work on this document has been partially supported by the 1882 European Union's H2020 Programme for research, technological 1883 development and demonstration under grant agreements: No 644852, 1884 project ARMOUR; No 687884, project F-Interop and open-call project 1885 SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA. 1887 The following individuals provided input to this document (in 1888 alphabetic order): Christian Amsuss, Tengfei Chang, Klaus Hartke, 1889 Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal 1890 Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne. 1892 13. References 1893 13.1. Normative References 1895 [I-D.ietf-core-object-security] 1896 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1897 "Object Security for Constrained RESTful Environments 1898 (OSCORE)", draft-ietf-core-object-security-16 (work in 1899 progress), March 2019. 1901 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1902 Requirement Levels", BCP 14, RFC 2119, 1903 DOI 10.17487/RFC2119, March 1997, 1904 . 1906 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1907 "Assured Forwarding PHB Group", RFC 2597, 1908 DOI 10.17487/RFC2597, June 1999, 1909 . 1911 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1912 Requirements for the Address and Routing Parameter Area 1913 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1914 September 2001, . 1916 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1917 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1918 October 2013, . 1920 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1921 Application Protocol (CoAP)", RFC 7252, 1922 DOI 10.17487/RFC7252, June 2014, 1923 . 1925 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1926 Writing an IANA Considerations Section in RFCs", BCP 26, 1927 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1928 . 1930 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1931 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1932 . 1934 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1935 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1936 May 2017, . 1938 13.2. Informative References 1940 [I-D.ietf-6tisch-architecture] 1941 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1942 of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work 1943 in progress), March 2019. 1945 [I-D.ietf-6tisch-terminology] 1946 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1947 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 1948 draft-ietf-6tisch-terminology-10 (work in progress), March 1949 2018. 1951 [I-D.ietf-cbor-cddl] 1952 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 1953 definition language (CDDL): a notational convention to 1954 express CBOR and JSON data structures", draft-ietf-cbor- 1955 cddl-08 (work in progress), March 2019. 1957 [I-D.ietf-core-stateless] 1958 Hartke, K., "Extended Tokens and Stateless Clients in the 1959 Constrained Application Protocol (CoAP)", draft-ietf-core- 1960 stateless-01 (work in progress), March 2019. 1962 [IEEE802.15.4] 1963 IEEE standard for Information Technology, ., "IEEE Std 1964 802.15.4 Standard for Low-Rate Wireless Networks", n.d.. 1966 [NIST800-90A] 1967 NIST Special Publication 800-90A, Revision 1, ., Barker, 1968 E., and J. Kelsey, "Recommendation for Random Number 1969 Generation Using Deterministic Random Bit Generators", 1970 2015. 1972 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1973 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1974 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1975 . 1977 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1978 "Transmission of IPv6 Packets over IEEE 802.15.4 1979 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1980 . 1982 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1983 Key Derivation Function (HKDF)", RFC 5869, 1984 DOI 10.17487/RFC5869, May 2010, 1985 . 1987 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1988 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1989 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1990 Low-Power and Lossy Networks", RFC 6550, 1991 DOI 10.17487/RFC6550, March 2012, 1992 . 1994 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1995 Bormann, "Neighbor Discovery Optimization for IPv6 over 1996 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1997 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1998 . 2000 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 2001 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 2002 Internet of Things (IoT): Problem Statement", RFC 7554, 2003 DOI 10.17487/RFC7554, May 2015, 2004 . 2006 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2007 Considerations for IPv6 Address Generation Mechanisms", 2008 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2009 . 2011 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2012 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2013 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2014 May 2017, . 2016 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 2017 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 2018 DOI 10.17487/RFC8480, November 2018, 2019 . 2021 Appendix A. Example 2023 Figure 3 illustrates a successful join protocol exchange. The pledge 2024 instantiates the OSCORE context and derives the OSCORE keys and 2025 nonces from the PSK. It uses the instantiated context to protect the 2026 Join Request addressed with a Proxy-Scheme option, the well-known 2027 host name of the JRC in the Uri-Host option, and its EUI-64 as pledge 2028 identifier and OSCORE kid context. Triggered by the presence of a 2029 Proxy-Scheme option, the JP forwards the request to the JRC and sets 2030 the CoAP token to the internally needed state. The JP has learned 2031 the IPv6 address of the JRC when it acted as a pledge and joined the 2032 network. Once the JRC receives the request, it looks up the correct 2033 context based on the kid context parameter. The OSCORE data 2034 authenticity verification ensures that the request has not been 2035 modified in transit. In addition, replay protection is ensured 2036 through persistent handling of mutable context parameters. 2038 Once the JP receives the Join Response, it authenticates the state 2039 within the CoAP token before deciding where to forward. The JP sets 2040 its internal state to that found in the token, and forwards the Join 2041 Response to the correct pledge. Note that the JP does not possess 2042 the key to decrypt the CBOR object (configuration) present in the 2043 payload. The Join Response is matched to the Join Request and 2044 verified for replay protection at the pledge using OSCORE processing 2045 rules. In this example, the Join Response does not contain the IPv6 2046 address of the JRC, the pledge hence understands the JRC is co- 2047 located with the 6LBR. 2049 <---E2E OSCORE--> 2050 Client Proxy Server 2051 Pledge JP JRC 2052 | | | 2053 | Join | | Code: 0.02 (POST) 2054 | Request | | Token: - 2055 +--------->| | Proxy-Scheme: coap 2056 | | | Uri-Host: 6tisch.arpa 2057 | | | OSCORE: kid: -, 2058 | | | kid_context: EUI-64, 2059 | | | Partial IV: 1 2060 | | | Payload: { Code: 0.02 (POST), 2061 | | | Uri-Path: "j", 2062 | | | join_request, } 2063 | | | 2064 | | Join | Code: 0.02 (POST) 2065 | | Request | Token: opaque state 2066 | +--------->| OSCORE: kid: -, 2067 | | | kid_context: EUI-64, 2068 | | | Partial IV: 1 2069 | | | Payload: { Code: 0.02 (POST), 2070 | | | Uri-Path: "j", 2071 | | | join_request, } 2072 | | | 2073 | | | 2074 | | Join | Code: 2.04 (Changed) 2075 | | Response | Token: opaque state 2076 | |<---------+ OSCORE: - 2077 | | | Payload: { Code: 2.04 (Changed), 2078 | | | configuration, } 2079 | | | 2080 | | | 2081 | Join | | Code: 2.04 (Changed) 2082 | Response | | Token: - 2083 |<---------+ | OSCORE: - 2084 | | | Payload: { Code: 2.04 (Changed), 2085 | | | configuration, } 2086 | | | 2088 Figure 3: Example of a successful join protocol exchange. { ... } 2089 denotes authenticated encryption, denotes the authentication 2090 tag. 2092 Where the join_request object is: 2094 join_request: 2095 { 2096 5 : h'cafe' / PAN ID of the network pledge is attempting to join / 2097 } 2099 Since the role parameter is not present, the default role of "6TiSCH 2100 Node" is implied. 2102 The join_request object encodes to h'a10542cafe' with a size of 5 2103 bytes. 2105 And the configuration object is: 2107 configuration: 2108 { 2109 2 : [ / link-layer key set / 2110 1, / key_id / 2111 h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / 2112 ], 2113 3 : [ / short identifier / 2114 h'af93' / assigned short address / 2115 ] 2116 } 2118 Since the key_usage parameter is not present in the link-layer key 2119 set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. 2120 Since key_addinfo parameter is not present and key_id is different 2121 than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since 2122 the lease_time parameter is not present in the short identifier 2123 object, the default value of positive infinity is implied. 2125 The configuration object encodes to 2127 h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size 2128 of 26 bytes. 2130 Appendix B. Lightweight Implementation Option 2132 In environments where optimizing the implementation footprint is 2133 important, it is possible to implement this specification without 2134 having the implementations of HKDF [RFC5869] and SHA [RFC4231] on 2135 constrained devices. HKDF and SHA are used during the OSCORE 2136 security context derivation phase. This derivation can also be done 2137 by the JRC or a provisioning device, on behalf of the (6LBR) pledge 2138 during the provisioning phase. In that case, the derived OSCORE 2139 security context parameters are written directly into the (6LBR) 2140 pledge, without requiring the PSK be provisioned to the (6LBR) 2141 pledge. 2143 The use of HKDF to derive OSCORE security context parameters ensures 2144 that the resulting OSCORE keys have good security properties, and are 2145 unique as long as the input for different pledges varies. This 2146 specification ensures the uniqueness by mandating unique pledge 2147 identifiers and a unique PSK for each (6LBR) pledge. From the AEAD 2148 nonce reuse viewpoint, having a unique pledge identifier is a 2149 sufficient condition. However, as discussed in Section 9, the use of 2150 a single PSK shared among many devices is a common security pitfall. 2151 The compromise of this shared PSK on a single device would lead to 2152 the compromise of the entire batch. When using the implementation/ 2153 deployment scheme outlined above, the PSK does not need to be written 2154 to individual pledges. As a consequence, even if a shared PSK is 2155 used, the scheme offers the same level of security as in the scenario 2156 where each pledge is provisioned with a unique PSK. 2158 Authors' Addresses 2160 Malisa Vucinic (editor) 2161 Inria 2162 2 Rue Simone Iff 2163 Paris 75012 2164 France 2166 Email: malisa.vucinic@inria.fr 2168 Jonathan Simon 2169 Analog Devices 2170 32990 Alvarado-Niles Road, Suite 910 2171 Union City, CA 94587 2172 USA 2174 Email: jonathan.simon@analog.com 2176 Kris Pister 2177 University of California Berkeley 2178 512 Cory Hall 2179 Berkeley, CA 94720 2180 USA 2182 Email: pister@eecs.berkeley.edu 2183 Michael Richardson 2184 Sandelman Software Works 2185 470 Dawson Avenue 2186 Ottawa, ON K1Z5V7 2187 Canada 2189 Email: mcr+ietf@sandelman.ca