idnits 2.17.1 draft-ietf-6tisch-minimal-security-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2017) is 2601 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-01 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-03 == 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-04 == 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-04 -- 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 3 Internet-Draft Inria 4 Intended status: Standards Track J. Simon 5 Expires: September 13, 2017 Linear Technology 6 K. Pister 7 University of California Berkeley 8 M. Richardson 9 Sandelman Software Works 10 March 12, 2017 12 Minimal Security Framework for 6TiSCH 13 draft-ietf-6tisch-minimal-security-02 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 September 13, 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 . 8 72 5.1. Stateless-Proxy CoAP Option . . . . . . . . . . . . . . . 9 73 6. Security Handshake . . . . . . . . . . . . . . . . . . . . . 10 74 6.1. Discovery Message . . . . . . . . . . . . . . . . . . . . 11 75 7. Simple Join Protocol Specification . . . . . . . . . . . . . 11 76 7.1. OSCOAP Security Context Instantiation . . . . . . . . . . 12 77 7.2. Specification of Join Request . . . . . . . . . . . . . . 13 78 7.3. Specification of Join Response . . . . . . . . . . . . . 13 79 8. Link-layer Requirements . . . . . . . . . . . . . . . . . . . 15 80 9. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 15 81 10. Rekeying and Rejoin . . . . . . . . . . . . . . . . . . . . . 16 82 11. Key Derivations . . . . . . . . . . . . . . . . . . . . . . . 16 83 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 85 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 14.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 18 87 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 16.2. Informative References . . . . . . . . . . . . . . . . . 19 91 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 94 1. Introduction 96 This document describes the minimal feature set for a new device, 97 termed pledge, to securely join a 6TiSCH network. As a successful 98 outcome of this process, the pledge is able to securely communicate 99 with its neighbors, participate in the routing structure of the 100 network or establish a secure session with an Internet host. 102 When a pledge seeks admission to a 6TiSCH [RFC7554] network, it first 103 needs to synchronize to the network. The pledge then configures its 104 link-local IPv6 address and authenticates itself, and also validates 105 that it is joining the right network. At this point it can expect to 106 interact with the network to configure its link-layer keying 107 material. Only then may the node establish an end-to-end secure 108 session with an Internet host using OSCOAP 109 [I-D.ietf-core-object-security] or DTLS [RFC6347]. Once the 110 application requirements are known, the node interacts with its peers 111 to request additional resources as needed, or to be reconfigured as 112 the network changes [I-D.ietf-6tisch-6top-protocol]. 114 This document presumes a network as described by [RFC7554], 115 [I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology]. 116 It assumes the pledge pre-configured with either a: 118 o pre-shared key (PSK), 120 o raw public key (RPK), 122 o or a locally-valid certificate and a trust anchor. 124 As the outcome of the join process, the pledge expects one or more 125 link-layer key(s) and optionally a temporary network identifier. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. These 132 words may also appear in this document in lowercase, absent their 133 normative meanings. 135 The reader is expected to be familiar with the terms and concepts 136 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 137 [I-D.ietf-core-object-security], and 138 [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are 139 imported: pledge, join proxy, join registrar/coordinator, drop ship, 140 imprint, enrollment, ownership voucher. 142 Pledge: the prospective device, which has the identity provided to 143 at the factory. 145 Joined Node: the prospective device, after having completed the join 146 process, often just called a Node. 148 Join Proxy (JP): a stateless relay that provides connectivity 149 between the pledge and the join registrar/coordinator. 151 Join Registrar/Coordinator (JRC): central entity responsible for 152 authentication and authorization of joining nodes. 154 3. One-Touch Assumptions 156 This document assumes the one-touch scenario, where devices are 157 provided with some mechanism by which a secure association may be 158 made in a controlled environment. There are many ways in which this 159 might be done, and detailing any of them is out of scope for this 160 document. But, some notion of how this might be done is important so 161 that the underlying assumptions can be reasoned about. 163 Some examples of how to do this could include: 165 o JTAG interface 167 o serial (craft) console interface 169 o pushes of physical buttons simultaneous to network attachment 171 o unsecured devices operated in a Faraday cage 173 There are likely many other ways as well. What is assumed is that 174 there can be a secure, private conversation between the Join 175 Registrar/Coordinator, and the pledge, and that the two devices can 176 exchange some trusted bytes of information. 178 4. Join Overview 180 This section describes the steps taken by a pledge in a 6TiSCH 181 network. When a previously unknown device seeks admission to a 182 6TiSCH [RFC7554] network, the following exchange occurs: 184 1. The pledge listens for an Enhanced Beacon (EB) frame 185 [IEEE8021542015]. This frame provides network synchronization 186 information, and tells the device when it can send a frame to the 187 node sending the beacons, which plays the role of Join Proxy (JP) 188 for the pledge, and when it can expect to receive a frame. 190 2. The pledge configures its link-local IPv6 address and advertizes 191 it to Join Proxy (JP). 193 3. The pledge sends packets to JP in order to securely identify 194 itself to the network. These packets are directed to the Join 195 Registrar/Coordinator (JRC), which may be co-located on the JP or 196 another device. 198 4. The pledge receives one or more packets from JRC (via the JP) 199 that sets up one or more link-layer keys used to authenticate 200 subsequent transmissions to peers. 202 From the pledge's perspective, minimal joining is a local phenomenon 203 - the pledge only interacts with the JP, and it need not know how far 204 it is from the DAG root, or how to route to the JRC. Only after 205 establishing one or more link-layer keys does it need to know about 206 the particulars of a 6TiSCH network. 208 The handshake is shown as a transaction diagram in Figure 1: 210 +--------+ +-------+ +--------+ 211 | pledge | | JP | | JRC | 212 | | | | | | 213 +--------+ +-------+ +--------+ 214 | | | 215 |<----ENH BEACON (1)-------| | 216 | | | 217 |<-Neighbor Discovery (2)->| | 218 | | | 219 |<---Sec. Handshake (3)----|---Sec. Handshake (3a)--->| 220 | | | 221 ....................................................................... 222 . |-----Join Request (4)-----|------Join Request (4a)-->| . 223 . | | | Simple Join . 224 . |<---Join Response (5)-----|-----Join Response (5a)---| Protocol . 225 . | | | . 226 ....................................................................... 228 Figure 1: Overview of the join process. 230 The details of each step are described in the following sections. 232 4.1. Step 1 - Enhanced Beacon 234 Due to the channel hopping nature of 6TiSCH, transmissions take place 235 on physical channels in a circular fashion. For that reason, 236 Enhanced Beacons (EBs) are expected to be found by listening on a 237 single channel. However, because some channels may be blacklisted, a 238 new pledge must listen for Enhanced Beacons for a certain period on 239 each of the 16 possible channels. This search process entails having 240 the pledge keep the receiver portion of its radio active for the 241 entire period of time. 243 Once the pledge hears an EB from a JP, it synchronizes itself to the 244 joining schedule using the cells contained in the EB. The selection 245 of which beacon to start with is outside the scope of this document. 246 Implementers SHOULD make use of information such as: whether the L2 247 address of the EB has been tried before, any Network Identifier 248 [I-D.richardson-6tisch-join-enhanced-beacon] seen, and the strength 249 of the signal. The pledge can be configured with the Network 250 Identifier to seek when it is configured with the PSK. 252 Once a candidate network has been selected, the pledge can transition 253 into a low-power duty cycle, waking up only when the provided 254 schedule indicates shared slots which the pledge may use for the join 255 process. 257 At this point the pledge may proceed to step 2, or continue to listen 258 for additional EBs. 260 A pledge which receives only Enhanced Beacons containing Network ID 261 extensions [I-D.richardson-6tisch-join-enhanced-beacon] with the 262 initiate bit cleared, SHOULD NOT proceed with this protocol on that 263 network. The pledge SHOULD consider that it is in a network which 264 manages join traffic, it SHOULD switch to 265 [I-D.ietf-6tisch-dtsecurity-secure-join]. 267 4.2. Step 2 - Neighbor Discovery 269 At this point, the pledge forms its link-local IPv6 address based on 270 EUI64 and may register it at JP, in order to bootstrap the IPv6 271 neighbor tables. The Neighbor Discovery exchange shown in Figure 1 272 refers to a single round trip Neighbor Solicitation / Neighbor 273 Advertisement exchange between the pledge and the JP. The pledge may 274 further follow the Neighbor Discovery (ND) process described in 275 Section 5 of [RFC6775]. 277 4.3. Step 3 - Security Handshake 279 The security handshake between pledge and JRC uses Ephemeral Diffie- 280 Hellman over COSE (EDHOC) [I-D.selander-ace-cose-ecdhe] to establish 281 the shared session secret used to encrypt the Simple Join Protocol. 283 The security handshake step is OPTIONAL in case PSKs are used, while 284 it is REQUIRED for RPKs and certificates. 286 When using certificates, the process continues as described in 287 [I-D.selander-ace-cose-ecdhe], but MAY result in no network key being 288 returned. In that case, the pledge enters a provisional situation 289 where it provides access to an enrollment mechanism described in 290 [I-D.ietf-6tisch-dtsecurity-secure-join]. 292 If using a locally relevant certificate, the pledge will be able to 293 validate the certificate of the JRC via a local trust anchor. In 294 that case, the JRC will return networks keys as in the PSK case. 295 This would typically be the case for a device which has slept so long 296 that it no longer has valid network keys and must go through a 297 partial join process again. 299 In case the handshake step is omitted, the shared secret used for 300 protection of the Simple Join Protocol in the next step is the PSK. 302 A consequence is that if the long-term PSK is compromised, keying 303 material transferred as part of the join response is compromised as 304 well. Physical compromise of the pledge, however, would also imply 305 the compromise of the same keying material, as it is likely to be 306 found in node's memory. 308 4.3.1. Pre-Shared Symmetric Key 310 The Diffie-Hellman key exchange and the use of EDHOC is optional, 311 when using a pre-shared symmetric key. This cuts down on traffic 312 between JRC and pledge, but requires pre-configuration of the shared 313 key on both devices. 315 It is REQUIRED to use unique PSKs for each pledge. If there are 316 multiple JRCs in the network (such as for redundancy), they would 317 have to share a database of PSKs. 319 4.3.2. Asymmetric Keys 321 The Security Handshake step is required, when using asymmetric keys. 322 Before conducting the Diffie-Hellman key exchange using EDHOC 323 [I-D.selander-ace-cose-ecdhe] the pledge and JRC need to receive and 324 validate each other's public key certificate. As detailed above, 325 this can only be done for locally relevant (LDevID) certificates. 326 IDevID certificates require entering a provisional state as described 327 in [I-D.ietf-6tisch-dtsecurity-secure-join]. 329 When RPKs are pre-configured at pledge and JRC, they can directly 330 proceed to the handshake. 332 4.4. Step 4 - Simple Join Protocol - Join Request 334 The Join Request that makes part of the Simple Join Protocol is sent 335 from the pledge to the JP using the shared slot as described in the 336 EB, and forwarded to the JRC. Which slot the JP uses to transmit to 337 the JRC is out of scope: some networks may wish to dedicate specific 338 slots for this join traffic. 340 The join request is typically authenticated/encrypted end-to-end 341 using AES-CCM-16-64-128 algorithm from [I-D.ietf-cose-msg] and a key 342 derived from the shared secret from step 3. Algorithm negotiation is 343 described in detail in [I-D.selander-ace-cose-ecdhe]. 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 typically authenticated/encrypted using AES-CCM- 361 16-64-128 algorithm from [I-D.ietf-cose-msg] and a key derived from 362 the shared 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. 374 5. Architectural Overview and Communication through Join Proxy 376 The protocol in Figure 1 is implemented over Constrained Application 377 Protocol (CoAP) [RFC7252]. The Pledge plays the role of a CoAP 378 client, JRC the role of a CoAP server, while JP implements CoAP 379 forward proxy functionality [RFC7252]. Since JP is also likely a 380 constrained device, it does not need to implement a cache but rather 381 process forwarding-related CoAP options and make requests on behalf 382 of pledge that is not yet part of the network. 384 The pledge communicates with a Join Proxy (JP) over link-local IPv6 385 addresses. The pledge designates a JP as a proxy by including in the 386 CoAP requests to the JP the Proxy-Scheme option with value "coap" 387 (CoAP-to-CoAP proxy). The pledge MUST include the Uri-Host option 388 with its value set to the well-known JRC's alias - "6tisch.arpa". 389 The pledge does not need to learn the actual IPv6 address of JRC at 390 any time during the join protocol. The JP knows the address of the 391 JRC, via a provisioning process that occured when the JP, acting as a 392 pledge, joined. The initial bootstrap of the DODAG root would 393 require explicit provisioning of 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]. 466 +--------+ +--------+ 467 | pledge | | JRC | 468 | | | | 469 +--------+ +--------+ 470 | Discovery Message | 471 +-------------------------------->| 472 | | 473 | Optional ACK | 474 |< - - - - - - - - - - - - - - - -+ 475 | | 476 | | 477 | EDHOC message_1 | 478 |<--------------------------------+ 479 | | 480 | EDHOC message_2 | 481 +-------------------------------->| 482 | | 483 | EDHOC message_3 | 484 |<--------------------------------+ 485 | | 487 Figure 3: Transaction diagram of the security handshake. 489 6.1. Discovery Message 491 Pledge triggers the security handshake by sending a discovery message 492 to the JRC. This initial message does not make part of the EDHOC 493 handshake. JRC is the initiator of the EDHOC run and is able to 494 schedule the execution of many concurrent enrollments at will by 495 acknowledging the request and sending a separate, delayed response. 496 The Discovery Message SHALL be mapped to a CoAP request: 498 o The request method is POST. 500 o The Proxy-Scheme option is set to "coap". 502 o The Uri-Host option is set to "6tisch.arpa". 504 o The Uri-Path option is set to "edhoc". 506 o The payload is optional and contains pledge's EUI-64. 508 7. Simple Join Protocol Specification 510 Simple Join Protocol is a single round trip protocol (c.f. Figure 4) 511 that facilitates secure enrollment of a pledge, based on a shared 512 symmetric secret. In case the pledge was provisioned by an 513 asymmetric key (certificate or RPK), Simple Join Protocol is preceded 514 by a security handshake, described in Section 6. When the pledge is 515 provisioned with a PSK, Simple Join Protocol may be run directly. 517 Pledge and JRC MUST protect their exchange end-to-end (i.e. through 518 the proxy) using Object Security of CoAP (OSCOAP) 519 [I-D.ietf-core-object-security]. 521 +--------+ +--------+ 522 | pledge | | JRC | 523 | | | | 524 +--------+ +--------+ 525 | | 526 | Join Request | 527 +-------------------------------->| 528 | | 529 | Join Response | 530 |<--------------------------------+ 531 | | 533 Figure 4: Transaction diagram of the Simple Join Protocol. 535 7.1. OSCOAP Security Context Instantiation 537 The OSCOAP security context MUST be derived at pledge and JRC as per 538 Section 3.2 of [I-D.ietf-core-object-security] using HKDF [RFC5869] 539 as the key derivation function. 541 o Master Secret MUST be the secret generated by the run of EDHOC as 542 per Appendix B of [I-D.selander-ace-cose-ecdhe], or the PSK in 543 case EDHOC step was omitted. 545 o Sender ID of the pledge MUST be set to the concatenation of its 546 EUI-64 and byte string 0x00. 548 o Recipient ID (ID of JRC) MUST be set to the concatenation of 549 pledge's EUI-64 and byte string 0x01. The construct uses pledge's 550 EUI-64 to avoid nonce reuse in the response in the case same PSK 551 is shared by a group of pledges. 553 o Algorithm MUST be set to AES-CCM-16-64-128 from 554 [I-D.ietf-cose-msg]. CoAP messages are therefore protected with 555 an 8-byte CCM authentication tag and the algorithm uses 13-byte 556 long nonces. 558 The hash algorithm that instantiates HKDF MUST be SHA-256 [RFC4231]. 559 The derivation in [I-D.ietf-core-object-security] results in traffic 560 keys and static IVs for each side of the conversation. Nonces are 561 constructed by XOR'ing the static IV with current sequence number. 562 The context derivation process occurs exactly once. 564 Implementations MUST ensure that multiple CoAP requests to different 565 JRCs result in the use of the same OSCOAP context so that sequence 566 numbers are properly incremented for each request. This may happen 567 in a scenario where there are multiple 6TiSCH networks present and 568 the pledge tries to join one network at a time. 570 7.2. Specification of Join Request 572 Message Join Request SHALL be mapped to a CoAP request: 574 o The request method is GET. 576 o The Proxy-Scheme option is set to "coap". 578 o The Uri-Host option is set to "6tisch.arpa". 580 o The Uri-Path option is set to "j". 582 o The object security option SHALL be set according to 583 [I-D.ietf-core-object-security] and OSCOAP parameters set as 584 described above. 586 7.3. Specification of Join Response 588 If OSCOAP processing is a success and the pledge is authorized to 589 join the network, message Join Response SHALL be mapped to a CoAP 590 response: 592 o The response Code is 2.05 (Content). 594 o Content-Format option is set to application/cbor. 596 o The payload is a CBOR [RFC7049] array containing, in order: 598 * COSE Key Set, specified in [I-D.ietf-cose-msg], containing one 599 or more link-layer keys. The mapping of individual keys to 600 802.15.4-specific parameters is described in Section 7.3.1. 602 * Optional short address that is assigned to the pledge. The 603 format of the short address follows Section 7.3.2. 605 payload = [ 606 COSE_KeySet, 607 ? short_address, 608 ] 610 7.3.1. Link-layer Keys Transported in COSE Key Set 612 Each key in the COSE Key Set [I-D.ietf-cose-msg] SHALL be a symmetric 613 key. If "kid" parameter of the COSE Key structure is present, the 614 corresponding keys SHALL belong to an IEEE 802.15.4 KeyIdMode 0x01 615 class. In that case, parameter "kid" of COSE Key structure SHALL be 616 used to carry IEEE 802.15.4 KeyIndex value. If the "kid" parameter 617 is not present in the transported key, the application SHALL consider 618 the key to be an IEEE 802.15.4 KeyIdMode 0x00 (implicit) key. This 619 document does not support IEEE 802.15.4 KeyIdMode 0x02 and 0x03 class 620 keys. 622 7.3.2. Short Address 624 Optional "short_address" structure transported as part of the join 625 response payload represents IEEE 802.15.4 short address assigned to 626 the pledge. It is encoded as CBOR array object, containing in order: 628 o Byte string, containing the 16-bit address. 630 o Optional lease time parameter, "lease_asn". The value of the 631 "lease_asn" parameter is the 5-byte Absolute Slot Number (ASN) 632 corresponding to its expiration, carried as a byte string in 633 network byte order. 635 short_address = [ 636 address : bstr, 637 ? lease_asn : bstr, 638 ] 640 It is up to the joined node to request a new short address before the 641 expiry of its previous address. The mechanism by which the node 642 requests renewal is the same as during join procedure, as described 643 in Section 10. The assigned short address is used for configuring 644 both Layer 2 short address and Layer 3 addresses. 646 7.3.3. Error Handling 648 In the case JRC determines that pledge is not supposed to join the 649 network (e.g. by failing to find an appropriate security context), it 650 should respond with a 4.01 Unauthorized error. Upon reception of a 651 4.01 Unauthorized, the pledge SHALL attempt to join the next 652 advertised 6TiSCH network. If all join attempts have failed at 653 pledge, the pledge SHOULD signal to the user by an out-of-band 654 mechanism the presence of an error condition. 656 In the case that the JRC determines that the pledge is not (yet) 657 authorized to join the network, but a further zero-touch process 658 might permit it, the JRC responds with a 2.05 (Content) code, but the 659 payload contains the single CBOR string "prov" (for "provisional"). 660 No link-layer keys or short address is returned. 662 This response is typically only expected when in asymmetric 663 certificate mode using 802.1AR IDevID certificates. But for reasons 664 of provisioning or device reuse, this could occur even when a one- 665 touch PSK authentication process was expected. 667 8. Link-layer Requirements 669 In an operational 6TiSCH network, all frames MUST use link-layer 670 frame security. The frame security options MUST include frame 671 authentication, and MAY include frame encryption. 673 Link-layer frames are protected with a 16-byte key, and a 13-byte 674 nonce constructed from current Absolute Slot Number (ASN) and the 675 source (the JP for EBs) address, as shown in Figure 5: 677 +-------------------------------------------+ 678 | Address (8B or 00-padded 2B) | ASN (5B) | 679 +-------------------------------------------+ 681 Figure 5: Link-layer CCM* nonce construction 683 The pledge does not initially do any authentication of the EB frames, 684 as it does not know the K1 key. When sending frames, the pledge 685 sends unencrypted and unauthenticated frames. JP accepts these 686 frames (exempt mode in 802.15.4) for the duration of the join 687 process. How JP learns whether the join process is ongoing is out of 688 scope of this specification. 690 As the EB itself cannot be authenticated by pledge, an attacker may 691 craft a frame that appears to be a valid EB, since the pledge can 692 neither know the ASN a priori nor verify the address of the JP. This 693 permits a Denial of Service (DoS) attack at the pledge. Beacon 694 authentication keys are discussed in [I-D.ietf-6tisch-minimal]. 696 9. Asymmetric Keys 698 Certificates or pre-configured RPKs may be used to exchange public 699 keys between the pledge and JRC. The key pair is generated using 700 elliptic curve secp256r1, and the certificate containing the public 701 key is signed using ECDSA. (XXX: would be nice to move to EdDSA) 703 The certificate itself may be a compact representation of an X.509 704 certificate, or a full X.509 certificate. Compact representation of 705 X.509 certificates is out of scope of this specification. The 706 certificate is signed by a root CA whose certificate is installed on 707 all nodes participating in a particular 6TiSCH network, allowing each 708 node to validate the certificate of the JRC or pledge as appropriate. 710 10. Rekeying and Rejoin 712 This protocol handles initial keying of the pledge. For reasons such 713 as rejoining after a long sleep, or expiry of the short address, the 714 joined node MAY send a new Join Request over the previously 715 established secure end-to-end session with JRC. JRC responds with 716 up-to-date keys and a short address. The node may also use the 717 Simple Join Protocol exchange for node-initiated rekeying. How node 718 learns that it should be rekeyed is out of scope. Additional work, 719 such as in [I-D.richardson-6tisch-minimal-rekey] can be used. 721 11. Key Derivations 723 When EDHOC is used to derive keys, the cost of the asymmetric 724 operation can be amortized over any additional connections that may 725 be required between the node (during or after joining) and the JRC. 727 Each application SHOULD use a unique session key. EDHOC was designed 728 with this in mind. In order to accomplish this, the EDHOC key 729 derivation algorithm can be run with a different label. Other users 730 of this key MUST define the label. 732 12. Security Considerations 734 In case PSKs are used, this document mandates that the pledge and JRC 735 are pre-configured with unique keys. The uniqueness of generated 736 nonces is guaranteed under the assumption of unique EUI64 identifiers 737 for each pledge. Note that the address of the JRC does not take part 738 in nonce construction. Therefore, even should an error occur, and a 739 PSK shared by a group of nodes, the nonces constructed as part of the 740 different responses are unique. The PSK is still important for 741 authentication of the pledge and authentication of the JRC to the 742 pledge. Should an attacker come to know the PSK, then a man-in-the- 743 middle attack is possible. The well known problem with Bluetooth 744 headsets with a "0000" pin applies here. The design differentiates 745 between nonces constructed for requests and nonces constructed for 746 responses by different sender identifiers (0x00 for pledge and 0x01 747 for JRC). 749 Being a stateless relay, JP blindly forwards the join traffic into 750 the network. While the exchange between pledge and JP takes place 751 over a shared cell, join traffic is forwarded using dedicated cells 752 on the JP to JRC path. In case of distributed scheduling, the join 753 traffic may therefore cause intermediate nodes to request additional 754 bandwidth. (EDNOTE: this is a problem that needs to be solved) 755 Because the relay operation of JP is implemented at the application 756 layer, JP is the only hop on the JP-6LBR path that can distinguish 757 join traffic from regular IP traffic in the network. It is therefore 758 recommended to implement stateless rate limiting at JP: a simple 759 bandwidth (in bytes or packets/second) cap would be appropriate. 761 The shared nature of the "minimal" cell used for join traffic makes 762 the network prone to DoS attacks by congesting the JP with bogus 763 radio traffic. As such an attacker is limited by emitted radio 764 power, redundancy in the number of deployed JPs alleviates the issue 765 and also gives the pledge a possibility to use the best available 766 link for join. How a network node decides to become a JP is out of 767 scope of this specification. 769 At the time of the join, the pledge has no means of verifying the 770 content in the EB and has to accept it at "face value". In case the 771 pledge tries to join an attacker's network, the join response message 772 in such cases will either fail the security check or time out. The 773 pledge may implement a blacklist in order to filter out undesired 774 beacons and try to join the next seemingly valid network. The 775 blacklist alleviates the issue but is effectively limited by the 776 node's available memory. Such bogus beacons will prolong the join 777 time of the pledge and so the time spent in "minimal" 778 [I-D.ietf-6tisch-minimal] duty cycle mode. 780 13. Privacy Considerations 782 This specification relies on the uniqueness of EUI64 that is 783 transferred in clear as part of the security context identifier. 784 (EDNOTE: should we say IID here?) Privacy implications of using such 785 long-term identifier are discussed in [RFC7721] and comprise 786 correlation of activities over time, location tracking, address 787 scanning and device-specific vulnerability exploitation. Since the 788 join protocol is executed rarely compared to the network lifetime, 789 long-term threats that arise from using EUI64 are minimal. In 790 addition, the join response message contains an optional short 791 address which can be assigned by JRC to the pledge. The short 792 address is independent of the long-term identifier EUI64 and is 793 encrypted in the response. For that reason, it is not possible to 794 correlate the short address with the EUI64 used during the join. Use 795 of short addresses once the join protocol completes mitigates the 796 aforementioned privacy risks. In addition, EDHOC may be used for 797 identity protection during the join protocol by generating a random 798 context identifier in place of the EUI64 799 [I-D.selander-ace-cose-ecdhe]. 801 14. IANA Considerations 803 Note to RFC Editor: Please replace all occurrences of "[[this 804 document]]" with the RFC number of this specification. 806 This document allocates a well known name under the .arpa name space 807 according to the rules given in: [RFC3172]. The name "6tisch.arpa" 808 is requested. No subdomains are expected. No A, AAAA or PTR record 809 is requested. 811 14.1. CoAP Option Numbers Registry 813 The Stateless-Proxy option is added to the CoAP Option Numbers 814 registry: 816 +--------+-----------------+-------------------+ 817 | Number | Name | Reference | 818 +--------+-----------------+-------------------+ 819 | TBD | Stateless-Proxy | [[this document]] | 820 +--------+-----------------+-------------------+ 822 15. Acknowledgments 824 The work on this document has been partially supported by the 825 European Union's H2020 Programme for research, technological 826 development and demonstration under grant agreement No 644852, 827 project ARMOUR. 829 The authors are grateful to Thomas Watteyne and Goeran Selander for 830 reviewing the draft. The authors would also like to thank Francesca 831 Palombini and Ludwig Seitz for participating in the discussions that 832 have helped shape the document. 834 16. References 836 16.1. Normative References 838 [I-D.ietf-core-object-security] 839 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 840 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 841 object-security-01 (work in progress), December 2016. 843 [I-D.ietf-cose-msg] 844 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 845 draft-ietf-cose-msg-24 (work in progress), November 2016. 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, 849 DOI 10.17487/RFC2119, March 1997, 850 . 852 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 853 Requirements for the Address and Routing Parameter Area 854 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 855 September 2001, . 857 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 858 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 859 October 2013, . 861 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 862 Application Protocol (CoAP)", RFC 7252, 863 DOI 10.17487/RFC7252, June 2014, 864 . 866 16.2. Informative References 868 [I-D.ietf-6tisch-6top-protocol] 869 Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- 870 ietf-6tisch-6top-protocol-03 (work in progress), October 871 2016. 873 [I-D.ietf-6tisch-dtsecurity-secure-join] 874 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 875 6tisch-dtsecurity-secure-join-01 (work in progress), 876 February 2017. 878 [I-D.ietf-6tisch-minimal] 879 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 880 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 881 in progress), February 2017. 883 [I-D.ietf-6tisch-terminology] 884 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 885 "Terminology in IPv6 over the TSCH mode of IEEE 886 802.15.4e", draft-ietf-6tisch-terminology-08 (work in 887 progress), December 2016. 889 [I-D.ietf-anima-bootstrapping-keyinfra] 890 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 891 S., and K. Watsen, "Bootstrapping Remote Secure Key 892 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 893 keyinfra-04 (work in progress), October 2016. 895 [I-D.richardson-6tisch-join-enhanced-beacon] 896 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 897 Element encapsulation of 6tisch Join Information", draft- 898 richardson-6tisch-join-enhanced-beacon-01 (work in 899 progress), March 2017. 901 [I-D.richardson-6tisch-minimal-rekey] 902 Richardson, M., "Minimal Security rekeying mechanism for 903 6TiSCH", draft-richardson-6tisch-minimal-rekey-01 (work in 904 progress), February 2017. 906 [I-D.selander-ace-cose-ecdhe] 907 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 908 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 909 cose-ecdhe-04 (work in progress), October 2016. 911 [IEEE8021542015] 912 IEEE standard for Information Technology, ., "IEEE Std 913 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 914 Networks (WPANs)", 2015. 916 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 917 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 918 RFC 4231, DOI 10.17487/RFC4231, December 2005, 919 . 921 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 922 Key Derivation Function (HKDF)", RFC 5869, 923 DOI 10.17487/RFC5869, May 2010, 924 . 926 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 927 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 928 January 2012, . 930 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 931 Bormann, "Neighbor Discovery Optimization for IPv6 over 932 Low-Power Wireless Personal Area Networks (6LoWPANs)", 933 RFC 6775, DOI 10.17487/RFC6775, November 2012, 934 . 936 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 937 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 938 Internet of Things (IoT): Problem Statement", RFC 7554, 939 DOI 10.17487/RFC7554, May 2015, 940 . 942 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 943 Considerations for IPv6 Address Generation Mechanisms", 944 RFC 7721, DOI 10.17487/RFC7721, March 2016, 945 . 947 Appendix A. Example 949 Figure 6 illustrates a join protocol exchange in case PSKs are used. 950 Pledge instantiates the OSCOAP context and derives the traffic keys 951 and nonces from the PSK. It uses the instantiated context to protect 952 the CoAP request addressed with Proxy-Scheme option and well-known 953 host name of JRC in the Uri-Host option. The example assumes a JP 954 that is already aware of JRC's IPv6 address and does not need to 955 resolve the well-known "6tisch.arpa" host name. Triggered by the 956 presence of Proxy-Scheme option, JP forwards the request to the JRC 957 and adds the Stateless-Proxy option with value set to the internally 958 needed state, authentication tag, and a freshness indicator. Once 959 JRC receives the request, it looks up the correct context based on 960 the Sender ID (sid) parameter. It reconstructs OSCOAP's external 961 Additional Authenticated Data (AAD) needed for verification based on: 963 o Version field of the received CoAP header. 965 o Code field of the received CoAP header. 967 o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. 969 o Request ID being set to pledge's EUI-64 concatenated with 0x00. 971 o Request Sequence number set to the value of "Partial IV" of the 972 received COSE object. 974 Replay protection is ensured by OSCOAP and the tracking of sequence 975 numbers at each side. In the example below, the response contains 976 sequence number 7 meaning that there have already been some attempts 977 to join under a given context, not coming from the pledge. Once JP 978 receives the response, it authenticates the Stateless-Proxy option 979 before deciding where to forward. JP sets its internal state to that 980 found in the Stateless-Proxy option. Note that JP does not posses 981 the key to decrypt the COSE object present in the payload so the 982 join_response object is opaque to it. The response is matched to the 983 request and verified for replay protection at pledge using OSCOAP 984 processing rules. 986 <--E2E OSCOAP--> 987 Client Proxy Server 988 Pledge JP JRC 989 | | | 990 +----->| | Code: [0.01] (GET) 991 | GET | | Token: 0x8c 992 | | | Proxy-Scheme: [coap] 993 | | | Uri-Host: [6tisch.arpa] 994 | | | Object-Security: [sid:EUI-64 | 0, seq:1, 995 | | | {Uri-Path:"j"}, 996 | | | ] 997 | | | Payload: - 998 | | | 999 | +----->| Code: [0.01] (GET) 1000 | | GET | Token: 0x7b 1001 | | | Uri-Host: [6tisch.arpa] 1002 | | | Object-Security: [sid:EUI-64 | 0, seq:1, 1003 | | | {Uri-Path:"j"}, 1004 | | | ] 1005 | | | Stateless-Proxy: opaque state 1006 | | | Payload: - 1007 | | | 1008 | |<-----+ Code: [2.05] (Content) 1009 | | 2.05 | Token: 0x7b 1010 | | | Object-Security: - 1011 | | | Stateless-Proxy: opaque state 1012 | | | Payload: [ seq:7, 1013 | | | {join_response}, ] 1014 | | | 1015 |<-----+ | Code: [2.05] (Content) 1016 | 2.05 | | Token: 0x8c 1017 | | | Object-Security: - 1018 | | | Payload: [ seq:7, 1019 | | | {join_response}, ] 1020 | | | 1022 Figure 6: Example of a join protocol exchange with a PSK. {} denotes 1023 encryption and authentication, [] denotes authentication. 1025 Where join_response is as follows. 1027 join_response: 1028 [ 1029 [ / COSE Key Set array with a single key / 1030 { 1031 1 : 4, / key type symmetric / 1032 2 : h'01', / key id / 1033 -1 : h'e6bf4287c2d7618d6a9687445ffd33e6' / key value / 1034 } 1035 ], 1036 [ 1037 h'af93' / assigned short address / 1038 ] 1039 ] 1041 Encodes to 1042 h'8281a301040241012050e6bf4287c2d7618d6a9687445ffd33e68142af93' with 1043 a size of 30 bytes. 1045 Authors' Addresses 1047 Malisa Vucinic 1048 Inria 1049 2 Rue Simone Iff 1050 Paris 75012 1051 France 1053 Email: malisa.vucinic@inria.fr 1055 Jonathan Simon 1056 Linear Technology 1057 32990 Alvarado-Niles Road, Suite 910 1058 Union City, CA 94587 1059 USA 1061 Email: jsimon@linear.com 1063 Kris Pister 1064 University of California Berkeley 1065 512 Cory Hall 1066 Berkeley, CA 94720 1067 USA 1069 Email: pister@eecs.berkeley.edu 1070 Michael Richardson 1071 Sandelman Software Works 1072 470 Dawson Avenue 1073 Ottawa, ON K1Z5V7 1074 Canada 1076 Email: mcr+ietf@sandelman.ca