idnits 2.17.1 draft-ietf-6tisch-minimal-security-03.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 (June 15, 2017) is 2507 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-03 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-05 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-08 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-06 == Outdated reference: A later version (-03) exists of draft-richardson-6tisch-join-enhanced-beacon-01 == Outdated reference: A later version (-02) exists of draft-richardson-6tisch-minimal-rekey-01 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-06 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Working Group M. Vucinic, Ed. 3 Internet-Draft Inria 4 Intended status: Standards Track J. Simon 5 Expires: December 17, 2017 Linear Technology 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 June 15, 2017 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-03 15 Abstract 17 This document describes the minimal mechanisms required to support 18 secure enrollment of a pledge, a device being added to an IPv6 over 19 the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that 20 the pledge has been provisioned with a credential that is relevant to 21 the deployment - the "one-touch" scenario. The goal of this 22 configuration is to set link-layer keys, and to establish a secure 23 end-to-end session between each pledge and the join registrar who may 24 use that to further configure the pledge. Additional security 25 behaviors and mechanisms may be added on top of this minimal 26 framework. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 17, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. One-Touch Assumptions . . . . . . . . . . . . . . . . . . . . 4 65 4. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5 67 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 6 68 4.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 6 69 4.4. Step 4 - Simple Join Protocol - Join Request . . . . . . 8 70 4.5. Step 5 - Simple Join Protocol - Join Response . . . . . . 8 71 5. Architectural Overview and Communication through Join Proxy . 9 72 5.1. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . 9 73 6. Security Handshake . . . . . . . . . . . . . . . . . . . . . 10 74 7. Simple Join Protocol Specification . . . . . . . . . . . . . 11 75 7.1. OSCOAP Security Context Instantiation . . . . . . . . . . 12 76 7.2. Specification of Join Request . . . . . . . . . . . . . . 13 77 7.3. Specification of Join Response . . . . . . . . . . . . . 13 78 8. Mandatory to Implement Algorithms and Certificate Format . . 15 79 9. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 15 80 10. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 16 81 11. Key Derivations . . . . . . . . . . . . . . . . . . . . . . . 16 82 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 84 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 14.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 18 86 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 87 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 16.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 16.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 This document describes the minimal feature set for a new device, 96 termed pledge, to securely join a 6TiSCH network. As a successful 97 outcome of this process, the pledge is able to securely communicate 98 with its neighbors, participate in the routing structure of the 99 network or establish a secure session with an Internet host. 101 When a pledge seeks admission to a 6TiSCH [RFC7554] network, it first 102 needs to synchronize to the network. The pledge then configures its 103 link-local IPv6 address and authenticates itself, and also validates 104 that it is joining the right network. At this point it can expect to 105 interact with the network to configure its link-layer keying 106 material. Only then may the node establish an end-to-end secure 107 session with an Internet host using OSCOAP 108 [I-D.ietf-core-object-security] or DTLS [RFC6347]. Once the 109 application requirements are known, the node interacts with its peers 110 to request additional resources as needed, or to be reconfigured as 111 the network changes [I-D.ietf-6tisch-6top-protocol]. 113 This document presumes a network as described by [RFC7554], 114 [I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology]. 115 It assumes the pledge pre-configured with either a: 117 o pre-shared key (PSK), 119 o raw public key (RPK), 121 o or a locally-valid certificate and a trust anchor. 123 As the outcome of the join process, the pledge expects one or more 124 link-layer key(s) and optionally a temporary link-layer identifier. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. These 131 words may also appear in this document in lowercase, absent their 132 normative meanings. 134 The reader is expected to be familiar with the terms and concepts 135 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 136 [I-D.ietf-core-object-security], and 137 [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are 138 imported: pledge, join proxy, join registrar/coordinator, drop ship, 139 imprint, enrollment, ownership voucher. 141 Pledge: the prospective device, which has the identity provided to 142 at the factory. 144 Joined Node: the prospective device, after having completed the join 145 process, often just called a Node. 147 Join Proxy (JP): a stateless relay that provides connectivity 148 between the pledge and the Join Registrar/Coordinator. 150 Join Registrar/Coordinator (JRC): central entity responsible for 151 authentication and authorization of joining nodes. 153 3. One-Touch Assumptions 155 This document assumes the one-touch scenario, where devices are 156 provided with some mechanism by which a secure association may be 157 made in a controlled environment. There are many ways in which this 158 might be done, and detailing any of them is out of scope for this 159 document. But, some notion of how this might be done is important so 160 that the underlying assumptions can be reasoned about. 162 Some examples of how to do this could include: 164 o JTAG interface 166 o serial (craft) console interface 168 o pushes of physical buttons simultaneous to network attachment 170 o unsecured devices operated in a Faraday cage 172 There are likely many other ways as well. What is assumed is that 173 there can be a secure, private conversation between the Join 174 Registrar/Coordinator, and the pledge, and that the two devices can 175 exchange some trusted bytes of information. 177 4. Join Overview 179 This section describes the steps taken by a pledge in a 6TiSCH 180 network. When a previously unknown device seeks admission to a 181 6TiSCH [RFC7554] network, the following exchange occurs: 183 1. The pledge listens for an Enhanced Beacon (EB) frame 184 [IEEE8021542015]. This frame provides network synchronization 185 information, and tells the device when it can send a frame to the 186 node sending the beacons, which plays the role of Join Proxy (JP) 187 for the pledge, and when it can expect to receive a frame. 189 2. The pledge configures its link-local IPv6 address and advertizes 190 it to Join Proxy (JP). 192 3. The pledge sends packets to JP in order to securely identify 193 itself to the network. These packets are directed to the Join 194 Registrar/Coordinator (JRC), which may be co-located on the JP or 195 another device. 197 4. The pledge receives one or more packets from JRC (via the JP) 198 that sets up one or more link-layer keys used to authenticate 199 subsequent transmissions to peers. 201 From the pledge's perspective, minimal joining is a local phenomenon 202 - the pledge only interacts with the JP, and it need not know how far 203 it is from the 6LBR, or how to route to the JRC. Only after 204 establishing one or more link-layer keys does it need to know about 205 the particulars of a 6TiSCH network. 207 The handshake is shown as a transaction diagram in Figure 1: 209 +--------+ +-------+ +--------+ 210 | pledge | | JP | | JRC | 211 | | | | | | 212 +--------+ +-------+ +--------+ 213 | | | 214 |<----ENH BEACON (1)-------| | 215 | | | 216 |<-Neighbor Discovery (2)->| | 217 | | | 218 |<---Sec. Handshake (3)----|---Sec. Handshake (3a)--->| 219 | | | 220 ....................................................................... 221 . |-----Join Request (4)-----|------Join Request (4a)-->| . 222 . | | | Simple Join . 223 . |<---Join Response (5)-----|-----Join Response (5a)---| Protocol . 224 . | | | . 225 ....................................................................... 227 Figure 1: Overview of the join process. 229 The details of each step are described in the following sections. 231 4.1. Step 1 - Enhanced Beacon 233 Due to the channel hopping nature of 6TiSCH, transmissions take place 234 on physical channels in a circular fashion. For that reason, 235 Enhanced Beacons (EBs) are expected to be found by listening on a 236 single channel. However, because some channels may be blacklisted, a 237 new pledge must listen for Enhanced Beacons for a certain period on 238 each of the 16 possible channels. This search process entails having 239 the pledge keep the receiver portion of its radio active for the 240 entire period of time. 242 Once the pledge hears an EB from a JP, it synchronizes itself to the 243 joining schedule using the cells contained in the EB. The selection 244 of which beacon to start with is outside the scope of this document. 245 Implementers SHOULD make use of information such as: whether the L2 246 address of the EB has been tried before, any Network Identifier 247 [I-D.richardson-6tisch-join-enhanced-beacon] seen, and the strength 248 of the signal. The pledge can be configured with the Network 249 Identifier to seek when it is configured with the PSK. 251 Once a candidate network has been selected, the pledge can transition 252 into a low-power duty cycle, waking up only when the provided 253 schedule indicates shared slots which the pledge may use for the join 254 process. 256 At this point the pledge may proceed to step 2, or continue to listen 257 for additional EBs. 259 A pledge which receives only Enhanced Beacons containing Network ID 260 extensions [I-D.richardson-6tisch-join-enhanced-beacon] with the 261 initiate bit cleared, SHOULD NOT proceed with this protocol on that 262 network. The pledge SHOULD consider that it is in a network which 263 manages join traffic, it SHOULD switch to 264 [I-D.ietf-6tisch-dtsecurity-secure-join]. 266 4.2. Step 2 - Neighbor Discovery 268 At this point, the pledge forms its link-local IPv6 address based on 269 EUI64 and may register it at JP, in order to bootstrap the IPv6 270 neighbor tables. The Neighbor Discovery exchange shown in Figure 1 271 refers to a single round trip Neighbor Solicitation / Neighbor 272 Advertisement exchange between the pledge and the JP. The pledge may 273 further follow the Neighbor Discovery (ND) process described in 274 Section 5 of [RFC6775]. 276 4.3. Step 3 - Security Handshake 278 The security handshake between pledge and JRC uses Ephemeral Diffie- 279 Hellman over COSE (EDHOC) [I-D.selander-ace-cose-ecdhe] to establish 280 the shared session secret used to encrypt the Simple Join Protocol. 282 The security handshake step is OPTIONAL in case PSKs are used, while 283 it is REQUIRED for RPKs and certificates. 285 When using certificates, the process continues as described in 286 [I-D.selander-ace-cose-ecdhe], but MAY result in no network key being 287 returned. In that case, the pledge enters a provisional situation 288 where it provides access to an enrollment mechanism described in 289 [I-D.ietf-6tisch-dtsecurity-secure-join]. 291 If using a locally relevant certificate, the pledge will be able to 292 validate the certificate of the JRC via a local trust anchor. In 293 that case, the JRC will return networks keys as in the PSK case. 294 This would typically be the case for a device which has slept so long 295 that it no longer has valid network keys and must go through a 296 partial join process again. 298 In case the handshake step is omitted, the shared secret used for 299 protection of the Simple Join Protocol in the next step is the PSK. 301 A consequence is that if the long-term PSK is compromised, keying 302 material transferred as part of the join response is compromised as 303 well. Physical compromise of the pledge, however, would also imply 304 the compromise of the same keying material, as it is likely to be 305 found in node's memory. 307 4.3.1. Pre-Shared Symmetric Key 309 The Diffie-Hellman key exchange and the use of EDHOC is optional, 310 when using a pre-shared symmetric key. This cuts down on traffic 311 between JRC and pledge, but requires pre-configuration of the shared 312 key on both devices. 314 It is REQUIRED to use unique PSKs for each pledge. If there are 315 multiple JRCs in the network (such as for redundancy), they would 316 have to share a database of PSKs. 318 4.3.2. Asymmetric Keys 320 The Security Handshake step is required, when using asymmetric keys. 321 Before conducting the Diffie-Hellman key exchange using EDHOC 322 [I-D.selander-ace-cose-ecdhe] the pledge and JRC need to receive and 323 validate each other's public key certificate. As detailed above, 324 this can only be done for locally relevant (LDevID) certificates. 325 IDevID certificates require entering a provisional state as described 326 in [I-D.ietf-6tisch-dtsecurity-secure-join]. 328 When RPKs are pre-configured at pledge and JRC, they can directly 329 proceed to the handshake. 331 4.4. Step 4 - Simple Join Protocol - Join Request 333 The Join Request that makes part of the Simple Join Protocol is sent 334 from the pledge to the JP using the shared slot as described in the 335 EB, and forwarded to the JRC. Which slot the JP uses to transmit to 336 the JRC is out of scope: some networks may wish to dedicate specific 337 slots for this join traffic. 339 The join request is authenticated/encrypted end-to-end using an 340 algorithm from [I-D.ietf-cose-msg] and a key derived from the shared 341 secret from step 3. Algorithm negotiation is described in detail in 342 [I-D.selander-ace-cose-ecdhe], and mandatory to implement algorithms 343 are specified in Section 8. 345 The nonce is derived from the shared secret, the pledge's EUI64 and a 346 monotonically increasing counter initialized to 0 when first 347 starting. 349 4.5. Step 5 - Simple Join Protocol - Join Response 351 The Join Response that makes part of the Simple Join Protocol is sent 352 from the JRC to the pledge through JP that serves as a stateless 353 relay. Packet containing the Join Response travels on the path from 354 JRC to JP using pre-established routes in the network. The JP 355 delivers it to the pledge using the slot information from the EB. JP 356 operates as the application-layer proxy and does not keep any state 357 to relay the message. It uses information sent in the clear within 358 the join response to decide where to forward to. 360 The join response is authenticated/encrypted end-to-end using an 361 algorithm from [I-D.ietf-cose-msg] and a key derived from the shared 362 secret from step 3. 364 The nonce is derived from the shared secret, pledge's EUI64 and a 365 monotonically increasing counter matching that of the join request. 367 The join response contains one or more link-layer key(s) that the 368 pledge will use for subsequent communication. Each key that is 369 provided by the JRC is associated with an 802.15.4 key identifier. 370 In other link-layer technologies, a different identifier may be 371 substituted. Join Response optionally also contains an IEEE 802.15.4 372 short address [IEEE8021542015] assigned to pledge by JRC, and the 373 IPv6 address of the JRC. 375 5. Architectural Overview and Communication through Join Proxy 377 The protocol in Figure 1 is implemented over Constrained Application 378 Protocol (CoAP) [RFC7252]. The Pledge plays the role of a CoAP 379 client, JRC the role of a CoAP server, while JP implements CoAP 380 forward proxy functionality [RFC7252]. Since JP is also likely a 381 constrained device, it does not need to implement a cache but rather 382 process forwarding-related CoAP options and make requests on behalf 383 of pledge that is not yet part of the network. 385 The pledge communicates with a Join Proxy (JP) over link-local IPv6 386 addresses. The pledge designates a JP as a proxy by including in the 387 CoAP requests to the JP the Proxy-Scheme option with value "coap" 388 (CoAP-to-CoAP proxy). The pledge MUST include the Uri-Host option 389 with its value set to the well-known JRC's alias - "6tisch.arpa". 390 The pledge learns the actual IPv6 address of JRC from the join 391 response and it uses it once joined in order to operate as JP. The 392 initial bootstrap of the 6LBR would require explicit provisioning of 393 the JRC address. 395 5.1. Stateless-Proxy CoAP Option 397 The CoAP proxy by default keeps per-client state information in order 398 to forward the response towards the originator of the request 399 (client). This state information comprises CoAP token, but the 400 implementations also need to keep track of the IPv6 address of the 401 host, as well as the corresponding UDP source port number. In the 402 setting where the proxy is a constrained device and there are 403 potentially many clients, as in the case of JP, this makes it prone 404 to Denial of Service (DoS) attacks, due to the limited memory. 406 The Stateless-Proxy CoAP option (c.f. Figure 2) allows the proxy to 407 insert within the request the state information necessary for 408 relaying the response back to the client. Note that the proxy still 409 needs to keep some state, such as for performing congestion control 410 or request retransmission, but what is aimed with Stateless-Proxy 411 option is to free the proxy from keeping per-client state. 413 Stateless-Proxy option is critical, Safe-to-Forward, not part of the 414 cache key, not repeatable and opaque. When processed by OSCOAP, 415 Stateless-Proxy option is neither encrypted nor integrity protected. 417 +-----+---+---+---+---+-----------------+--------+--------+ 418 | No. | C | U | N | R | Name | Format | Length | 419 +-----+---+---+---+---+-----------------+--------+--------| 420 | TBD | x | | x | | Stateless-Proxy | opaque | 1-255 | 421 +-----+---+---+---+---+-----------------+--------+--------+ 422 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 424 Figure 2: Stateless-Proxy CoAP Option 426 Upon reception of a Stateless-Proxy option, the CoAP server MUST echo 427 it in the response. The value of the Stateless-Proxy option is 428 internal proxy state that is opaque to the server. Example state 429 information includes IPv6 address of the client, its UDP source port, 430 and the CoAP token. For security reasons, the state information MUST 431 be authenticated, MUST include a freshness indicator (e.g. a sequence 432 number or timestamp) and MAY be encrypted. The proxy may use an 433 appropriate COSE structure [I-D.ietf-cose-msg] to wrap the state 434 information as the value of the Stateless-Proxy option. The key used 435 for encryption/authentication of the state information may be known 436 only to the proxy. 438 Once the proxy has received the CoAP response with Stateless-Proxy 439 option present, it decrypts/authenticates it, checks the freshness 440 indicator and constructs the response for the client, based on the 441 information present in the option value. 443 Note that a CoAP proxy using the Stateless-Proxy option is not able 444 to return 5.04 Gateway Timeout error in case the request to the 445 server times out. Likewise, if the response to the proxy's request 446 does not contain the Stateless-Proxy option, for example when the 447 option is not supported by the server, the proxy is not able to 448 return the response to the client. 450 6. Security Handshake 452 In order to derive a shared session key, pledge and JRC run the EDHOC 453 protocol [I-D.selander-ace-cose-ecdhe]. During this process, pledge 454 and JRC mutually authenticate each other and verify authorization 455 information before proceeding with the Simple Join Protocol. In case 456 certificates are used for authentication, this document assumes that 457 a special certificate with role attribute set has been provisioned to 458 the JRC. This certificate is verified by pledge in order to 459 authorize JRC to continue with the join process. How such a 460 certificate is issued to the JRC is out of scope of this document. 462 Figure 3 details the exchanges between the pledge and JRC that take 463 place during the execution of the security handshake. Format of 464 EDHOC messages is specified in [I-D.selander-ace-cose-ecdhe]. The 465 handshake is initiated by the pledge. JRC may either respond with an 466 empty CoAP acknowledgment, signaling to the pledge that it needs to 467 wait, or directly with the second message of EDHOC handshake. How 468 JRC decides whether it will immediately proceed with the handshake is 469 out of scope of this document. 471 +--------+ +--------+ 472 | pledge | | JRC | 473 | | | | 474 +--------+ +--------+ 475 | | 476 | EDHOC message_1 | 477 +-------------------------------->| 478 | | 479 | Optional ACK | 480 |< - - - - - - - - - - - - - - - -+ 481 ~ ~ 482 | | 483 | EDHOC message_2 | 484 |<--------------------------------+ 485 | | 486 | EDHOC message_3 | 487 +-------------------------------->| 488 | | 490 Figure 3: Transaction diagram of the security handshake. 492 7. Simple Join Protocol Specification 494 Simple Join Protocol is a single round trip protocol (c.f. Figure 4) 495 that facilitates secure enrollment of a pledge, based on a shared 496 symmetric secret. In case the pledge was provisioned by an 497 asymmetric key (certificate or RPK), Simple Join Protocol is preceded 498 by a security handshake, described in Section 6. When the pledge is 499 provisioned with a PSK, Simple Join Protocol may be run directly. 501 Pledge and JRC MUST protect their exchange end-to-end (i.e. through 502 the proxy) using Object Security of CoAP (OSCOAP) 503 [I-D.ietf-core-object-security]. 505 +--------+ +--------+ 506 | pledge | | JRC | 507 | | | | 508 +--------+ +--------+ 509 | | 510 | Join Request | 511 +-------------------------------->| 512 | | 513 | Join Response | 514 |<--------------------------------+ 515 | | 517 Figure 4: Transaction diagram of the Simple Join Protocol. 519 7.1. OSCOAP Security Context Instantiation 521 The OSCOAP security context MUST be derived at pledge and JRC as per 522 Section 3.2 of [I-D.ietf-core-object-security] using HKDF SHA-256 523 [RFC5869] as the key derivation function. 525 o Master Secret MUST be the secret generated by the run of EDHOC as 526 per Appendix B of [I-D.selander-ace-cose-ecdhe], or the PSK in 527 case EDHOC step was omitted. 529 o Sender ID of the pledge MUST be set to the concatenation of its 530 EUI-64 and byte string 0x00. 532 o Recipient ID (ID of JRC) MUST be set to the concatenation of 533 pledge's EUI-64 and byte string 0x01. The construct uses pledge's 534 EUI-64 to avoid nonce reuse in the response in the case same PSK 535 is shared by a group of pledges. 537 o Algorithm MUST be set to the value from [I-D.ietf-cose-msg] agreed 538 by the run of EDHOC, or out-of-band in case of PSKs. 540 The derivation in [I-D.ietf-core-object-security] results in traffic 541 keys and static IVs for each side of the conversation. Nonces are 542 constructed by XOR'ing the static IV with current sequence number. 543 The context derivation process occurs exactly once. 545 Implementations MUST ensure that multiple CoAP requests to different 546 JRCs result in the use of the same OSCOAP context so that sequence 547 numbers are properly incremented for each request. This may happen 548 in a scenario where there are multiple 6TiSCH networks present and 549 the pledge tries to join one network at a time. 551 7.2. Specification of Join Request 553 Message Join Request SHALL be mapped to a CoAP request: 555 o The request method is GET. 557 o The Proxy-Scheme option is set to "coap". 559 o The Uri-Host option is set to "6tisch.arpa". 561 o The Uri-Path option is set to "j". 563 o The object security option SHALL be set according to 564 [I-D.ietf-core-object-security] and OSCOAP parameters set as 565 described above. 567 7.3. Specification of Join Response 569 If OSCOAP processing is a success and the pledge is authorized to 570 join the network, message Join Response SHALL be mapped to a CoAP 571 response: 573 o The response Code is 2.05 (Content). 575 o Content-Format option is set to application/cbor. 577 o The payload is a CBOR [RFC7049] array containing, in order: 579 * COSE Key Set, specified in [I-D.ietf-cose-msg], containing one 580 or more link-layer keys. The mapping of individual keys to 581 802.15.4-specific parameters is described in Section 7.3.1. 583 * Optional. Link layer short address that is assigned to the 584 pledge. The format of the short address follows Section 7.3.2. 586 * Optional. IPv6 address of the JRC transported as a byte 587 string. If the address of the JRC is not present in the 588 response, JRC is co-located with 6LBR. 590 payload = [ 591 COSE_KeySet, 592 ? short_address, 593 ? JRC_address : bstr, 594 ] 596 7.3.1. Link-layer Keys Transported in COSE Key Set 598 Each key in the COSE Key Set [I-D.ietf-cose-msg] SHALL be a symmetric 599 key. If "kid" parameter of the COSE Key structure is present, the 600 corresponding keys SHALL belong to an IEEE 802.15.4 KeyIdMode 0x01 601 class. In that case, parameter "kid" of COSE Key structure SHALL be 602 used to carry IEEE 802.15.4 KeyIndex value. If the "kid" parameter 603 is not present in the transported key, the application SHALL consider 604 the key to be an IEEE 802.15.4 KeyIdMode 0x00 (implicit) key. This 605 document does not support IEEE 802.15.4 KeyIdMode 0x02 and 0x03 class 606 keys. 608 7.3.2. Short Address 610 Optional "short_address" structure transported as part of the join 611 response payload represents IEEE 802.15.4 short address assigned to 612 the pledge. It is encoded as CBOR array object, containing in order: 614 o Byte string, containing the 16-bit address. 616 o Optional lease time parameter, "lease_asn". The value of the 617 "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN) 618 corresponding to its expiration, carried as a byte string in 619 network byte order. 621 short_address = [ 622 address : bstr, 623 ? lease_asn : bstr, 624 ] 626 It is up to the joined node to request a new short address before the 627 expiry of its previous address. The mechanism by which the node 628 requests renewal is the same as during join procedure, as described 629 in Section 10. The assigned short address is used for configuring 630 both Layer 2 short address and Layer 3 addresses. 632 7.3.3. Error Handling 634 In the case JRC determines that pledge is not supposed to join the 635 network (e.g. by failing to find an appropriate security context), it 636 should respond with a 4.01 Unauthorized error. Upon reception of a 637 4.01 Unauthorized, the pledge SHALL attempt to join the next 638 advertised 6TiSCH network. If all join attempts have failed at 639 pledge, the pledge SHOULD signal to the user by an out-of-band 640 mechanism the presence of an error condition. 642 In the case that the JRC determines that the pledge is not (yet) 643 authorized to join the network, but a further zero-touch process 644 might permit it, the JRC responds with a 2.05 (Content) code, but the 645 payload contains the single CBOR string "prov" (for "provisional"). 646 No link-layer keys or short address is returned. 648 This response is typically only expected when in asymmetric 649 certificate mode using 802.1AR IDevID certificates. But for reasons 650 of provisioning or device reuse, this could occur even when a one- 651 touch PSK authentication process was expected. 653 8. Mandatory to Implement Algorithms and Certificate Format 655 The mandatory to implement symmetric-key algorithm for use with 656 OSCOAP is AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. This is the 657 algorithm used in 802.15.4, and is present in hardware on many 658 platforms. With this choice, CoAP messages are therefore protected 659 with an 8-byte CCM authentication tag and the algorithm uses 13-byte 660 long nonces. 662 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. 664 Certificates or pre-configured RPKs may be used to exchange public 665 keys between the pledge and JRC. The mandatory to implement Elliptic 666 Curve is P-256, also known as secp256r1. The mandatory to implement 667 signature algorithm is ECDSA with SHA-256. 669 The certificate itself may be a compact representation of an X.509 670 certificate, or a full X.509 certificate. Compact representation of 671 X.509 certificates is out of scope of this specification. The 672 certificate is signed by a root CA whose certificate is installed on 673 all nodes participating in a particular 6TiSCH network, allowing each 674 node to validate the certificate of the JRC or pledge as appropriate. 676 9. Link-layer Requirements 678 In an operational 6TiSCH network, all frames MUST use link-layer 679 frame security. The frame security options MUST include frame 680 authentication, and MAY include frame encryption. 682 Link-layer frames are protected with a 16-byte key, and a 13-byte 683 nonce constructed from current Absolute Slot Number (ASN) and the 684 source (the JP for EBs) address, as shown in Figure 5: 686 +-------------------------------------------+ 687 | Address (8B or 00-padded 2B) | ASN (5B) | 688 +-------------------------------------------+ 690 Figure 5: Link-layer CCM* nonce construction 692 The pledge does not initially do any authentication of the EB frames, 693 as it does not know the K1 key. When sending frames, the pledge 694 sends unencrypted and unauthenticated frames. JP accepts these 695 frames (exempt mode in 802.15.4) for the duration of the join 696 process. How JP learns whether the join process is ongoing is out of 697 scope of this specification. 699 As the EB itself cannot be authenticated by pledge, an attacker may 700 craft a frame that appears to be a valid EB, since the pledge can 701 neither know the ASN a priori nor verify the address of the JP. This 702 permits a Denial of Service (DoS) attack at the pledge. Beacon 703 authentication keys are discussed in [I-D.ietf-6tisch-minimal]. 705 10. Rekeying and Rejoin 707 This protocol handles initial keying of the pledge. For reasons such 708 as rejoining after a long sleep, or expiry of the short address, the 709 joined node MAY send a new Join Request over the previously 710 established secure end-to-end session with JRC. JRC responds with 711 up-to-date keys and a short address. The node may also use the 712 Simple Join Protocol exchange for node-initiated rekeying. How node 713 learns that it should be rekeyed is out of scope. Additional work, 714 such as in [I-D.richardson-6tisch-minimal-rekey] can be used. 716 11. Key Derivations 718 When EDHOC is used to derive keys, the cost of the asymmetric 719 operation can be amortized over any additional connections that may 720 be required between the node (during or after joining) and the JRC. 722 Each application SHOULD use a unique session key. EDHOC was designed 723 with this in mind. In order to accomplish this, the EDHOC key 724 derivation algorithm can be run with a different label. Other users 725 of this key MUST define the label. 727 12. Security Considerations 729 In case PSKs are used, this document mandates that the pledge and JRC 730 are pre-configured with unique keys. The uniqueness of generated 731 nonces is guaranteed under the assumption of unique EUI64 identifiers 732 for each pledge. Note that the address of the JRC does not take part 733 in nonce construction. Therefore, even should an error occur, and a 734 PSK shared by a group of nodes, the nonces constructed as part of the 735 different responses are unique. The PSK is still important for 736 authentication of the pledge and authentication of the JRC to the 737 pledge. Should an attacker come to know the PSK, then a man-in-the- 738 middle attack is possible. The well known problem with Bluetooth 739 headsets with a "0000" pin applies here. The design differentiates 740 between nonces constructed for requests and nonces constructed for 741 responses by different sender identifiers (0x00 for pledge and 0x01 742 for JRC). 744 Being a stateless relay, JP blindly forwards the join traffic into 745 the network. While the exchange between pledge and JP takes place 746 over a shared cell, join traffic is forwarded using dedicated cells 747 on the JP to JRC path. In case of distributed scheduling, the join 748 traffic may therefore cause intermediate nodes to request additional 749 bandwidth. (EDNOTE: this is a problem that needs to be solved) 750 Because the relay operation of JP is implemented at the application 751 layer, JP is the only hop on the JP-6LBR path that can distinguish 752 join traffic from regular IP traffic in the network. It is therefore 753 recommended to implement stateless rate limiting at JP: a simple 754 bandwidth (in bytes or packets/second) cap would be appropriate. 756 The shared nature of the "minimal" cell used for join traffic makes 757 the network prone to DoS attacks by congesting the JP with bogus 758 radio traffic. As such an attacker is limited by emitted radio 759 power, redundancy in the number of deployed JPs alleviates the issue 760 and also gives the pledge a possibility to use the best available 761 link for join. How a network node decides to become a JP is out of 762 scope of this specification. 764 At the time of the join, the pledge has no means of verifying the 765 content in the EB and has to accept it at "face value". In case the 766 pledge tries to join an attacker's network, the join response message 767 in such cases will either fail the security check or time out. The 768 pledge may implement a blacklist in order to filter out undesired 769 beacons and try to join the next seemingly valid network. The 770 blacklist alleviates the issue but is effectively limited by the 771 node's available memory. Such bogus beacons will prolong the join 772 time of the pledge and so the time spent in "minimal" 773 [I-D.ietf-6tisch-minimal] duty cycle mode. 775 13. Privacy Considerations 777 This specification relies on the uniqueness of EUI64 that is 778 transferred in clear as part of the security context identifier. 779 (EDNOTE: should we say IID here?) Privacy implications of using such 780 long-term identifier are discussed in [RFC7721] and comprise 781 correlation of activities over time, location tracking, address 782 scanning and device-specific vulnerability exploitation. Since the 783 join protocol is executed rarely compared to the network lifetime, 784 long-term threats that arise from using EUI64 are minimal. In 785 addition, the join response message contains an optional short 786 address which can be assigned by JRC to the pledge. The short 787 address is independent of the long-term identifier EUI64 and is 788 encrypted in the response. For that reason, it is not possible to 789 correlate the short address with the EUI64 used during the join. Use 790 of short addresses once the join protocol completes mitigates the 791 aforementioned privacy risks. In addition, EDHOC may be used for 792 identity protection during the join protocol by generating a random 793 context identifier in place of the EUI64 794 [I-D.selander-ace-cose-ecdhe]. 796 14. IANA Considerations 798 Note to RFC Editor: Please replace all occurrences of "[[this 799 document]]" with the RFC number of this specification. 801 This document allocates a well-known name under the .arpa name space 802 according to the rules given in: [RFC3172]. The name "6tisch.arpa" 803 is requested. No subdomains are expected. No A, AAAA or PTR record 804 is requested. 806 14.1. CoAP Option Numbers Registry 808 The Stateless-Proxy option is added to the CoAP Option Numbers 809 registry: 811 +--------+-----------------+-------------------+ 812 | Number | Name | Reference | 813 +--------+-----------------+-------------------+ 814 | TBD | Stateless-Proxy | [[this document]] | 815 +--------+-----------------+-------------------+ 817 15. Acknowledgments 819 The work on this document has been partially supported by the 820 European Union's H2020 Programme for research, technological 821 development and demonstration under grant agreement No 644852, 822 project ARMOUR. 824 The authors are grateful to Thomas Watteyne and Goeran Selander for 825 reviewing the draft and to Klaus Hartke for providing input on the 826 Stateless-Proxy CoAP option. The authors would also like to thank 827 Francesca Palombini and Ludwig Seitz for participating in the 828 discussions that have helped shape the document. 830 16. References 831 16.1. Normative References 833 [I-D.ietf-core-object-security] 834 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 835 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 836 object-security-03 (work in progress), May 2017. 838 [I-D.ietf-cose-msg] 839 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 840 draft-ietf-cose-msg-24 (work in progress), November 2016. 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, 844 DOI 10.17487/RFC2119, March 1997, 845 . 847 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 848 Requirements for the Address and Routing Parameter Area 849 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 850 September 2001, . 852 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 853 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 854 October 2013, . 856 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 857 Application Protocol (CoAP)", RFC 7252, 858 DOI 10.17487/RFC7252, June 2014, 859 . 861 16.2. Informative References 863 [I-D.ietf-6tisch-6top-protocol] 864 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol 865 (6P)", draft-ietf-6tisch-6top-protocol-05 (work in 866 progress), May 2017. 868 [I-D.ietf-6tisch-dtsecurity-secure-join] 869 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 870 6tisch-dtsecurity-secure-join-01 (work in progress), 871 February 2017. 873 [I-D.ietf-6tisch-minimal] 874 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 875 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 876 in progress), February 2017. 878 [I-D.ietf-6tisch-terminology] 879 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 880 "Terminology in IPv6 over the TSCH mode of IEEE 881 802.15.4e", draft-ietf-6tisch-terminology-08 (work in 882 progress), December 2016. 884 [I-D.ietf-anima-bootstrapping-keyinfra] 885 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 886 S., and K. Watsen, "Bootstrapping Remote Secure Key 887 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 888 keyinfra-06 (work in progress), May 2017. 890 [I-D.richardson-6tisch-join-enhanced-beacon] 891 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 892 Element encapsulation of 6tisch Join Information", draft- 893 richardson-6tisch-join-enhanced-beacon-01 (work in 894 progress), March 2017. 896 [I-D.richardson-6tisch-minimal-rekey] 897 Richardson, M., "Minimal Security rekeying mechanism for 898 6TiSCH", draft-richardson-6tisch-minimal-rekey-01 (work in 899 progress), February 2017. 901 [I-D.selander-ace-cose-ecdhe] 902 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 903 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 904 cose-ecdhe-06 (work in progress), April 2017. 906 [IEEE8021542015] 907 IEEE standard for Information Technology, ., "IEEE Std 908 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 909 Networks (WPANs)", 2015. 911 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 912 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 913 RFC 4231, DOI 10.17487/RFC4231, December 2005, 914 . 916 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 917 Key Derivation Function (HKDF)", RFC 5869, 918 DOI 10.17487/RFC5869, May 2010, 919 . 921 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 922 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 923 January 2012, . 925 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 926 Bormann, "Neighbor Discovery Optimization for IPv6 over 927 Low-Power Wireless Personal Area Networks (6LoWPANs)", 928 RFC 6775, DOI 10.17487/RFC6775, November 2012, 929 . 931 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 932 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 933 Internet of Things (IoT): Problem Statement", RFC 7554, 934 DOI 10.17487/RFC7554, May 2015, 935 . 937 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 938 Considerations for IPv6 Address Generation Mechanisms", 939 RFC 7721, DOI 10.17487/RFC7721, March 2016, 940 . 942 Appendix A. Example 944 Figure 6 illustrates a join protocol exchange in case PSKs are used. 945 Pledge instantiates the OSCOAP context and derives the traffic keys 946 and nonces from the PSK. It uses the instantiated context to protect 947 the CoAP request addressed with Proxy-Scheme option and well-known 948 host name of JRC in the Uri-Host option. Triggered by the presence 949 of Proxy-Scheme option, JP forwards the request to the JRC and adds 950 the Stateless-Proxy option with value set to the internally needed 951 state, authentication tag, and a freshness indicator. JP learned the 952 IPv6 address of JRC when it acted as a pledge and joined the network. 953 Once JRC receives the request, it looks up the correct context based 954 on the Sender ID (sid) parameter. It reconstructs OSCOAP's external 955 Additional Authenticated Data (AAD) needed for verification based on: 957 o Version field of the received CoAP header. 959 o Code field of the received CoAP header. 961 o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. 963 o Request ID being set to pledge's EUI-64 concatenated with 0x00. 965 o Request Sequence number set to the value of "Partial IV" of the 966 received COSE object. 968 Replay protection is ensured by OSCOAP and the tracking of sequence 969 numbers at each side. In the example below, the response contains 970 sequence number 7 meaning that there have already been some attempts 971 to join under a given context, not coming from the pledge. Once JP 972 receives the response, it authenticates the Stateless-Proxy option 973 before deciding where to forward. JP sets its internal state to that 974 found in the Stateless-Proxy option. Note that JP does not posses 975 the key to decrypt the COSE object present in the payload so the 976 join_response object is opaque to it. The response is matched to the 977 request and verified for replay protection at pledge using OSCOAP 978 processing rules. The response does not contain JRC's address as in 979 this particular example, we assume that JRC is co-located with 6LBR. 981 <--E2E OSCOAP--> 982 Client Proxy Server 983 Pledge JP JRC 984 | | | 985 +----->| | Code: [0.01] (GET) 986 | GET | | Token: 0x8c 987 | | | Proxy-Scheme: [coap] 988 | | | Uri-Host: [6tisch.arpa] 989 | | | Object-Security: [sid:EUI-64 | 0, seq:1, 990 | | | {Uri-Path:"j"}, 991 | | | ] 992 | | | Payload: - 993 | | | 994 | +----->| Code: [0.01] (GET) 995 | | GET | Token: 0x7b 996 | | | Uri-Host: [6tisch.arpa] 997 | | | Object-Security: [sid:EUI-64 | 0, seq:1, 998 | | | {Uri-Path:"j"}, 999 | | | ] 1000 | | | Stateless-Proxy: opaque state 1001 | | | Payload: - 1002 | | | 1003 | |<-----+ Code: [2.05] (Content) 1004 | | 2.05 | Token: 0x7b 1005 | | | Object-Security: - 1006 | | | Stateless-Proxy: opaque state 1007 | | | Payload: [ seq:7, 1008 | | | {join_response}, ] 1009 | | | 1010 |<-----+ | Code: [2.05] (Content) 1011 | 2.05 | | Token: 0x8c 1012 | | | Object-Security: - 1013 | | | Payload: [ seq:7, 1014 | | | {join_response}, ] 1015 | | | 1017 Figure 6: Example of a join protocol exchange with a PSK. {} denotes 1018 encryption and authentication, [] denotes authentication. 1020 Where join_response is as follows. 1022 join_response: 1023 [ 1024 [ / COSE Key Set array with a single key / 1025 { 1026 1 : 4, / key type symmetric / 1027 2 : h'01', / key id / 1028 -1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value / 1029 } 1030 ], 1031 [ 1032 h'af93' / assigned short address / 1033 ] 1034 ] 1036 Encodes to 1037 h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with 1038 a size of 30 bytes. 1040 Authors' Addresses 1042 Malisa Vucinic (editor) 1043 Inria 1044 2 Rue Simone Iff 1045 Paris 75012 1046 France 1048 Email: malisa.vucinic@inria.fr 1050 Jonathan Simon 1051 Linear Technology 1052 32990 Alvarado-Niles Road, Suite 910 1053 Union City, CA 94587 1054 USA 1056 Email: jsimon@linear.com 1058 Kris Pister 1059 University of California Berkeley 1060 512 Cory Hall 1061 Berkeley, CA 94720 1062 USA 1064 Email: pister@eecs.berkeley.edu 1065 Michael Richardson 1066 Sandelman Software Works 1067 470 Dawson Avenue 1068 Ottawa, ON K1Z5V7 1069 Canada 1071 Email: mcr+ietf@sandelman.ca