idnits 2.17.1 draft-ietf-6tisch-minimal-security-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 05, 2018) is 2243 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) == Unused Reference: 'I-D.richardson-6tisch-minimal-rekey' is defined on line 1059, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-08 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-09 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-09 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-02 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Working Group M. Vucinic, Ed. 3 Internet-Draft University of Montenegro 4 Intended status: Standards Track J. Simon 5 Expires: September 6, 2018 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 March 05, 2018 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-05 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 a short link-layer address. This 27 specification defines the message format, a new Stateless-Proxy CoAP 28 option, and configures the rest of the 6TiSCH communication stack for 29 this join process to occur in a secure manner. Additional security 30 mechanisms may be added on top of this minimal framework. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 6, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 5 70 5. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 7 72 5.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 7 73 5.3. Step 3 - Join Request . . . . . . . . . . . . . . . . . . 8 74 5.4. Step 4 - Join Response . . . . . . . . . . . . . . . . . 8 75 6. Link-layer Configuration . . . . . . . . . . . . . . . . . . 9 76 7. Network-layer Configuration . . . . . . . . . . . . . . . . . 9 77 7.1. Identification of Join Request Traffic . . . . . . . . . 10 78 7.2. Identification of Join Response Traffic . . . . . . . . . 11 79 8. Application-level Configuration . . . . . . . . . . . . . . . 11 80 8.1. OSCORE Security Context . . . . . . . . . . . . . . . . . 12 81 9. 6TiSCH Join Protocol . . . . . . . . . . . . . . . . . . . . 13 82 9.1. Specification of the Join Request . . . . . . . . . . . . 14 83 9.2. Specification of the Join Response . . . . . . . . . . . 15 84 9.3. Error Handling and Retransmission . . . . . . . . . . . . 17 85 9.4. Rekeying and Rejoining . . . . . . . . . . . . . . . . . 18 86 9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 18 87 9.6. Mandatory to Implement Algorithms . . . . . . . . . . . . 18 88 10. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . . . 19 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 91 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 13.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 21 93 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 94 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 15.1. Normative References . . . . . . . . . . . . . . . . . . 22 96 15.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 This document presumes a 6TiSCH network as described by [RFC7554] and 104 [RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their 105 radio turned off most of the time, to conserve energy. As a 106 consequence, the link used by a new device for joining the network 107 has limited bandwidth [RFC8180]. The secure join solution defined in 108 this document therefore keeps the number of over-the-air exchanges 109 for join purposes to a minimum. 111 The micro-controllers at the heart of 6TiSCH nodes have a small 112 amount of code memory. It is therefore paramount to reuse existing 113 protocols available as part of the 6TiSCH stack. At the application 114 layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web 115 transfer, and on OSCORE [I-D.ietf-core-object-security] for its end- 116 to-end security. The secure join solution defined in this document 117 therefore reuses those two protocols as its building blocks. 119 This document defines a secure join solution for a new device, called 120 "pledge", to securely join a 6TiSCH network. The specification 121 defines a 6TiSCH Join Protocol (6JP) used by the pledge to request 122 admission into a network managed by the JRC, and for the JRC to 123 configure the pledge with the necessary parameters, a new CoAP 124 option, and configures different layers of the 6TiSCH protocol stack 125 for the join process to occur in a secure manner. 127 It assumes the presence of a JRC (join registrar/coordinator), a 128 central entity. It further assumes that the pledge and the JRC share 129 a symmetric key, called PSK (pre-shared key). The PSK is used to 130 configure OSCORE to provide a secure channel to 6JP. How the PSK is 131 installed is out of scope of this document. 133 When the pledge seeks admission to a 6TiSCH network, it first 134 synchronizes to it, by initiating the passive scan defined in 135 [IEEE802.15.4-2015]. The pledge then exchanges messages with the 136 JRC; these messages can be forwarded by nodes already part of the 137 6TiSCH network. The messages exchanged allow the JRC and the pledge 138 to mutually authenticate, based on the PSK. They also allow the JRC 139 to configure the pledge with link-layer keying material and a short 140 link-layer address. After this secure join process successfully 141 completes, the joined node can interact with its neighbors to request 142 additional bandwidth using the 6top Protocol 143 [I-D.ietf-6tisch-6top-protocol] and start sending the application 144 traffic. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. These 151 words may also appear in this document in lowercase, absent their 152 normative meanings. 154 The reader is expected to be familiar with the terms and concepts 155 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 156 [I-D.ietf-core-object-security], and [RFC8152]. 158 The specification also includes a set of informative examples using 159 the CBOR diagnostic notation [I-D.ietf-cbor-cddl]. 161 The following terms defined in [I-D.ietf-6tisch-terminology] are used 162 extensively throughout this document: 164 o pledge 166 o joined node 168 o join proxy (JP) 170 o join registrar/coordinator (JRC) 172 o enhanced beacon (EB) 174 o join protocol 176 o join process 178 In addition, we use the generic terms "network identifier" and 179 "pledge identifier". See Section 3. 181 3. Identifiers 183 The "network identifier" uniquely identifies the 6TiSCH network in 184 the namespace managed by a JRC. Typically, this is the 16-bit 185 Personal Area Network Identifier (PAN ID) defined in 186 [IEEE802.15.4-2015]. Companion documents can specify the use of a 187 different network identifier for join purposes, but this is out of 188 scope of this specification. Such identifier needs to be carried 189 within Enhanced Beacon (EB) frames. 191 The "pledge identifier" uniquely identifies the pledge in the 192 namespace managed by a JRC. The pledge identifier is typically the 193 globally unique 64-bit Extended Unique Identifier (EUI-64) of the 194 IEEE 802.15.4 device. This identifier is used to generate the IPv6 195 addresses of the pledge and to identify it during the execution of 196 the join protocol. For privacy reasons, it is possible to use an 197 identifier different from the EUI-64 (e.g. a random string). See 198 Section 12. 200 4. One-Touch Assumption 202 This document assumes a one-touch scenario. The pledge is 203 provisioned with certain parameters before attempting to join the 204 network, and the same parameters are provisioned to the JRC. 206 There are many ways by which this provisioning can be done. 207 Physically, the parameters can be written into the pledge using a 208 number of mechanisms, such as a JTAG interface, a serial (craft) 209 console interface, pushing buttons simultaneously on different 210 devices, over-the-air configuration in a Faraday cage, etc. The 211 provisioning can be done by the vendor, the manufacturer, the 212 integrator, etc. 214 Details of how this provisioning is done is out of scope of this 215 document. What is assumed is that there can be a secure, private 216 conversation between the JRC and the pledge, and that the two devices 217 can exchange the parameters. 219 Parameters that are provisioned to the pledge include: 221 o Pre-Shared Key (PSK). The JRC additionally needs to store the 222 identifier of the pledge bound to the given PSK. The PSK SHOULD 223 be at least 128 bits in length, generated uniformly at random. It 224 is RECOMMENDED to generate the PSK with a cryptographically secure 225 pseudorandom number generator. Each pledge SHOULD be provisioned 226 with a unique PSK. 228 o Optionally, a network identifier. Provisioning the network 229 identifier to the pledge is RECOMMENDED, as it significantly 230 speeds up the join process. In case this parameter is not 231 provisioned, the pledge attempts to join one network at a time. 233 o Optionally, any non-default algorithms. Mandatory to implement 234 and default algorithms are specified in Section 9.6. 236 5. Join Overview 238 This section describes the steps taken by a pledge in a 6TiSCH 239 network. When a pledge seeks admission to a 6TiSCH network, the 240 following exchange occurs: 242 1. The pledge listens for an Enhanced Beacon (EB) frame 243 [IEEE802.15.4-2015]. This frame provides network synchronization 244 information, and tells the device when it can send a frame to the 245 node sending the beacons, which plays the role of join proxy (JP) 246 for the pledge, and when it can expect to receive a frame. 248 2. The pledge configures its link-local IPv6 address and advertises 249 it to the join proxy (JP). 251 3. The pledge sends a Join Request to the JP in order to securely 252 identify itself to the network. The Join Request is directed to 253 the JRC, which may be co-located on the JP or another device. 255 4. In case of successful processing of the request, the pledge 256 receives a join response from JRC (via the JP) that sets up one 257 or more link-layer keys used to authenticate and encrypt 258 subsequent transmissions to peers, and a short link-layer address 259 for the pledge. 261 From the pledge's perspective, joining is a local phenomenon - the 262 pledge only interacts with the JP, and it needs not know how far it 263 is from the 6LBR, or how to route to the JRC. Only after 264 establishing one or more link-layer keys does it need to know about 265 the particulars of a 6TiSCH network. 267 The join process is shown as a transaction diagram in Figure 1: 269 +--------+ +-------+ +--------+ 270 | pledge | | JP | | JRC | 271 | | | | | | 272 +--------+ +-------+ +--------+ 273 | | | 274 |<---Enhanced Beacon (1)---| | 275 | | | 276 |<-Neighbor Discovery (2)->| | 277 | | | 278 |-----Join Request (3)-----|------Join Request (3a)-->| \ 279 | | | | 6JP 280 |<---Join Response (4)-----|-----Join Response (4a)---| / 281 | | | 283 Figure 1: Overview of a successful join process. 6JP stands for 284 6TiSCH Join Protocol. 286 The details of each step are described in the following sections. 288 5.1. Step 1 - Enhanced Beacon 290 The pledge synchronizes to the network by listening for, and 291 receiving, an Enhanced Beacon (EB) sent by a node already in the 292 network. This process is entirely defined by [IEEE802.15.4-2015], 293 and described in [RFC7554]. 295 Once the pledge hears an EB, it synchronizes to the joining schedule 296 using the cells contained in the EB. The pledge can hear multiple 297 EBs; the selection of which EB to use is out of the scope for this 298 document, and is discussed in [RFC7554]. Implementers should make 299 use of information such as: what network identifier the EB contains, 300 whether the source link-layer address of the EB has been tried 301 before, what signal strength the different EBs were received at, etc. 302 In addition, the pledge may be pre-configured to search for EBs with 303 a specific network identifier. 305 If the pledge is not provisioned with the network identifier, it 306 attempts to join one network at a time, as described in Section 9.3. 308 Once the pledge selects the EB, it synchronizes to it and transitions 309 into a low-power mode. It deeply duty cycles its radio, switching 310 the radio on when the provided schedule indicates slots which the 311 pledge may use for the join process. During the remainder of the 312 join process, the node that has sent the EB to the pledge plays the 313 role of JP. 315 At this point, the pledge may proceed to step 2, or continue to 316 listen for additional EBs. 318 5.2. Step 2 - Neighbor Discovery 320 The pledge forms its link-local IPv6 address based on the interface 321 identifier, as per [RFC4944]. The pledge MAY perform the Neighbor 322 Solicitation / Neighbor Advertisement exchange with the JP, as per 323 Section 5.5.1 of [RFC6775]. The pledge and the JP use their link- 324 local IPv6 addresses for all subsequent communication during the join 325 process. 327 Note that Neighbor Discovery exchanges at this point are not 328 protected with link-layer security as the pledge is not in possession 329 of the keys. How JP accepts these unprotected frames is discussed in 330 Section 6. 332 5.3. Step 3 - Join Request 334 The Join Request is a message sent from the pledge to the JP, and 335 which the JP forwards to the JRC. The JP forwards the Join Request 336 to the JRC on the existing 6TiSCH network. How exactly this happens 337 is out of scope of this document; some networks may wish to dedicate 338 specific slots for this join traffic. 340 The Join Request is authenticated/encrypted end-to-end using an AEAD 341 (Authenticated Encryption with Associated Data) algorithm from 342 [RFC8152] and a key derived from the PSK, the pledge identifier and a 343 request-specific constant value. Algorithms which MUST be 344 implemented are specified in Section 9.6. 346 The nonce used when securing the Join Request is derived from the 347 PSK, the pledge identifier and a monotonically increasing counter 348 initialized to 0 when first starting. 350 Join Request message is specified in Section 9.1, while the details 351 on security processing can be found in Section 7 of 352 [I-D.ietf-core-object-security]. 354 5.4. Step 4 - Join Response 356 The Join Response is sent by the JRC to the pledge, and is forwarded 357 through the JP as it serves as a stateless relay. The packet 358 containing the Join Response travels from the JRC to JP using the 359 operating routes in the 6TiSCH network. The JP delivers it to the 360 pledge. The JP operates as the application-layer proxy, and does not 361 keep any state to relay the message. It uses information sent in the 362 clear within the Join Response to decide where to forward to. 364 The Join Response is authenticated/encrypted end-to-end using an AEAD 365 algorithm from [RFC8152]. The key used to protect the response is 366 different from the one used to protect the request (both are derived 367 from the PSK, as explained in Section 8.1). The response is 368 protected using the same nonce as in the request. 370 The Join Response contains one or more link-layer key(s) that the 371 pledge will use for subsequent communication. Each key that is 372 provided by the JRC is associated with an 802.15.4 key identifier. 373 In other link-layer technologies, a different identifier may be 374 substituted. The Join Response also contains an IEEE 802.15.4 short 375 address [IEEE802.15.4-2015] assigned by the JRC to the pledge, and 376 optionally the IPv6 address of the JRC. 378 Join Response message is specified in Section 9.2, while the details 379 on security processing can be found in Section 7 of 380 [I-D.ietf-core-object-security]. 382 6. Link-layer Configuration 384 In an operational 6TiSCH network, all frames MUST use link-layer 385 frame security [RFC8180]. The IEEE 802.15.4 security attributes MUST 386 include frame authenticity, and MAY include frame confidentiality 387 (i.e. encryption). 389 As specified in [RFC8180], the network uses a key termed as K1 to 390 authenticate EBs and a key termed as K2 to authenticate and 391 optionally encrypt DATA and ACKNOWLEDGMENT frames. The keys K1 and 392 K2 MAY be the same key (same value and IEEE 802.15.4 index). How the 393 JRC communicates these keys to 6LBR is out of scope of this 394 specification. 396 The pledge does not initially do any authenticity check of the EB 397 frames, as it does not know the K1 key. The pledge is still able to 398 parse the contents of the received EBs and synchronize to the 399 network, as EBs are not encrypted [RFC8180]. 401 When sending frames during the join process, the pledge sends 402 unencrypted and unauthenticated frames. The JP accepts these frames 403 (using the "exempt mode" in 802.15.4) for the duration of the join 404 process. How the JP learns whether the join process is ongoing is 405 out of scope of this specification. 407 As the EB itself cannot be authenticated by the pledge, an attacker 408 may craft a frame that appears to be a valid EB, since the pledge can 409 neither know the ASN a priori nor verify the address of the JP. This 410 opens up a possibility of DoS attack, as discussed in Section 11. 411 Beacon authentication keys are discussed in [RFC8180]. 413 7. Network-layer Configuration 415 The pledge and the JP SHOULD keep a separate neighbor cache for 416 untrusted entries and use it to store each other's information during 417 the join process. Mixing neighbor entries belonging to pledges and 418 nodes that are part of the network opens up the JP to a DoS attack. 419 How the pledge and the JP decide to transition each other from 420 untrusted to trusted cache, once the join process completes, is out 421 of scope. One implementation technique is to use the information 422 whether the incoming frames are secured at the link layer. 424 The pledge does not communicate with the JRC at the network layer. 425 This allows the pledge to join without knowing the IPv6 address of 426 the JRC. Instead, the pledge communicates with the JP at the network 427 layer, and with the JRC at the application layer, as specified in 428 Section 8. 430 The JP communicates with the JRC over global IPv6 addresses. The JP 431 discovers the network prefix and configures its global IPv6 address 432 upon successful completion of the join process and the obtention of 433 link-layer keys. The pledge learns the actual IPv6 address of the 434 JRC from the Join Response, as specified in Section 9.2; it uses it 435 once joined in order to operate as a JP. 437 The JRC can be co-located on the 6LBR. In this special case, the 438 IPv6 address of the JRC can be omitted from the Join Response message 439 for space optimization. The 6LBR then MUST set the DODAGID field in 440 RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the 441 address of the JRC once joined and upon the reception of a first RPL 442 DIO message, and uses it to operate as a JP. 444 Before the 6TiSCH network is started, the 6LBR MUST be provisioned 445 with the IPv6 address of the JRC. 447 7.1. Identification of Join Request Traffic 449 The join request traffic that is proxied by the Join Proxy comes from 450 unauthenticated nodes, and there may be an arbitrary amount of it. 451 In particular, an attacker may send fraudulent traffic in attempt to 452 overwhelm the network. 454 When operating as part of a [RFC8180] 6TiSCH minimal network using 455 reasonable scheduling algorithms, the join request traffic present 456 may cause intermediate nodes to request additional bandwidth. An 457 attacker could use this property to cause the network to overcommit 458 bandwidth (and energy) to the join process. 460 The Join Proxy is aware of what traffic is join request traffic, and 461 so can avoid allocating additional bandwidth itself. The Join Proxy 462 SHOULD implement a bandwidth cap on outgoing join request traffic. 463 This cap will not protect intermediate nodes as they can not tell 464 join request traffic from regular traffic. Despite the bandwidth cap 465 implemented separately on each Join Proxy, the aggregate join request 466 traffic from many Join Proxies may cause intermediate nodes to decide 467 to allocate additional cells. It is undesirable to to so in response 468 to the join request traffic. In order to permit the intermediate 469 nodes to avoid this, the traffic needs to be tagged in some way. 471 [RFC2597] defines a set of per-hop behaviors that may be encoded into 472 the Diffserv Code Points (DSCPs). The Join Proxy SHOULD set the DSCP 473 of join request packets that it produces as part of the relay process 474 to AF43 code point (See Section 6 of [RFC2597]). 476 A Join Proxy that does not set the DSCP on traffic forwarded should 477 set it to zero so that it is compressed out. 479 A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT 480 allocate additional cells as a result of traffic with code point 481 AF43. Companion SF documents SHOULD specify how this recommended 482 behavior is achieved. 484 7.2. Identification of Join Response Traffic 486 The JRC SHOULD set the DSCP of join response packets addressed to the 487 Join Proxy to AF42 code point. Join response traffic can not be 488 induced by an attacker as it is generated only in response to 489 legitimate pledges (see Section 9.3). AF42 has lower drop 490 probability than AF43, giving join response traffic priority in 491 buffers over join request traffic. 493 When the JRC is not co-located with the 6LBR, then the code point 494 provides a clear indication to the 6LBR that this is join response 495 traffic. 497 Due to the convergecast nature of the DODAG, the 6LBR links are often 498 the most congested, and from that point down there is progressively 499 less (or equal) congestion. If the 6LBR paces itself when sending 500 join response traffic then it ought to never exceed the bandwidth 501 allocated to the best effort traffic cells. If the 6LBR has the 502 capacity (if it is not constrained) then it should provide some 503 buffers in order to satisfy the Assured Forwarding behavior. 505 Companion SF documents SHOULD specify how traffic with code point 506 AF42 is handled with respect to cell allocation. 508 8. Application-level Configuration 510 The Join Request/Join Response exchange in Figure 1 is carried over 511 CoAP [RFC7252] and secured using OSCORE 512 [I-D.ietf-core-object-security]. The pledge plays the role of a CoAP 513 client; the JRC plays the role of a CoAP server. The JP implements 514 CoAP forward proxy functionality [RFC7252]. Because the JP can also 515 be a constrained device, it cannot implement a cache. Rather, the JP 516 processes forwarding-related CoAP options and makes requests on 517 behalf of the pledge, in a stateless manner by using the Stateless- 518 Proxy option defined in this document. 520 The pledge designates a JP as a proxy by including the Proxy-Scheme 521 option in CoAP requests it sends to the JP. The pledge also includes 522 in the requests the Uri-Host option with its value set to the well- 523 known JRC's alias, as specified in Section 9.1. 525 The JP resolves the alias to the IPv6 address of the JRC that it 526 learned when it acted as a pledge, and joined the network. This 527 allows the JP to reach the JRC at the network layer and forward the 528 requests on behalf of the pledge. 530 The JP MUST add a Stateless-Proxy option to all the requests that it 531 forwards on behalf of the pledge as part of the join process. 533 The value of the Stateless-Proxy option is set to the internal JP 534 state, needed to forward the Join Response message to the pledge. 535 The Stateless-Proxy option handling is defined in Section 10. 537 The JP also tags all packets carrying the Join Request message at the 538 network layer, as specified in Section 7.1. 540 8.1. OSCORE Security Context 542 Before the pledge and the JRC may start exchanging CoAP messages 543 protected with OSCORE, they need to derive the OSCORE security 544 context from the parameters provisioned out-of-band, as discussed in 545 Section 4. 547 The OSCORE security context MUST be derived at the pledge and the JRC 548 as per Section 3 of [I-D.ietf-core-object-security]. 550 o the Master Secret MUST be the PSK. 552 o the Master Salt MUST be the pledge identifier. 554 o the Sender ID of the pledge MUST be set to byte string 0x00. 556 o the Recipient ID (ID of the JRC) MUST be set to byte string 0x01. 558 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 559 of-band by the same mechanism used to provision the PSK. The 560 default is AES-CCM-16-64-128. 562 o the Key Derivation Function MUST be agreed out-of-band. Default 563 is HKDF SHA-256 [RFC5869]. 565 The derivation in [I-D.ietf-core-object-security] results in traffic 566 keys and a common IV for each side of the conversation. Nonces are 567 constructed by XOR'ing the common IV with the current sequence number 568 and sender identifier. For details on nonce construction, refer to 569 [I-D.ietf-core-object-security]. 571 Implementations MUST ensure that multiple CoAP requests to different 572 JRCs result in the use of the same OSCORE context, so that the 573 sequence numbers are properly incremented for each request. The 574 pledge typically sends requests to different JRCs if it is not 575 provisioned with the network identifier and attempts to join one 576 network at a time. A simple implementation technique is to 577 instantiate the OSCORE security context with a given PSK only once 578 and use it for all subsequent requests. Failure to comply will break 579 the confidentiality property of the AEAD algorithm due to the nonce 580 reuse. 582 8.1.1. Persistency 584 Implementations MUST ensure that mutable OSCORE context parameters 585 (Sender Sequence Number, Replay Window) are stored in persistent 586 memory. A technique that prevents reuse of sequence numbers, 587 detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be 588 implemented. Each update of the OSCORE Replay Window MUST be written 589 to persistent memory. 591 This is an important security requirement in order to guarantee nonce 592 uniqueness and resistance to replay attacks across reboots and 593 rejoins. Traffic between the pledge and the JRC is rare, making 594 security outweigh the cost of writing to persistent memory. 596 9. 6TiSCH Join Protocol 598 6TiSCH Join Protocol (6JP) is a lightweight protocol over CoAP 599 [RFC7252] and a secure channel provided by OSCORE 600 [I-D.ietf-core-object-security]. 6JP allows the pledge to request 601 admission into a network managed by the JRC, and for the JRC to 602 configure the pledge with the parameters necessary for joining the 603 network. These parameters are: link-layer keys in use, IEEE 802.15.4 604 short address assigned to the pledge, and the IPv6 address of the 605 JRC. 607 This section specifies the 6JP bindings to CoAP and OSCORE, 6JP 608 message formats and the semantics of different fields. 610 6JP relies on the security properties provided by OSCORE. This 611 includes end-to-end confidentiality, data authenticity, replay 612 protection, and a secure binding of responses to requests. 614 +-----------------------------------+ 615 | 6TiSCH Join Protocol (6JP) | 616 +-----------------------------------+ 617 +-----------------------------------+ \ 618 | Requests / Responses | | 619 |-----------------------------------| | 620 | OSCORE | | CoAP 621 |-----------------------------------| | 622 | Messaging Layer / Message Framing | | 623 +-----------------------------------+ / 624 +-----------------------------------+ 625 | UDP | 626 +-----------------------------------+ 628 Figure 2: Abstract layering of 6JP. 630 6JP consists of two messages: 632 o the Join Request message, sent by the pledge to the JRC, proxied 633 by the JP. The Join Request message and its mapping to CoAP is 634 specified in Section 9.1. 636 o the Join Response message, sent by the JRC to the pledge if the 637 JRC successfully processes the Join Request using OSCORE and it 638 determines through a mechanism that is out of scope of this 639 specification that the pledge is authorized to join the network. 640 The Join Response message is proxied by the JP. The Join Response 641 message and its mapping to CoAP is specified in Section 9.2. 643 The payload of 6JP messages is encoded with CBOR [RFC7049], with some 644 parameters being optional. The first byte of the CBOR-encoded byte 645 string contains the CBOR major type and additional information (e.g. 646 the number of elements in an array). In case of an array, the CBOR 647 decoder decides based on this additional information if a certain 648 optional parameter is present or not. 650 9.1. Specification of the Join Request 652 The Join Request the pledge sends SHALL be mapped to a CoAP request: 654 o The request method is POST. 656 o The type is Non-confirmable (NON). 658 o The Proxy-Scheme option is set to "coap". 660 o The Uri-Host option is set to "6tisch.arpa". 662 o The Uri-Path option is set to "j". 664 o The Object-Security option SHALL be set according to 665 [I-D.ietf-core-object-security]. The OSCORE security context used 666 is the one derived in Section 8.1. The OSCORE Context Hint SHALL 667 be set to the pledge identifier. The OSCORE Context Hint allows 668 the JRC to retrieve the security context for a given pledge. 670 o The payload is a CBOR array [RFC7049] containing, in order: 672 * Byte string, containing the identifier of the network that the 673 pledge is attempting to join. This enables the JRC to manage 674 multiple 6TiSCH networks. 676 request_payload = [ 677 network_identifier : bstr, 678 ] 680 9.2. Specification of the Join Response 682 The Join Response the JRC sends SHALL be mapped to a CoAP response: 684 o The response Code is 2.04 (Changed). 686 o The payload is a CBOR array [RFC7049] containing, in order: 688 * the COSE Key Set, specified in [RFC8152], containing one or 689 more link-layer keys. The mapping of individual keys to 690 802.15.4-specific parameters is described in Section 9.2.1. 692 * the link-layer short address to be used by the pledge. The 693 format of the short address follows Section 9.2.2. 695 * optionally, the IPv6 address of the JRC, encoded as a byte 696 string, with the length of 16 bytes. If the IPv6 address of 697 the JRC is not present in the Join Response, this indicates the 698 JRC is co-located with the 6LBR, and has the same IPv6 address 699 as the 6LBR. See Section 7. 701 response_payload = [ 702 COSE_KeySet, 703 short_address, 704 ? JRC_address : bstr, 705 ] 707 9.2.1. Link-layer Keys Transported in the COSE Key Set 709 Each key in the COSE Key Set [RFC8152] SHALL be a symmetric key. The 710 first key in the COSE Key Set SHALL be used as the K1 key from 711 [RFC8180]. The second key in the COSE Key Set SHALL be used as the 712 K2 key from [RFC8180]. In the case where the network uses the same 713 key for K1 and K2, the COSE Key Set SHALL carry a single key. 715 If the COSE Key Set carries more than 2 keys, the implementation 716 SHOULD consider the response as malformed. 718 If the "kid" parameter of the COSE Key structure is present, the 719 corresponding key SHALL be used as IEEE 802.15.4 KeyIdMode 0x01 720 (index). In that case, parameter "kid" of the COSE Key structure 721 SHALL be used to carry the IEEE 802.15.4 KeyIndex value. 723 If the length of the "kid" parameter is more than 1 byte (length 724 defined by [IEEE802.15.4-2015]), the implementation SHOULD consider 725 the response as malformed. 727 If the "kid" parameter is not present in the transported key, the 728 implementation SHALL consider the key to be an IEEE 802.15.4 729 KeyIdMode 0x00 (implicit) key. 731 This document does not support IEEE 802.15.4 KeyIdMode 0x02 and 0x03 732 class keys. In the case that the response is considered malformed, 733 the implementation SHOULD indicate to the user through an out-of-band 734 mechanism the presence of an error condition. 736 9.2.2. Short Address 738 The "short_address" structure transported as part of the join 739 response payload represents the IEEE 802.15.4 short address assigned 740 to the pledge. It is encoded as a CBOR array object, containing, in 741 order: 743 o Byte string, containing the 16-bit address. 745 o Optionally, the lease time parameter, "lease_asn". The value of 746 the "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN) 747 corresponding to its expiration, carried as a byte string in 748 network byte order. 750 short_address = [ 751 address : bstr, 752 ? lease_asn : bstr, 753 ] 754 It is up to the joined node to request a new short address before the 755 expiry of its previous address. The mechanism by which the node 756 requests renewal is the same as during join procedure, as described 757 in Section 9.4. 759 9.3. Error Handling and Retransmission 761 Since the Join Request is mapped to a Non-confirmable CoAP message, 762 OSCORE processing at the JRC will silently drop the request in case 763 of a failure. This may happen for a number of reasons, including 764 failed lookup of an appropriate security context (e.g. the pledge 765 attempting to join a wrong network), failed decryption, positive 766 replay window lookup, formatting errors (possibly due to malicious 767 alterations in transit). Silently dropping the Join Request at the 768 JRC prevents a DoS attack where an attacker could force the pledge to 769 attempt joining one network at a time, until all networks have been 770 tried. 772 Using a Non-confirmable CoAP message to transport the Join Request 773 also helps minimize the required CoAP state at the pledge and the 774 Join Proxy, keeping it to a minimum typically needed to perform CoAP 775 congestion control. It does, however, introduce some complexity as 776 the pledge needs to implement a retransmission mechanism. 778 The following binary exponential back-off algorithm is inspired by 779 the one described in [RFC7252]. For each Join Request the pledge 780 sends while waiting for a Join Response, the pledge MUST keep track 781 of a timeout and a retransmission counter. For a new Join Request, 782 the timeout is set to a random value between TIMEOUT_BASE and 783 (TIMEOUT_BASE * TIMEOUT_RANDOM_FACTOR), and the retransmission 784 counter is set to 0. When the timeout is triggered and the 785 retransmission counter is less than MAX_RETRANSMIT, the Join Request 786 is retransmitted, the retransmission counter is incremented, and the 787 timeout is doubled. Note that the retransmitted Join Request passes 788 new OSCORE processing, such that the sequence number in the OSCORE 789 context is properly incremented. If the retransmission counter 790 reaches MAX_RETRANSMIT on a timeout, the pledge SHOULD attempt to 791 join the next advertised 6TiSCH network. If the pledge receives a 792 Join Response that successfully passes OSCORE processing, it cancels 793 the pending timeout and processes the response. The pledge MUST 794 silently discard any response not protected with OSCORE, including 795 error codes. For default values of retransmission parameters, see 796 Section 9.5. 798 If all join attempts to advertised networks have failed, the pledge 799 SHOULD signal to the user the presence of an error condition, through 800 some out-of-band mechanism. 802 9.4. Rekeying and Rejoining 804 This specification handles initial keying of the pledge. For reasons 805 such as rejoining after a long sleep, expiry of the short address, or 806 node-initiated rekeying, the joined node MAY send a new Join Request 807 using the already-established OSCORE security context. The JRC then 808 responds with up-to-date keys and a (possibly new) short address. 809 How the joined node decides when to rekey is out of scope of this 810 document. Mechanisms for rekeying the network are defined in 811 companion specifications. 813 9.5. Parameters 815 6JP uses the following parameters: 817 +-----------------------+----------------+ 818 | Name | Default Value | 819 +-----------------------+----------------+ 820 | TIMEOUT_BASE | 10 s | 821 +-----------------------+----------------+ 822 | TIMEOUT_RANDOM_FACTOR | 1.5 | 823 +-----------------------+----------------+ 824 | MAX_RETRANSMIT | 4 | 825 +----------------------------------------+ 827 The values of TIMEOUT_BASE, TIMEOUT_RANDOM_FACTOR, MAX_RETRANSMIT may 828 be configured to values specific to the deployment. The default 829 values have been chosen to accommodate a wide range of deployments, 830 taking into account dense networks. 832 9.6. Mandatory to Implement Algorithms 834 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 835 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 836 securing 802.15.4 frames, and hardware acceleration for it is present 837 in virtually all compliant radio chips. With this choice, CoAP 838 messages are protected with an 8-byte CCM authentication tag, and the 839 algorithm uses 13-byte long nonces. 841 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. 843 The mandatory to implement key derivation function is HKDF [RFC5869], 844 instantiated with a SHA-256 hash. 846 10. Stateless-Proxy CoAP Option 848 The CoAP proxy defined in [RFC7252] keeps per-client state 849 information in order to forward the response towards the originator 850 of the request. This state information includes at least the CoAP 851 token, the IPv6 address of the host, and the UDP source port number. 852 If the JP used the stateful CoAP proxy defined in [RFC7252], it would 853 be prone to Denial-of-Service (DoS) attacks, due to its limited 854 memory. 856 The Stateless-Proxy CoAP option Figure 3 allows the JP to be entirely 857 stateless. This option inserts, in the request, the state 858 information needed for relaying the response back to the client. The 859 proxy still keeps some general state (e.g. for congestion control or 860 request retransmission), but no per-client state. 862 The Stateless-Proxy CoAP option is critical, Safe-to-Forward, not 863 part of the cache key, not repeatable and opaque. When processed by 864 OSCORE, the Stateless-Proxy option is neither encrypted nor integrity 865 protected. 867 +-----+---+---+---+---+-----------------+--------+--------+ 868 | No. | C | U | N | R | Name | Format | Length | 869 +-----+---+---+---+---+-----------------+--------+--------| 870 | TBD | x | | x | | Stateless-Proxy | opaque | 1-255 | 871 +-----+---+---+---+---+-----------------+--------+--------+ 872 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 874 Figure 3: Stateless-Proxy CoAP Option 876 Upon reception of a Stateless-Proxy option, the CoAP server MUST echo 877 it in the response. The value of the Stateless-Proxy option is 878 internal proxy state that is opaque to the server. Example state 879 information includes the IPv6 address of the client, its UDP source 880 port, and the CoAP token. For security reasons, the state 881 information MUST be authenticated, MUST include a freshness indicator 882 (e.g. a sequence number or timestamp) and MAY be encrypted. The 883 proxy may use an appropriate COSE structure [RFC8152] to wrap the 884 state information as the value of the Stateless-Proxy option. The 885 key used for encryption/authentication of the state information may 886 be known only to the proxy. 888 Once the proxy has received the CoAP response with a Stateless-Proxy 889 option present, it decrypts/authenticates it, checks the freshness 890 indicator and constructs the response for the client, based on the 891 information present in the option value. 893 Note that a CoAP proxy using the Stateless-Proxy option is not able 894 to return a 5.04 Gateway Timeout Response Code in case the request to 895 the server times out. Likewise, if the response to the proxy's 896 request does not contain the Stateless-Proxy option, for example when 897 the option is not supported by the server, the proxy is not able to 898 return the response to the client. 900 11. Security Considerations 902 This document recommends that the pledge and JRC are provisioned with 903 unique PSKs. The nonce used for the Join Request and the Join 904 Response is the same, but used under a different key. The design 905 differentiates between keys derived for requests and keys derived for 906 responses by different sender identifiers (0x00 for pledge and 0x01 907 for JRC). Note that the address of the JRC does not take part in 908 nonce or key construction. Even in the case of a misconfiguration in 909 which the same PSK is used for several pledges, the keys used to 910 protect the requests/responses from/towards different pledges are 911 different, as they are derived using the pledge identifier as Master 912 Salt. The PSK is still important for mutual authentication of the 913 pledge and the JRC. Should an attacker come to know the PSK, then a 914 man-in-the-middle attack is possible. The well-known problem with 915 Bluetooth headsets with a "0000" pin applies here. 917 Being a stateless relay, the JP blindly forwards the join traffic 918 into the network. A simple bandwidth cap on the JP prevents it from 919 forwarding more traffic than the network can handle. This forces 920 attackers to use more than one Join Proxy if they wish to overwhelm 921 the network. Marking the join traffic packets with a non-zero DSCP 922 allows the network to carry the traffic if it has capacity, but 923 encourages the network to drop the extra traffic rather than add 924 bandwidth due to that traffic. 926 The shared nature of the "minimal" cell used for the join traffic 927 makes the network prone to DoS attacks by congesting the JP with 928 bogus traffic. Such an attacker is limited by its maximum transmit 929 power. The redundancy in the number of deployed JPs alleviates the 930 issue and also gives the pledge a possibility to use the best 931 available link for joining. How a network node decides to become a 932 JP is out of scope of this specification. 934 At the beginning of the join process, the pledge has no means of 935 verifying the content in the EB, and has to accept it at "face 936 value". In case the pledge tries to join an attacker's network, the 937 Join Response message will either fail the security check or time 938 out. The pledge may implement a blacklist in order to filter out 939 undesired EBs and try to join using the next seemingly valid EB. 940 This blacklist alleviates the issue, but is effectively limited by 941 the node's available memory. Bogus beacons prolong the join time of 942 the pledge, and so the time spent in "minimal" [RFC8180] duty cycle 943 mode. 945 12. Privacy Considerations 947 The join solution specified in this document relies on the uniqueness 948 of the pledge identifier within the namespace managed by the JRC. 949 This identifier is transferred in clear as an OSCORE Context Hint. 950 The use of the globally unique EUI-64 as pledge identifier simplifies 951 the management but comes with certain privacy risks. The 952 implications are thoroughly discussed in [RFC7721] and comprise 953 correlation of activities over time, location tracking, address 954 scanning and device-specific vulnerability exploitation. Since the 955 join protocol is executed rarely compared to the network lifetime, 956 long-term threats that arise from using EUI-64 as the pledge 957 identifier are minimal. In addition, the Join Response message 958 contains a short address which is assigned by the JRC to the pledge. 959 The assigned short address SHOULD be uncorrelated with the long-term 960 pledge identifier. The short address is encrypted in the response. 961 Once the join process completes, the new node uses the short 962 addresses for all further layer 2 (and layer-3) operations. This 963 mitigates the aforementioned privacy risks as the short layer-2 964 address (visible even when the network is encrypted) is not traceable 965 between locations and does not disclose the manufacturer, as is the 966 case of EUI-64. 968 13. IANA Considerations 970 Note to RFC Editor: Please replace all occurrences of "[[this 971 document]]" with the RFC number of this specification. 973 This document allocates a well-known name under the .arpa name space 974 according to the rules given in [RFC3172]. The name "6tisch.arpa" is 975 requested. No subdomains are expected. No A, AAAA or PTR record is 976 requested. 978 13.1. CoAP Option Numbers Registry 980 The Stateless-Proxy option is added to the CoAP Option Numbers 981 registry: 983 +--------+-----------------+-------------------+ 984 | Number | Name | Reference | 985 +--------+-----------------+-------------------+ 986 | TBD | Stateless-Proxy | [[this document]] | 987 +--------+-----------------+-------------------+ 989 14. Acknowledgments 991 The work on this document has been partially supported by the 992 European Union's H2020 Programme for research, technological 993 development and demonstration under grant agreement No 644852, 994 project ARMOUR. 996 The authors are grateful to Thomas Watteyne and Goeran Selander for 997 reviewing, and to Klaus Hartke for providing input on the Stateless- 998 Proxy CoAP option. The authors would also like to thank Francesca 999 Palombini, Ludwig Seitz and John Mattsson for participating in the 1000 discussions that have helped shape the document. 1002 15. References 1004 15.1. Normative References 1006 [I-D.ietf-core-object-security] 1007 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1008 "Object Security for Constrained RESTful Environments 1009 (OSCORE)", draft-ietf-core-object-security-08 (work in 1010 progress), January 2018. 1012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1013 Requirement Levels", BCP 14, RFC 2119, 1014 DOI 10.17487/RFC2119, March 1997, 1015 . 1017 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1018 "Assured Forwarding PHB Group", RFC 2597, 1019 DOI 10.17487/RFC2597, June 1999, 1020 . 1022 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1023 Requirements for the Address and Routing Parameter Area 1024 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1025 September 2001, . 1027 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1028 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1029 October 2013, . 1031 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1032 Application Protocol (CoAP)", RFC 7252, 1033 DOI 10.17487/RFC7252, June 2014, 1034 . 1036 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1037 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1038 . 1040 15.2. Informative References 1042 [I-D.ietf-6tisch-6top-protocol] 1043 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol 1044 (6P)", draft-ietf-6tisch-6top-protocol-09 (work in 1045 progress), October 2017. 1047 [I-D.ietf-6tisch-terminology] 1048 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1049 "Terminology in IPv6 over the TSCH mode of IEEE 1050 802.15.4e", draft-ietf-6tisch-terminology-09 (work in 1051 progress), June 2017. 1053 [I-D.ietf-cbor-cddl] 1054 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 1055 definition language (CDDL): a notational convention to 1056 express CBOR data structures", draft-ietf-cbor-cddl-02 1057 (work in progress), February 2018. 1059 [I-D.richardson-6tisch-minimal-rekey] 1060 Richardson, M., "Minimal Security rekeying mechanism for 1061 6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in 1062 progress), August 2017. 1064 [IEEE802.15.4-2015] 1065 IEEE standard for Information Technology, ., "IEEE Std 1066 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 1067 Networks (WPANs)", 2015. 1069 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 1070 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 1071 RFC 4231, DOI 10.17487/RFC4231, December 2005, 1072 . 1074 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1075 "Transmission of IPv6 Packets over IEEE 802.15.4 1076 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1077 . 1079 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1080 Key Derivation Function (HKDF)", RFC 5869, 1081 DOI 10.17487/RFC5869, May 2010, 1082 . 1084 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1085 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1086 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1087 Low-Power and Lossy Networks", RFC 6550, 1088 DOI 10.17487/RFC6550, March 2012, 1089 . 1091 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1092 Bormann, "Neighbor Discovery Optimization for IPv6 over 1093 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1094 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1095 . 1097 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1098 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1099 Internet of Things (IoT): Problem Statement", RFC 7554, 1100 DOI 10.17487/RFC7554, May 2015, 1101 . 1103 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1104 Considerations for IPv6 Address Generation Mechanisms", 1105 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1106 . 1108 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 1109 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 1110 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 1111 May 2017, . 1113 Appendix A. Example 1115 Figure 4 illustrates a successful join protocol exchange. The pledge 1116 instantiates the OSCORE context and derives the traffic keys and 1117 nonces from the PSK. It uses the instantiated context to protect the 1118 Join Request addressed with a Proxy-Scheme option, the well-known 1119 host name of the JRC in the Uri-Host option, and its EUI-64 as pledge 1120 identifier and OSCORE Context Hint. Triggered by the presence of a 1121 Proxy-Scheme option, the JP forwards the request to the JRC and adds 1122 the Stateless-Proxy option with value set to the internally needed 1123 state, authentication tag, and a freshness indicator. The JP has 1124 learned the IPv6 address of the JRC when it acted as a pledge and 1125 joined the network. Once the JRC receives the request, it looks up 1126 the correct context based on the Context Hint parameter. It 1127 reconstructs OSCORE's external Additional Authenticated Data (AAD) 1128 needed for verification based on: 1130 o the Version of the received CoAP header. 1132 o the Algorithm value agreed out-of-band, default being AES-CCM- 1133 16-64-128 from [RFC8152]. 1135 o the Request ID being set to the value of the "kid" field of the 1136 received COSE object. 1138 o the Join Request sequence number set to the value of "Partial IV" 1139 field of the received COSE object. 1141 o Integrity-protected options received as part of the request. 1143 Replay protection is ensured by OSCORE and through persistent 1144 handling of mutable context parameters. Once the JP receives the 1145 Join Response, it authenticates the Stateless-Proxy option before 1146 deciding where to forward. The JP sets its internal state to that 1147 found in the Stateless-Proxy option, and forwards the Join Response 1148 to the correct pledge. Note that the JP does not possess the key to 1149 decrypt the COSE object (join_response) present in the payload. The 1150 Join Response is matched to the Join Request and verified for replay 1151 protection at the pledge using OSCORE processing rules. In this 1152 example, the Join Response does not contain the IPv6 address of the 1153 JRC, the pledge hence understands the JRC is co-located with the 1154 6LBR. 1156 <---E2E OSCORE--> 1157 Client Proxy Server 1158 Pledge JP JRC 1159 | | | 1160 +------>| | Code: { 0.02 } (POST) 1161 | GET | | Token: 0x8c 1162 | | | Proxy-Scheme: [ coap ] 1163 | | | Uri-Host: [ 6tisch.arpa ] 1164 | | | Object-Security: [ kid: 0 ] 1165 | | | Payload: Context-Hint: EUI-64 1166 | | | [ Partial IV: 1, 1167 | | | { Uri-Path:"j", 1168 | | | join_request }, 1169 | | | ] 1170 | | | 1171 | +------>| Code: { 0.01 } (GET) 1172 | | GET | Token: 0x7b 1173 | | | Uri-Host: [ 6tisch.arpa ] 1174 | | | Object-Security: [ kid: 0 ] 1175 | | | Stateless-Proxy: opaque state 1176 | | | Payload: Context-Hint: EUI-64 1177 | | | [ Partial IV: 1, 1178 | | | { Uri-Path:"j", 1179 | | | join_request }, 1180 | | | ] 1181 | | | 1182 | |<------+ Code: { 2.05 } (Content) 1183 | | 2.05 | Token: 0x7b 1184 | | | Object-Security: - 1185 | | | Stateless-Proxy: opaque state 1186 | | | Payload: [ { join_response }, ] 1187 | | | 1188 |<------+ | Code: { 2.05 } (Content) 1189 | 2.05 | | Token: 0x8c 1190 | | | Object-Security: - 1191 | | | Payload: [ { join_response }, ] 1192 | | | 1194 Figure 4: Example of a successful join protocol exchange. { ... } 1195 denotes encryption and authentication, [ ... ] denotes 1196 authentication. 1198 Where join_request is: 1200 join_request: 1201 [ 1202 h'cafe' / PAN ID of the network pledge is attempting to join / 1203 ] 1204 The join_request encodes to h'8142cafe' with a size of 4 bytes. 1206 And join_response is: 1208 join_response: 1209 [ 1210 [ / COSE Key Set array with a single key / 1211 { 1212 1 : 4, / key type symmetric / 1213 2 : h'01', / key id / 1214 -1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value / 1215 } 1216 ], 1217 [ 1218 h'af93' / assigned short address / 1219 ] 1220 ] 1222 The join_response encodes to 1223 h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with 1224 a size of 30 bytes. 1226 Authors' Addresses 1228 Malisa Vucinic (editor) 1229 University of Montenegro 1230 Dzordza Vasingtona bb 1231 Podgorica 81000 1232 Montenegro 1234 Email: malisav@ac.me 1236 Jonathan Simon 1237 Analog Devices 1238 32990 Alvarado-Niles Road, Suite 910 1239 Union City, CA 94587 1240 USA 1242 Email: jonathan.simon@analog.com 1243 Kris Pister 1244 University of California Berkeley 1245 512 Cory Hall 1246 Berkeley, CA 94720 1247 USA 1249 Email: pister@eecs.berkeley.edu 1251 Michael Richardson 1252 Sandelman Software Works 1253 470 Dawson Avenue 1254 Ottawa, ON K1Z5V7 1255 Canada 1257 Email: mcr+ietf@sandelman.ca