idnits 2.17.1 draft-ietf-6tisch-minimal-security-04.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 (October 30, 2017) is 2363 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-06 ** 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-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Working Group M. Vucinic, Ed. 3 Internet-Draft University of Montenegro 4 Intended status: Standards Track J. Simon 5 Expires: May 3, 2018 Analog Devices 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 October 30, 2017 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-04 15 Abstract 17 This document describes the minimal configuration 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 entities involved use CoAP 20 (Constrained Application Protocol) and OSCORE (Object Security for 21 Constrained RESTful Environments). The configuration requires that 22 the pledge and the JRC (join registrar/coordinator, a central 23 entity), share a symmetric key. How this key is provisioned is out 24 of scope of this document. The result of the joining process is that 25 the JRC configures the pledge with link-layer keying material and a 26 short link-layer address. This specification also defines a new 27 Stateless-Proxy CoAP option. Additional security mechanisms may be 28 added on top of this minimal framework. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 3, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. One-Touch Assumption . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Pre-Shared Key . . . . . . . . . . . . . . . . . . . . . 4 68 4. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 6 70 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 7 71 4.3. Step 3 - Join Request . . . . . . . . . . . . . . . . . . 7 72 4.4. Step 4 - Join Response . . . . . . . . . . . . . . . . . 8 73 5. Architectural Overview and Communication through Join Proxy . 8 74 5.1. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . 9 75 6. OSCORE Security Context . . . . . . . . . . . . . . . . . . . 10 76 6.1. Persistency . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Specification of Join Request . . . . . . . . . . . . . . . . 11 78 8. Specification of Join Response . . . . . . . . . . . . . . . 11 79 8.1. Link-layer Keys Transported in COSE Key Set . . . . . . . 12 80 8.2. Short Address . . . . . . . . . . . . . . . . . . . . . . 12 81 9. Error Handling and Retransmission . . . . . . . . . . . . . . 13 82 10. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 11. Mandatory to Implement Algorithms . . . . . . . . . . . . . . 14 84 12. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 14 85 13. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 15 86 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 88 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 16.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 16 90 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 91 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 18.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 18.2. Informative References . . . . . . . . . . . . . . . . . 18 94 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 This document presumes a 6TiSCH network as described by [RFC7554], 100 [RFC8180], [I-D.ietf-6tisch-6top-protocol], and 101 [I-D.ietf-6tisch-terminology]. By design, nodes in a 6TiSCH network 102 [RFC7554] have their radio turned off most of the time, to conserve 103 energy. As a consequence, the link used by a new device for joining 104 the network has limited bandwidth [RFC8180]. The secure join 105 solution defined in this document therefore keeps the number of over- 106 the-air exchanges for join purposes to a minimum. 108 The micro-controllers at the heart of 6TiSCH nodes have a small 109 amount of code memory. It is therefore paramount to reuse existing 110 protocols available as part of the 6TiSCH stack. At the application 111 layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web 112 transfer, and on OSCORE [I-D.ietf-core-object-security] for its end- 113 to-end security. The secure join solution defined in this document 114 therefore reuses those two protocols as its building blocks. 116 This document defines a secure join solution for a new device, called 117 "pledge", to securely join a 6TiSCH network. The specification 118 configures different layers of the 6TiSCH protocol stack and also 119 defines a new CoAP option. It assumes the presence of a JRC (join 120 registrar/coordinator), a central entity. It further assumes that 121 the pledge and the JRC share a symmetric key, called PSK (pre-shared 122 key). How the PSK is installed is out of scope of this document. 124 When the pledge seeks admission to a 6TiSCH network, it first 125 synchronizes to it, by initiating the passive scan defined in 126 [IEEE802.15.4-2015]. The pledge then exchanges messages with the 127 JRC; these messages can be forwarded by nodes already part of the 128 6TiSCH network. The messages exchanged allow the JRC and the pledge 129 to mutually authenticate, based on the PSK. They also allow the JRC 130 to configure the pledge with link-layer keying material and a short 131 link-layer address. After this secure joining process successfully 132 completes, the joined node can establish an end-to-end secure session 133 with an Internet host. The joined node can also interact with its 134 neighbors to request additional bandwidth using the 6top Protocol 135 [I-D.ietf-6tisch-6top-protocol]. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. These 142 words may also appear in this document in lowercase, absent their 143 normative meanings. 145 The reader is expected to be familiar with the terms and concepts 146 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 147 [I-D.ietf-core-object-security], and [RFC8152]. 149 The specification also includes a set of informative examples using 150 the CBOR diagnostic notation [I-D.ietf-cbor-cddl]. 152 The following terms are used throughout this document: 154 pledge: The new device that wishes to join a 6TiSCH network. 156 joined node: The new device, after having completed the join 157 process, often just called a node. 159 join proxy (JP): A node already part of the 6TiSCH network that 160 serves as a relay to provide connectivity between the pledge and 161 the JRC. 163 join registrar/coordinator (JRC): A central entity responsible for 164 the authentication, authorization and configuration of the pledge. 166 3. One-Touch Assumption 168 This document assumes a one-touch scenario. The pledge is 169 provisioned with a PSK before attempting to join the network, and the 170 same PSK (as well as the uniquer identifier of the pledge) is 171 provisioned on the JRC. 173 There are many ways by which this provisioning can be done. 174 Physically, the PSK can be written into the pledge using a number of 175 mechanisms, such as a JTAG interface, a serial (craft) console 176 interface, pushing buttons simultaneously on different devices, over- 177 the-air configuration in a Faraday cage, etc. The provisioning can 178 be done by the vendor, the manufacturer, the integrator, etc. 180 Details of how this provisioning is done is out of scope of this 181 document. What is assumed is that there can be a secure, private 182 conversation between the JRC and the pledge, and that the two devices 183 can exchange the PSK. 185 3.1. Pre-Shared Key 187 The PSK SHOULD be at least 128 bits in length, generated uniformly at 188 random. It is RECOMMENDED to generate the PSK with a 189 cryptographically secure pseudorandom number generator. Each pledge 190 SHOULD be provisioned with a unique PSK. 192 4. Join Overview 194 This section describes the steps taken by a pledge in a 6TiSCH 195 network. When a pledge seeks admission to a 6TiSCH network, the 196 following exchange occurs: 198 1. The pledge listens for an Enhanced Beacon (EB) frame 199 [IEEE802.15.4-2015]. This frame provides network synchronization 200 information, and tells the device when it can send a frame to the 201 node sending the beacons, which plays the role of join proxy (JP) 202 for the pledge, and when it can expect to receive a frame. 204 2. The pledge configures its link-local IPv6 address and advertises 205 it to the join proxy (JP). 207 3. The pledge sends a Join Request to JP in order to securely 208 identify itself to the network. The Join Request is directed to 209 the JRC, which may be co-located on the JP or another device. 211 4. In case of successful processing of the request, the pledge 212 receives a join response from JRC (via the JP) that sets up one 213 or more link-layer keys used to authenticate and encrypt 214 subsequent transmissions to peers, and a short link-layer address 215 for the pledge. 217 From the pledge's perspective, minimal joining is a local phenomenon 218 - the pledge only interacts with the JP, and it need not know how far 219 it is from the 6LBR, or how to route to the JRC. Only after 220 establishing one or more link-layer keys does it need to know about 221 the particulars of a 6TiSCH network. 223 The process is shown as a transaction diagram in Figure 1: 225 +--------+ +-------+ +--------+ 226 | pledge | | JP | | JRC | 227 | | | | | | 228 +--------+ +-------+ +--------+ 229 | | | 230 |<---Enhanced Beacon (1)---| | 231 | | | 232 |<-Neighbor Discovery (2)->| | 233 | | | 234 |-----Join Request (3)-----|------Join Request (3a)-->| 235 | | | 236 |<---Join Response (4)-----|-----Join Response (4a)---| 237 | | | 239 Figure 1: Overview of a successful join process. 241 The details of each step are described in the following sections. 243 4.1. Step 1 - Enhanced Beacon 245 The pledge synchronizes to the network by listening for, and 246 receiving, an Enhanced Beacon (EB) sent by a node already in the 247 network. This process is entirely defined by [IEEE802.15.4-2015], 248 and described in [RFC7554]. 250 Once the pledge hears an EB, it synchronizes to the joining schedule 251 using the cells contained in the EB. The pledge can hear multiple 252 EBs; the selection of which EB to use is out of the scope for this 253 document, and is discussed in [RFC7554]. Implementers SHOULD make 254 use of information such as: what Personal Area Network Identifier 255 (PAN ID) [IEEE802.15.4-2015] the EB contains, whether the source 256 link-layer address of the EB has been tried before, what signal 257 strength the different EBs were received at, etc. In addition, the 258 pledge may be pre-configured to search for EBs with a specific PAN 259 ID. 261 Once the pledge selects the EB, it synchronizes to it and transitions 262 into a low-power mode. It deeply duty cycles its radio, switching 263 the radio on when the provided schedule indicates slots which the 264 pledge may use for the join process. During the remainder of the 265 join process, the node that has sent the EB to the pledge plays the 266 role of JP. 268 At this point, the pledge may proceed to step 2, or continue to 269 listen for additional EBs. 271 4.2. Step 2 - Neighbor Discovery 273 The pledge forms its link-local IPv6 address based on EUI-64, as per 274 [RFC4944]. The Neighbor Discovery exchange shown in Figure 1 refers 275 to a single round trip Neighbor Solicitation / Neighbor Advertisement 276 exchange between the pledge and the JP (Section 5.5.1 of [RFC6775]). 277 The pledge uses the link-local IPv6 address for all subsequent 278 communication with the JP during the join process. 280 Note that ND exchanges at this point are not protected with link- 281 layer security as the pledge is not in possession of the keys. How 282 JP accepts these unprotected frames is discussed in Section 12. 284 The pledge and the JP SHOULD keep a separate neighbor cache for 285 untrusted entries and use it to store each other's information during 286 the join process. Mixing neighbor entries belonging to pledges and 287 nodes that are part of the network opens up the JP to a DoS attack. 288 How the pledge and JP decide to transition each other from untrusted 289 to trusted cache, once the join process completes, is out of scope. 290 One implementation technique is to use the information whether the 291 incoming frames are secured at the link layer. 293 4.3. Step 3 - Join Request 295 The Join Request is a message sent from the pledge to the JP using 296 the shared slot as described in the EB, and which the JP forwards to 297 the JRC. The JP forwards the Join Request to the JRC on the existing 298 6TiSCH network. How exactly this happens is out of scope of this 299 document; some networks may wish to dedicate specific slots for this 300 join traffic. 302 The Join Request is authenticated/encrypted end-to-end using an AEAD 303 algorithm from [RFC8152] and a key derived from the PSK, the pledge's 304 EUI-64 and a request-specific constant value. Algorithms which MUST 305 be implemented are specified in Section 11. 307 The nonce used when securing the Join Request is derived from the 308 PSK, the pledge's EUI-64 and a monotonically increasing counter 309 initialized to 0 when first starting. 311 Join Request construction is specified in Section 7, while the 312 details on processing can be found in Section 7 of 313 [I-D.ietf-core-object-security]. 315 4.4. Step 4 - Join Response 317 The Join Response is sent by the JRC to the pledge, and is forwarded 318 through the JP as it serves as a stateless relay. The packet 319 containing the Join Response travels from the JRC to JP using the 320 operating routes in the 6TiSCH network. The JP delivers it to the 321 pledge using the slot information it has indicated in the EB it sent. 322 The JP operates as the application-layer proxy, and does not keep any 323 state to relay the message. It uses information sent in the clear 324 within the Join Response to decide where to forward to. 326 The Join Response is authenticated/encrypted end-to-end using an AEAD 327 algorithm from [RFC8152]. The key used to protect the response is 328 different from the one used to protect the request (both are derived 329 from the PSK, as explained in Section 6). The response is protected 330 using the same nonce as in the request. 332 The Join Response contains one or more link-layer key(s) that the 333 pledge will use for subsequent communication. Each key that is 334 provided by the JRC is associated with an 802.15.4 key identifier. 335 In other link-layer technologies, a different identifier may be 336 substituted. The Join Response also contains an IEEE 802.15.4 short 337 address [IEEE802.15.4-2015] assigned by the JRC to the pledge, and 338 optionally the IPv6 address of the JRC. 340 Join Response construction is specified in Section 8, while the 341 details on processing can be found in Section 7 of 342 [I-D.ietf-core-object-security]. 344 5. Architectural Overview and Communication through Join Proxy 346 The Join Request/Join Response exchange in Figure 1 is carried over 347 CoAP [RFC7252] and secured using OSCORE 348 [I-D.ietf-core-object-security]. The pledge plays the role of a CoAP 349 client; the JRC plays the role of a CoAP server. The JP implements 350 CoAP forward proxy functionality [RFC7252]. Because the JP can also 351 be a constrained device, it cannot implement a cache. Rather, the JP 352 processes forwarding-related CoAP options and makes requests on 353 behalf of the pledge, in a stateless manner. 355 The pledge communicates with a JP over link-local IPv6 addresses. 356 The pledge designates a JP as a proxy by including the Proxy-Scheme 357 option with value "coap" (CoAP-to-CoAP proxy) in CoAP requests it 358 sends to the JP. The pledge MUST include the Uri-Host option with 359 its value set to the well-known JRC's alias "6tisch.arpa". This 360 allows the pledge to join without knowing the IPv6 address of the 361 JRC. The pledge learns the actual IPv6 address of the JRC from the 362 Join Response; it uses it once joined in order to operate as a JP. 364 The JRC can be co-located on the 6LBR. Before the 6TiSCH network is 365 started, the 6LBR MUST be provisioned with the IPv6 address of the 366 JRC. 368 5.1. Stateless-Proxy CoAP Option 370 The CoAP proxy defined in [RFC7252] keeps per-client state 371 information in order to forward the response towards the originator 372 of the request. This state information includes at least the CoAP 373 token, the IPv6 address of the host, and the UDP source port number. 374 If the JP used the stateful CoAP proxy defined in [RFC7252], it would 375 be prone to Denial-of-Service (DoS) attacks, due to its limited 376 memory. 378 The Stateless-Proxy CoAP option Figure 2 allows the JP to be entirely 379 stateless. This option inserts, in the request, the state 380 information needed for relaying the response back to the client. The 381 proxy still keeps some general state (e.g. for congestion control or 382 request retransmission), but no per-client state. 384 The Stateless-Proxy CoAP option is critical, Safe-to-Forward, not 385 part of the cache key, not repeatable and opaque. When processed by 386 OSCORE, the Stateless-Proxy option is neither encrypted nor integrity 387 protected. 389 +-----+---+---+---+---+-----------------+--------+--------+ 390 | No. | C | U | N | R | Name | Format | Length | 391 +-----+---+---+---+---+-----------------+--------+--------| 392 | TBD | x | | x | | Stateless-Proxy | opaque | 1-255 | 393 +-----+---+---+---+---+-----------------+--------+--------+ 394 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 396 Figure 2: Stateless-Proxy CoAP Option 398 Upon reception of a Stateless-Proxy option, the CoAP server MUST echo 399 it in the response. The value of the Stateless-Proxy option is 400 internal proxy state that is opaque to the server. Example state 401 information includes the IPv6 address of the client, its UDP source 402 port, and the CoAP token. For security reasons, the state 403 information MUST be authenticated, MUST include a freshness indicator 404 (e.g. a sequence number or timestamp) and MAY be encrypted. The 405 proxy may use an appropriate COSE structure [RFC8152] to wrap the 406 state information as the value of the Stateless-Proxy option. The 407 key used for encryption/authentication of the state information may 408 be known only to the proxy. 410 Once the proxy has received the CoAP response with Stateless-Proxy 411 option present, it decrypts/authenticates it, checks the freshness 412 indicator and constructs the response for the client, based on the 413 information present in the option value. 415 Note that a CoAP proxy using the Stateless-Proxy option is not able 416 to return a 5.04 Gateway Timeout Response Code in case the request to 417 the server times out. Likewise, if the response to the proxy's 418 request does not contain the Stateless-Proxy option, for example when 419 the option is not supported by the server, the proxy is not able to 420 return the response to the client. 422 6. OSCORE Security Context 424 The OSCORE security context MUST be derived at the pledge and the JRC 425 as per Section 3 of [I-D.ietf-core-object-security]. 427 o the Master Secret MUST be the PSK. 429 o the Master Salt MUST be pledge's EUI-64. 431 o the Sender ID of the pledge MUST be set to byte string 0x00. 433 o the Recipient ID (ID of the JRC) MUST be set to byte string 0x01. 435 o the Algorithm MUST be set to the value from [RFC8152], agreed out- 436 of-band by the same mechanism used to provision the PSK. The 437 default is AES-CCM-16-64-128. 439 o the Key derivation function MUST be agreed out-of-band. Default 440 is HKDF SHA-256. 442 The derivation in [I-D.ietf-core-object-security] results in traffic 443 keys and a common IV for each side of the conversation. Nonces are 444 constructed by XOR'ing the common IV with the current sequence number 445 and sender identifier. For details on nonce construction, refer to 446 [I-D.ietf-core-object-security]. 448 It is RECOMMENDED that a PAN ID be provisioned to the pledge out-of- 449 band by the same mechanism used to provision the PSK. This prevents 450 the pledge from attempting to join a wrong network. If the pledge is 451 not provisioned with the PAN ID, it SHOULD attempt to join one 452 network at a time. In that case, implementations MUST ensure that 453 multiple CoAP requests to different JRCs result in the use of the 454 same OSCORE context so that sequence numbers are properly incremented 455 for each request. 457 6.1. Persistency 459 Implementations MUST ensure that mutable OSCORE context parameters 460 (Sender Sequence Number, Replay Window) are stored in persistent 461 memory. A technique that prevents reuse of sequence numbers, 462 detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be 463 implemented. Each update of the OSCORE Replay Window MUST be written 464 to persistent memory. 466 This is an important security requirement in order to guarantee nonce 467 uniqueness and resistance to replay attacks across reboots and 468 rejoins. Traffic between the pledge and the JRC is rare, making 469 security outweigh the cost of writing to persistent memory. 471 7. Specification of Join Request 473 The Join Request the pledge sends SHALL be mapped to a CoAP request: 475 o The request method is POST. 477 o The type is Non-confirmable (NON). 479 o The Proxy-Scheme option is set to "coap". 481 o The Uri-Host option is set to "6tisch.arpa". 483 o The Uri-Path option is set to "j". 485 o The Object-Security option SHALL be set according to 486 [I-D.ietf-core-object-security]. The OSCORE Context Hint SHALL be 487 set to pledge's EUI-64. The OSCORE Context Hint allows the JRC to 488 retrieve the security context for a given pledge. 490 o The payload is empty. 492 8. Specification of Join Response 494 If the JRC successfully processes the Join Request using OSCORE, and 495 if the pledge is authorized to join the network, the Join Response 496 the JRC sends back to the pledge SHALL be mapped to a CoAP response: 498 o The response Code is 2.04 (Changed). 500 o The payload is a CBOR [RFC7049] array containing, in order: 502 * the COSE Key Set, specified in [RFC8152], containing one or 503 more link-layer keys. The mapping of individual keys to 504 802.15.4-specific parameters is described in Section 8.1. 506 * the link-layer short address to be used by the pledge. The 507 format of the short address follows Section 8.2. 509 * optionally, the IPv6 address of the JRC transported as a byte 510 string. If the IPv6 address of the JRC is not present in the 511 Join Response, this indicates the JRC is co-located with 6LBR, 512 and has the same IPv6 address as the 6LBR. The address of the 513 6LBR can then be learned from DODAGID field in RPL DIOs 514 [RFC6550]. 516 response_payload = [ 517 COSE_KeySet, 518 short_address, 519 ? JRC_address : bstr, 520 ] 522 8.1. Link-layer Keys Transported in COSE Key Set 524 Each key in the COSE Key Set [RFC8152] SHALL be a symmetric key. If 525 the "kid" parameter of the COSE Key structure is present, the 526 corresponding keys SHALL belong to an IEEE 802.15.4 KeyIdMode 0x01 527 class. In that case, parameter "kid" of the COSE Key structure SHALL 528 be used to carry the IEEE 802.15.4 KeyIndex value. If the "kid" 529 parameter is not present in the transported key, the application 530 SHALL consider the key to be an IEEE 802.15.4 KeyIdMode 0x00 531 (implicit) key. This document does not support IEEE 802.15.4 532 KeyIdMode 0x02 and 0x03 class keys. 534 8.2. Short Address 536 The "short_address" structure transported as part of the join 537 response payload represents the IEEE 802.15.4 short address assigned 538 to the pledge. It is encoded as a CBOR array object, containing, in 539 order: 541 o Byte string, containing the 16-bit address. 543 o Optionally, the lease time parameter, "lease_asn". The value of 544 the "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN) 545 corresponding to its expiration, carried as a byte string in 546 network byte order. 548 short_address = [ 549 address : bstr, 550 ? lease_asn : bstr, 551 ] 552 It is up to the joined node to request a new short address before the 553 expiry of its previous address. The mechanism by which the node 554 requests renewal is the same as during join procedure, as described 555 in Section 13. The assigned short address is used for configuring 556 both link-layer short address and IPv6 addresses. 558 9. Error Handling and Retransmission 560 Since the Join Request is mapped to a Non-confirmable CoAP message, 561 OSCORE processing at JRC will silently drop the request in case of a 562 failure. This may happen for a number of reasons, including failed 563 lookup of an appropriate security context, failed decryption, 564 positive replay window lookup, formatting errors possibly due to 565 malicious alterations in transit. Silent drop at JRC prevents a DoS 566 attack where an attacker could force the pledge to attempt joining 567 one network at a time, until all networks have been tried. 569 Using Non-confirmable CoAP message to transport Join Request also 570 helps minimize the required CoAP state at the pledge and the Join 571 Proxy, keeping it to a minimum typically needed to perform CoAP 572 congestion control. It does, however, introduce complexity at the 573 application layer, as the pledge needs to implement a retransmission 574 mechanism. 576 The following binary exponential back-off algorithm is inspired by 577 the one described in [RFC7252]. For each Join Request the pledge 578 sends while waiting for a Join Response, the pledge MUST keep track 579 of a timeout and a retransmission counter. For a new Join Request, 580 the timeout is set to a random value between TIMEOUT and (TIMEOUT * 581 TIMEOUT_RANDOM_FACTOR), and the retransmission counter is set to 0. 582 When the timeout is triggered and the retransmission counter is less 583 than MAX_RETRANSMIT, the Join Request is retransmitted, the 584 retransmission counter is incremented, and the timeout is doubled. 585 Note that the retransmitted Join Request passes new OSCORE 586 processing, such that the sequence number in the OSCORE context is 587 properly incremented. If the retransmission counter reaches 588 MAX_RETRANSMIT on a timeout, the pledge SHOULD attempt to join the 589 next advertised 6TiSCH network. If the pledge receives a Join 590 Response that successfully passed OSCORE processing, it cancels the 591 pending timeout and processes the response. The pledge MUST silently 592 discard any response not protected with OSCORE, including error 593 codes. For default values of retransmission parameters, see 594 Section 10. 596 If all join attempts to advertised networks have failed, the pledge 597 SHOULD signal to the user the presence of an error condition, through 598 some out-of-band mechanism. 600 10. Parameters 602 This specification uses the following parameters: 604 +-----------------------+----------------+ 605 | Name | Default Value | 606 +-----------------------+----------------+ 607 | TIMEOUT | 10 s | 608 +-----------------------+----------------+ 609 | TIMEOUT_RANDOM_FACTOR | 1.5 | 610 +-----------------------+----------------+ 611 | MAX_RETRANSMIT | 4 | 612 +----------------------------------------+ 614 The values of TIMEOUT, TIMEOUT_RANDOM_FACTOR, MAX_RETRANSMIT may be 615 configured to values specific to the deployment. The default values 616 have been chosen to accommodate a wide range of deployments, taking 617 into account dense networks. 619 11. Mandatory to Implement Algorithms 621 The mandatory to implement AEAD algorithm for use with OSCORE is AES- 622 CCM-16-64-128 from [RFC8152]. This is the algorithm used for 623 securing 802.15.4 frames, and hardware acceleration for it is present 624 in virtually all compliant radio chips. With this choice, CoAP 625 messages are protected with an 8-byte CCM authentication tag, and the 626 algorithm uses 13-byte long nonces. 628 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. 630 12. Link-layer Requirements 632 In an operational 6TiSCH network, all frames MUST use link-layer 633 frame security [RFC8180]. The frame security options MUST include 634 frame authentication, and MAY include frame encryption. 636 The pledge does not initially do any authentication of the EB frames, 637 as it does not know the K1 key [RFC8180]. When sending frames, the 638 pledge sends unencrypted and unauthenticated frames. The JP accepts 639 these frames (using the "exempt mode" in 802.15.4) for the duration 640 of the join process. How the JP learns whether the join process is 641 ongoing is out of scope of this specification. 643 As the EB itself cannot be authenticated by the pledge, an attacker 644 may craft a frame that appears to be a valid EB, since the pledge can 645 neither know the ASN a priori nor verify the address of the JP. This 646 opens up a possibility of DoS attack, as discussed in Section 14. 647 Beacon authentication keys are discussed in [RFC8180]. 649 13. Rekeying and Rejoin 651 This specification handles initial keying of the pledge. For reasons 652 such as rejoining after a long sleep, expiry of the short address, or 653 node-initiated rekeying, the joined node MAY send a new Join Request 654 using the already-established OSCORE security context. The JRC then 655 responds with up-to-date keys and a (possibly new) short address. 656 How the joined node decides when to rekey is out of scope of this 657 document. Mechanisms for rekeying the network are defined in 658 companion specifications, such as 659 [I-D.richardson-6tisch-minimal-rekey]. 661 14. Security Considerations 663 This document recommends that the pledge and JRC are provisioned with 664 unique PSKs. The request nonce and the response nonce are the same, 665 but used under a different key. The design differentiates between 666 keys derived for requests and keys derived for responses by different 667 sender identifiers (0x00 for pledge and 0x01 for JRC). Note that the 668 address of the JRC does not take part in nonce or key construction. 669 Even in case of a misconfiguration in which the same PSK is used for 670 several nodes, the keys used to protect the requests/responses from/ 671 towards different pledges are different, as they are derived using 672 the pledge's EUI-64 as Master Salt. The PSK is still important for 673 mutual authentication of the pledge and JRC. Should an attacker come 674 to know the PSK, then a man-in-the-middle attack is possible. The 675 well-known problem with Bluetooth headsets with a "0000" pin applies 676 here. 678 Being a stateless relay, the JP blindly forwards the join traffic 679 into the network. While the exchange between pledge and JP takes 680 place over a shared 6TiSCH cell, join traffic is forwarded using 681 dedicated cells on the JP to JRC multi-hop path. In case of 682 distributed scheduling, the join traffic may therefore cause 683 intermediate nodes to request additional bandwidth. Because the 684 relay operation of the JP is implemented at the application layer, 685 the JP is the only hop on the JP-6LBR path that can distinguish join 686 traffic from regular IP traffic in the network. It is therefore 687 recommended to implement stateless rate limiting at JP; a simple 688 bandwidth cap would be appropriate. 690 The shared nature of the "minimal" cell used for the join traffic 691 makes the network prone to DoS attacks by congesting the JP with 692 bogus radio traffic. As such an attacker is limited by its emitted 693 radio power, the redundancy in the number of deployed JPs alleviates 694 the issue and also gives the pledge a possibility to use the best 695 available link for joining. How a network node decides to become a 696 JP is out of scope of this specification. 698 At the beginning of the join process, the pledge has no means of 699 verifying the content in the EB, and has to accept it at "face 700 value". In case the pledge tries to join an attacker's network, the 701 Join Response message will either fail the security check or time 702 out. The pledge may implement a blacklist in order to filter out 703 undesired EBs and try to join using the next seemingly valid EB. 704 This blacklist alleviates the issue, but is effectively limited by 705 the node's available memory. Bogus beacons prolong the join time of 706 the pledge, and so the time spent in "minimal" [RFC8180] duty cycle 707 mode. 709 15. Privacy Considerations 711 This specification relies on the uniqueness of the node's EUI-64 that 712 is transferred in clear as an OSCORE Context Hint. Privacy 713 implications of using such long-term identifier are discussed in 714 [RFC7721] and comprise correlation of activities over time, location 715 tracking, address scanning and device-specific vulnerability 716 exploitation. Since the join protocol is executed rarely compared to 717 the network lifetime, long-term threats that arise from using EUI-64 718 are minimal. In addition, the Join Response message contains a short 719 address which is assigned by JRC to the pledge. The assigned short 720 address SHOULD be uncorrelated with the long-term EUI-64 identifier. 721 The short address is encrypted in the response. Use of short 722 addresses once the join protocol completes mitigates the 723 aforementioned privacy risks. 725 16. IANA Considerations 727 Note to RFC Editor: Please replace all occurrences of "[[this 728 document]]" with the RFC number of this specification. 730 This document allocates a well-known name under the .arpa name space 731 according to the rules given in: [RFC3172]. The name "6tisch.arpa" 732 is requested. No subdomains are expected. No A, AAAA or PTR record 733 is requested. 735 16.1. CoAP Option Numbers Registry 737 The Stateless-Proxy option is added to the CoAP Option Numbers 738 registry: 740 +--------+-----------------+-------------------+ 741 | Number | Name | Reference | 742 +--------+-----------------+-------------------+ 743 | TBD | Stateless-Proxy | [[this document]] | 744 +--------+-----------------+-------------------+ 746 17. Acknowledgments 748 The work on this document has been partially supported by the 749 European Union's H2020 Programme for research, technological 750 development and demonstration under grant agreement No 644852, 751 project ARMOUR. 753 The authors are grateful to Thomas Watteyne and Goeran Selander for 754 reviewing, and to Klaus Hartke for providing input on the Stateless- 755 Proxy CoAP option. The authors would also like to thank Francesca 756 Palombini, Ludwig Seitz and John Mattsson for participating in the 757 discussions that have helped shape the document. 759 18. References 761 18.1. Normative References 763 [I-D.ietf-core-object-security] 764 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 765 "Object Security for Constrained RESTful Environments 766 (OSCORE)", draft-ietf-core-object-security-06 (work in 767 progress), October 2017. 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, 771 DOI 10.17487/RFC2119, March 1997, 772 . 774 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 775 Requirements for the Address and Routing Parameter Area 776 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 777 September 2001, . 779 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 780 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 781 October 2013, . 783 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 784 Application Protocol (CoAP)", RFC 7252, 785 DOI 10.17487/RFC7252, June 2014, 786 . 788 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 789 RFC 8152, DOI 10.17487/RFC8152, July 2017, 790 . 792 18.2. Informative References 794 [I-D.ietf-6tisch-6top-protocol] 795 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol 796 (6P)", draft-ietf-6tisch-6top-protocol-09 (work in 797 progress), October 2017. 799 [I-D.ietf-6tisch-terminology] 800 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 801 "Terminology in IPv6 over the TSCH mode of IEEE 802 802.15.4e", draft-ietf-6tisch-terminology-09 (work in 803 progress), June 2017. 805 [I-D.ietf-cbor-cddl] 806 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 807 definition language (CDDL): a notational convention to 808 express CBOR data structures", draft-ietf-cbor-cddl-00 809 (work in progress), July 2017. 811 [I-D.richardson-6tisch-minimal-rekey] 812 Richardson, M., "Minimal Security rekeying mechanism for 813 6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in 814 progress), August 2017. 816 [IEEE802.15.4-2015] 817 IEEE standard for Information Technology, ., "IEEE Std 818 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 819 Networks (WPANs)", 2015. 821 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 822 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 823 RFC 4231, DOI 10.17487/RFC4231, December 2005, 824 . 826 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 827 "Transmission of IPv6 Packets over IEEE 802.15.4 828 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 829 . 831 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 832 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 833 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 834 Low-Power and Lossy Networks", RFC 6550, 835 DOI 10.17487/RFC6550, March 2012, 836 . 838 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 839 Bormann, "Neighbor Discovery Optimization for IPv6 over 840 Low-Power Wireless Personal Area Networks (6LoWPANs)", 841 RFC 6775, DOI 10.17487/RFC6775, November 2012, 842 . 844 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 845 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 846 Internet of Things (IoT): Problem Statement", RFC 7554, 847 DOI 10.17487/RFC7554, May 2015, 848 . 850 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 851 Considerations for IPv6 Address Generation Mechanisms", 852 RFC 7721, DOI 10.17487/RFC7721, March 2016, 853 . 855 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 856 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 857 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 858 May 2017, . 860 Appendix A. Example 862 Figure 3 illustrates a successful join protocol exchange. The pledge 863 instantiates the OSCORE context and derives the traffic keys and 864 nonces from the PSK. It uses the instantiated context to protect the 865 Join Request addressed with a Proxy-Scheme option, the well-known 866 host name of the JRC in the Uri-Host option, and its EUI-64 867 identifier as OSCORE Context Hint. Triggered by the presence of 868 Proxy-Scheme option, the JP forwards the request to the JRC and adds 869 the Stateless-Proxy option with value set to the internally needed 870 state, authentication tag, and a freshness indicator. The JP learned 871 the IPv6 address of JRC when it acted as a pledge and joined the 872 network. Once the JRC receives the request, it looks up the correct 873 context based on the Context Hint parameter. It reconstructs 874 OSCORE's external Additional Authenticated Data (AAD) needed for 875 verification based on: 877 o the Version of the received CoAP header. 879 o the Algorithm value agreed out-of-band, default being AES-CCM- 880 16-64-128 from [RFC8152]. 882 o the Request ID being set to the value of the "kid" field of the 883 received COSE object. 885 o the Join Request sequence number set to the value of "Partial IV" 886 field of the received COSE object. 888 o Integrity-protected options received as part of the request. 890 Replay protection is ensured by OSCORE and the tracking of sequence 891 numbers at each side. Once the JP receives the Join Response, it 892 authenticates the Stateless-Proxy option before deciding where to 893 forward. The JP sets its internal state to that found in the 894 Stateless-Proxy option, and forwards the Join Response to the correct 895 pledge. Note that the JP does not possess the key to decrypt the 896 COSE object (join_response) present in the payload. The Join 897 Response is matched to the Join Request and verified for replay 898 protection at the pledge using OSCORE processing rules. In this 899 example, the Join Response does not contain the IPv6 address of the 900 JRC, the pledge hence understands the JRC is co-located with the 901 6LBR. 903 <---E2E OSCORE--> 904 Client Proxy Server 905 Pledge JP JRC 906 | | | 907 +------>| | Code: { 0.02 } (POST) 908 | GET | | Token: 0x8c 909 | | | Proxy-Scheme: [ coap ] 910 | | | Uri-Host: [ 6tisch.arpa ] 911 | | | Object-Security: [ kid: 0 ] 912 | | | Payload: Context-Hint: EUI-64 913 | | | [ Partial IV: 1, 914 | | | { Uri-Path:"j" }, 915 | | | ] 916 | | | 917 | +------>| Code: { 0.01 } (GET) 918 | | GET | Token: 0x7b 919 | | | Uri-Host: [ 6tisch.arpa ] 920 | | | Object-Security: [ kid: 0 ] 921 | | | Stateless-Proxy: opaque state 922 | | | Payload: Context-Hint: EUI-64 923 | | | [ Partial IV: 1, 924 | | | { Uri-Path:"j" }, 925 | | | ] 926 | | | 927 | |<------+ Code: { 2.05 } (Content) 928 | | 2.05 | Token: 0x7b 929 | | | Object-Security: - 930 | | | Stateless-Proxy: opaque state 931 | | | Payload: [ { join_response }, ] 932 | | | 933 |<------+ | Code: { 2.05 } (Content) 934 | 2.05 | | Token: 0x8c 935 | | | Object-Security: - 936 | | | Payload: [ { join_response }, ] 937 | | | 939 Figure 3: Example of a successful join protocol exchange. { ... } 940 denotes encryption and authentication, [ ... ] denotes 941 authentication. 943 Where join_response is as follows. 945 join_response: 946 [ 947 [ / COSE Key Set array with a single key / 948 { 949 1 : 4, / key type symmetric / 950 2 : h'01', / key id / 951 -1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value / 952 } 953 ], 954 [ 955 h'af93' / assigned short address / 956 ] 957 ] 959 Encodes to 960 h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with 961 a size of 30 bytes. 963 Authors' Addresses 965 Malisa Vucinic (editor) 966 University of Montenegro 967 Dzordza Vasingtona bb 968 Podgorica 81000 969 Montenegro 971 Email: malisav@ac.me 973 Jonathan Simon 974 Analog Devices 975 32990 Alvarado-Niles Road, Suite 910 976 Union City, CA 94587 977 USA 979 Email: jonathan.simon@analog.com 981 Kris Pister 982 University of California Berkeley 983 512 Cory Hall 984 Berkeley, CA 94720 985 USA 987 Email: pister@eecs.berkeley.edu 988 Michael Richardson 989 Sandelman Software Works 990 470 Dawson Avenue 991 Ottawa, ON K1Z5V7 992 Canada 994 Email: mcr+ietf@sandelman.ca