idnits 2.17.1 draft-ietf-6tisch-minimal-security-01.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 (February 02, 2017) is 2639 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-01 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-19 == 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 (-14) exists of draft-selander-ace-cose-ecdhe-04 Summary: 1 error (**), 0 flaws (~~), 6 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: August 6, 2017 Linear Technology 6 K. Pister 7 University of California Berkeley 8 February 02, 2017 10 Minimal Security Framework for 6TiSCH 11 draft-ietf-6tisch-minimal-security-01 13 Abstract 15 This draft describes the minimal mechanisms required to support 16 secure initial configuration in a device being added to a 6TiSCH 17 network. The goal of this configuration is to set link-layer keys, 18 and to establish a secure session between each joining node and the 19 JCE who may use that to further configure the joining device. 20 Additional security behaviors and mechanisms may be added on top of 21 this minimal framework. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 6, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Join Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 5 61 3.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 5 62 3.3. Step 3 - Security Handshake . . . . . . . . . . . . . . . 5 63 3.3.1. Pre-Shared Key . . . . . . . . . . . . . . . . . . . 6 64 3.3.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 6 65 3.4. Step 4 - Join Request . . . . . . . . . . . . . . . . . . 6 66 3.5. Step 5 - Join Response . . . . . . . . . . . . . . . . . 6 67 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 7 68 4.1. Proxy Operation of JA . . . . . . . . . . . . . . . . . . 7 69 4.1.1. Implementation of origin_info . . . . . . . . . . . . 8 70 4.2. OSCOAP Security Context Instantiation . . . . . . . . . . 8 71 4.3. Implementation of Join Request . . . . . . . . . . . . . 9 72 4.4. Implementation of Join Response . . . . . . . . . . . . . 9 73 5. Link-layer requirements . . . . . . . . . . . . . . . . . . . 10 74 5.1. Well-known beacon authentication key . . . . . . . . . . 10 75 5.2. Private beacon authentication key . . . . . . . . . . . . 10 76 6. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 11.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 When a previously unknown device seeks admission to a 6TiSCH 90 [RFC7554] network (to "join"), it first needs to synchronize to the 91 network. The device then configures its IPv6 address and 92 authenticates itself, and also validates that it is joining the right 93 network. At this point it can expect to interact with the network to 94 configure its link-layer keying material. Only then may the node 95 establish an end-to-end secure session with an Internet host using 96 DTLS [RFC6347] or OSCOAP [I-D.ietf-core-object-security]. Once the 97 application requirements are known, the device interacts with its 98 peers to request additional resources as needed, or to be 99 reconfigured as the network changes [I-D.ietf-6tisch-6top-protocol]. 101 This document describes the mechanisms comprising a minimal feature 102 set for a device to join a 6TiSCH network, up to the point where it 103 can establish a secure session with an Internet host. 105 It presumes a network as described by [RFC7554], 106 [I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-terminology]. 107 It assumes the joining device pre-configured with either a: 109 o pre-shared key (PSK), 111 o raw public key (RPK), 113 o or a locally-valid certificate and a trust anchor. 115 As the outcome of the join process, the joining device expects one or 116 more link-layer key(s) and optionally a temporary network identifier. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. These 123 words may also appear in this document in lowercase, absent their 124 normative meanings. 126 The reader is expected to be familiar with the terms and concepts 127 defined in [I-D.ietf-6tisch-terminology], [RFC7252], and 128 [I-D.ietf-core-object-security]. The entities participating in the 129 protocol that is specified in this document are: 131 o JN: Joining node - the device attempting to join a particular 132 6TiSCH network. 134 o JCE: Join coordinating entity - central entity responsible for 135 authentication and authorization of joining nodes. 137 o JA: Join assistant - the device within radio range of the JN that 138 generates Enhanced Beacons (EBs) and facilitates end-to-end 139 communications between the JN and JCE. 141 3. Join Overview 143 This section describes the steps taken by a joining node (JN) in a 144 6TiSCH network. When a previously unknown device seeks admission to 145 a 6TiSCH [RFC7554] network, the following exchange occurs: 147 1. The JN listens for an Enhanced Beacon (EB) frame 148 [IEEE802154-2015]. This frame provides network synchronization 149 information, and tells the device when it can send a frame to the 150 node sending the beacons, which plays the role of Join Assistant 151 (JA) for the JN, and when it can expect to receive a frame. 153 2. The JN configures its link-local IPv6 address and advertises it 154 to JA. 156 3. The JN sends packets to the JA device in order to securely 157 identify itself to the network. These packets are directed to 158 the Join Coordination Entity (JCE), which may be the JA or 159 another device. 161 4. The JN receives one or more packets from JCE (via the JA) that 162 sets up one or more link-layer keys used to authenticate 163 subsequent transmissions to peers. 165 From the joining node's perspective, minimal joining is a local 166 phenomenon - the JN only interacts with the JA, and it need not know 167 how far it is from the DAG root, or how to route to the JCE. Only 168 after establishing one or more link-layer keys does it need to know 169 about the particulars of a 6TiSCH network. 171 The handshake is shown as a transaction diagram in Figure 1: 173 +-----+ +----------+ +-----------+ 174 | JCE | | JA | | JN | 175 | | | | | | 176 +-----+ +----------+ +-----------+ 177 | | | 178 | |-----------ENH BEACON (1)-->| 179 | | | 180 | |<--Neighbor Discovery (2)-->| 181 | | | 182 |<--Sec. Handshake (3a)--|---Security Handshake (3)-->| 183 | | | 184 |<----Join request (4a)--|---------Join request (4)---| 185 | | | 186 |----Join response (5a)--|--------Join response (5)-->| 187 | | | 189 Figure 1: Message sequence for join protocol. 191 The details of each step are described in the following sections. 193 3.1. Step 1 - Enhanced Beacon 195 The JN hears an EB from the JA and synchronizes itself to the joining 196 schedule using the cells contained in the EB. At this point the JN 197 MAY proceed to step 2, or continue to listen for additional EBs. If 198 more than one EB is heard, the JN MAY use a metric based on DAG rank 199 and received signal level of the EB, or other factors to decide which 200 JA to use for the security handshake in step 3. Details on how a JN 201 chooses the JA are out of scope of this specification. 203 3.2. Step 2 - Neighbor Discovery 205 At this point, JN forms its link-local IPv6 address based on EUI64 206 and MAY further follow the Neighbor Discovery (ND) process described 207 in Section 5 of [RFC6775]. 209 3.3. Step 3 - Security Handshake 211 The security handshake between JN and JCE uses Ephemeral Diffie- 212 Hellman over COSE (EDHOC) [I-D.selander-ace-cose-ecdhe] to establish 213 the shared secret used to encrypt the join request and join response. 215 The security handshake step is OPTIONAL in case PSKs are used, while 216 it is REQUIRED for RPKs and certificates. In case the handshake step 217 is omitted, the shared secret used for protection of the join request 218 and join response in the next step is the PSK. This means that the 219 protocol trades off perfect forward secrecy for reduced traffic load 220 between JN and JCE. A consequence is that if the long-term PSK is 221 compromised, keying material transferred as part of the join response 222 is compromised as well. Physical compromise of the JN, however, 223 would also imply the compromise of the same keying material, as it is 224 likely to be found in node's memory. 226 3.3.1. Pre-Shared Key 228 The Diffie-Hellman key exchange and the use of EDHOC is optional, 229 when using a pre-shared symmetric key. This cuts down on traffic 230 between JCE and JN, but requires pre-configuration of the shared key 231 on both devices. 233 It is REQUIRED to use unique PSKs for each JN. 235 3.3.2. Asymmetric Keys 237 The Security Handshake step is required, when using asymmetric keys. 238 Before conducting the Diffie-Hellman key exchange using EDHOC 239 [I-D.selander-ace-cose-ecdhe] the JN and JCE need to receive and 240 validate each other's public key certificate. When RPKs are pre- 241 configured at JN and JCE, they can directly proceed to the handshake. 243 3.4. Step 4 - Join Request 245 The join request is sent from the JN to the JA using the slot 246 information from the EB, and forwarded to the JCE. 248 The join request is authenticated/encrypted end-to-end using AES-CCM- 249 16-64-128 algorithm from [I-D.ietf-cose-msg] and a key derived from 250 the shared secret from step 3. The nonce is derived from the shared 251 secret, JN's EUI64 and a monotonically increasing counter initialized 252 to 0 when first starting. 254 3.5. Step 5 - Join Response 256 The join response is sent from the JCE to the JN through JA that 257 serves as a stateless relay. Packet containing the join response 258 travels on the path from JCE to JA using pre-established routes in 259 the network. The JA delivers it to the JN using the slot information 260 from the EB. JA operates as the application-layer proxy and does not 261 keep any state to relay the message. It uses information sent in the 262 clear within the join response to decide where to forward to. 264 The join response is authenticated/encrypted using AES-CCM-16-64-128 265 algorithm from [I-D.ietf-cose-msg] and a key derived from the shared 266 secret from step 3. The nonce is derived from the shared secret, 267 JN's EUI64 and a monotonically increasing counter matching that of 268 the join request. 270 The join response contains one or more (per-peer) link-layer key(s) 271 K2 that the JN will use for subsequent communication. It optionally 272 also contains an IEEE 802.15.4 short-address [IEEE802154-2015] 273 assigned to JN by JCE. 275 4. Protocol Specification 277 The join protocol in Figure 1 is implemented over Constrained 278 Application Protocol (CoAP) [RFC7252]. JN plays the role of a CoAP 279 client, JCE the role of a CoAP server, while JA implements CoAP 280 forward proxy functionality [RFC7252]. Since JA is likely a 281 constrained device, it does not need to implement a cache but rather 282 process forwarding-related CoAP options and make requests on behalf 283 of JN that is not yet part of the network. 285 JN and JCE MUST protect their exchange end-to-end (i.e. through the 286 proxy) using Object Security of CoAP (OSCOAP) 287 [I-D.ietf-core-object-security]. 289 4.1. Proxy Operation of JA 291 JN designates a JA as a proxy by including in the CoAP requests to 292 the JA the Proxy-Scheme option with value "coap" (CoAP-to-CoAP 293 proxy). JN MUST include the Uri-Host option with its value set to 294 the well-known JCE's alias - "6tisch.jce". JN does not need to learn 295 the actual IPv6 address of JCE at any time during the join protocol. 296 JA resolves the address by performing a GET request at "/jce" 297 resource of its parent in the DODAG. 299 Note that the CoAP proxy by default keeps state information in order 300 to forward the response towards the originator of the request. This 301 state information comprises CoAP token, but the implementations also 302 need to keep track of the IPv6 address of the host, as well as the 303 corresponding UDP source port number. In the setting where the proxy 304 is a constrained device, as in the case of JA, this makes it prone to 305 Denial of Service (DoS) attacks, due to the limited memory. 307 In order to facilitate a stateless implementation of JA proxying, JN 308 shall encode in the CoAP message the information necessary for the JA 309 to send the response back - "origin_info". For this purpose, JN uses 310 the "Context Identifier (Cid)" parameter of OSCOAP's security context 311 structure. Context Identifier is sent in clear, readable by JA, and 312 MUST be echoed back in the response from JCE. This makes it possible 313 to implement JA's CoAP proxy in a stateless manner. It also allows 314 JCE to look up the right security context for communication with a 315 given JN. 317 4.1.1. Implementation of origin_info 319 The origin_info is implemented as a CBOR [RFC7049] array object 320 containing: 322 o EUI64: JN's EUI64 address 324 o source_port: JN's UDP source port 326 o token: JN's CoAP token 328 origin_info = [ 329 EUI64 : bstr, 330 source_port : uint, 331 token : uint 332 ] 334 4.2. OSCOAP Security Context Instantiation 336 The OSCOAP security context MUST be derived at JN and JCE as per 337 Section 3.2 of [I-D.ietf-core-object-security] using HKDF [RFC5869] 338 as the key derivation function. 340 o Context Identifier (Cid) MUST be the origin_info object wrapped as 341 a byte string (bstr). 343 o Algorithm MUST be set to AES-CCM-16-64-128 from 344 [I-D.ietf-cose-msg]. CoAP messages are therefore protected with 345 an 8-byte CCM authentication tag and the algorithm uses 13-byte 346 long nonces. 348 o Base key (base_key) MUST be the secret generated by the run of 349 EDHOC, or the PSK in case EDHOC step was omitted. 351 o Sender ID of JN MUST be set to 0x00, while the ID of JCE MUST be 352 set to 0x01. 354 The hash algorithm that instantiates HKDF MUST be SHA-256 [RFC4231]. 355 The derivation in [I-D.ietf-core-object-security] results in traffic 356 keys and static IVs for each side of the conversation. Nonces are 357 constructed by XOR'ing the static IV with current sequence number. 358 The context derivation process occurs exactly once. Implementations 359 MUST ensure that multiple CoAP requests to different JCEs result in 360 the use of the same OSCOAP context so that sequence numbers are 361 properly incremented for each request. This may happen in a scenario 362 where there are multiple 6TiSCH networks present and the JN tries to 363 join one network at a time. 365 4.3. Implementation of Join Request 367 Join Request message SHALL be mapped to a CoAP request: 369 o The request method is GET. 371 o The Proxy-Scheme option is set to "coap". 373 o The Uri-Host option is set to "6tisch.jce". 375 o The Uri-Path option is set to "j". 377 o The object security option SHALL be set according to 378 [I-D.ietf-core-object-security] and OSCOAP parameters set as 379 described above. 381 4.4. Implementation of Join Response 383 If OSCOAP processing is a success, Join Response message SHALL be a 384 CoAP response: 386 o The response Code is 2.05 (Content). 388 o The payload is a CBOR array containing, in order: 390 * COSE Key Set [I-D.ietf-cose-msg]. Each key in the Key Set 391 SHALL be a symmetric key. A key that is present in the Key Set 392 and does not have an identifier is assumed to be "K2" link- 393 layer key from [I-D.ietf-6tisch-minimal]. Parameter "kid" of 394 the COSE Key structure SHALL be used to denote pair-wise keys 395 if present, where the value SHALL be set to the address of the 396 corresponding peer. 398 * Optional byte string representing IEEE 802.15.4 short address 399 assigned to JN. If the length of the byte string is different 400 than 2 bytes, the implementation SHOULD ignore it. 402 payload = [ 403 COSE_KeySet, 404 ? short_address : bstr, 405 ] 407 In case JCE determines that JN is not supposed to join the network 408 (e.g. by failing to find an appropriate security context), it should 409 respond with a 4.01 Unauthorized error. Upon reception of a 4.01 410 Unauthorized, JN SHALL attempt to join the next advertised 6TiSCH 411 network. If all join attempts have failed at JN, JN SHOULD signal to 412 the user by an out-of-band mechanism the presence of an error 413 condition. 415 5. Link-layer requirements 417 All frames in a 6TiSCH network MUST use link-layer frame security. 418 The frame security options MUST include frame authentication, and MAY 419 include frame encryption. 421 In order for the JN to be able to validate that the Enhanced Beacon 422 frame is coming from a 6TiSCH network, EB frames are authenticated at 423 the link layer using CCM* per [IEEE802154-2015]. Link-layer frames 424 are protected with a 16-byte key, and a 13-byte nonce constructed 425 from current Absolute Slot Number (ASN) and the source (the JA for 426 EBs) address, as shown in Figure 2: 428 +-------------------------------------------+ 429 | Address (8B or 00-padded 2B) | ASN (5B) | 430 +-------------------------------------------+ 432 Figure 2: Link-layer CCM* nonce construction 434 The JN uses the initial key K1 [I-D.ietf-6tisch-minimal] until it is 435 configured with a new link-layer key K2 as described above. JA 436 SHOULD secure/verify DATA and ACKNOWLEDGMENT frames destined/ 437 originated at JN with K1 only during the duration of the join 438 process. How JA learns whether the join process is ongoing is out of 439 scope of this specification. 441 As the EB itself does not contain security information, where the 442 link key is known, an attacker may craft a frame that appears to be a 443 valid EB, since the JN can neither know the ASN a priori nor verify 444 the address of the JA. This permits a Denial of Service (DoS) attack 445 at the JN. Beacon authentication keys are discussed in Section 5.1 446 and Section 5.2. 448 5.1. Well-known beacon authentication key 450 For zero-touch operation, where any 6TiSCH device can attempt to join 451 any 6TiSCH network out of the box, a well-known EB link-layer key 452 MUST be used. The value of this key is specified in 453 [I-D.ietf-6tisch-minimal] 455 5.2. Private beacon authentication key 457 Some pre-configuration MAY be done when the device is manufactured or 458 designated for a specific network (i.e. the network is one-touch) or 459 a network operator may not wish to allow arbitrary devices to try to 460 join. A private (per-vendor, or per-installation) EB link-layer key 461 MAY be used in place of a well-known key to create a private network. 463 6. Asymmetric Keys 465 Certificates or pre-configured RPKs may be used to exchange public 466 keys between the JN and JCE. The key pair is generated using 467 elliptic curve secp256r1, and the certificate containing the public 468 key is signed using ECDSA. The certificate itself may be a compact 469 representation of an X.509 certificate, or a full X.509 certificate. 470 Compact representation of X.509 certificates is out of scope of this 471 specification. The certificate is signed by a root CA whose 472 certificate is installed on all nodes participating in a particular 473 6TiSCH network, allowing each node to validate the certificate of the 474 JCE or JN as appropriate. 476 7. Security Considerations 478 In case PSKs are used, this document mandates that JN and JCE are 479 pre-configured with unique keys. The uniqueness of generated nonces 480 is guaranteed under the assumption of unique EUI64 identifiers for 481 each JN. Note that the address of the JCE does not take part in 482 nonce construction. Therefore, even under the assumption of a PSK 483 shared by a group of nodes, the nonces constructed as part of the 484 different responses are unique. The design differentiates between 485 nonces constructed for requests and nonces constructed for responses 486 by different sender identifiers (0x00 for JN and 0x01 for JCE). 488 Being a stateless relay, JA blindly forwards the join traffic into 489 the network. While the exchange between JN and JA takes place over a 490 shared cell, join traffic is forwarded using dedicated cells on the 491 JA to JCE path. In case of distributed scheduling, the join traffic 492 may therefore cause intermediate nodes to request additional 493 bandwidth. Because the relay operation of JA is implemented at the 494 application layer, JA is the only hop on the JA-6LBR path that can 495 distinguish join traffic from regular IP traffic in the network. It 496 is therefore permitted to implement rate limiting at JA. 498 The shared nature of the "minimal" cell used for join traffic makes 499 the network prone to DoS attacks by congesting the JA with bogus 500 radio traffic. As such an attacker is limited by emitted radio 501 power, redundancy in the number of deployed JAs alleviates the issue 502 and also gives JN a possibility to use the best available link for 503 join. How a network node decides to become a JA is out of scope of 504 this specification. 506 Because the well-known beacon authentication key does not provide any 507 security, it is feasible for an attacker to generate EBs that will 508 get accepted at JN. At the time of the join, JN has no means of 509 verifying the content in the EB and has to accept it at "face value". 510 As the join response message in such cases will either fail the 511 security check or time out, JN may implement a blacklist in order to 512 filter out undesired beacons and try to join the next seemingly valid 513 network. The blacklist alleviates the issue but is effectively 514 limited by the node's available memory. Such bogus beacons will 515 prolong the join time of JN and so the time spent in "minimal" 516 [I-D.ietf-6tisch-minimal] duty cycle mode. The permitted practice is 517 to use a private, per-installation beacon authentication key. 519 8. Privacy Considerations 521 This specification relies on the uniqueness of EUI64 that is 522 transferred in clear as part of the security context identifier. 523 Privacy implications of using such long-term identifier are discussed 524 in [RFC7721] and comprise correlation of activities over time, 525 location tracking, address scanning and device-specific vulnerability 526 exploitation. Since the join protocol is executed rarely compared to 527 the network lifetime, long-term threats that arise from using EUI64 528 are minimal. In addition, the join response message contains an 529 optional short address which can be assigned by JCE to JN. Short 530 address is independent of the long-term identifier EUI64 and is 531 encrypted in the response. For that reason, it is not possible to 532 correlate the short address with the EUI64 used during the join. Use 533 of short addresses once the join protocol completes mitigates the 534 aforementioned privacy risks. In addition, EDHOC may be used for 535 identity protection during the join protocol by generating a random 536 context identifier in place of the EUI64 537 [I-D.selander-ace-cose-ecdhe]. 539 9. IANA Considerations 541 There is no IANA action required for this document. 543 10. Acknowledgments 545 The work on this document has been partially supported by the 546 European Union's H2020 Programme for research, technological 547 development and demonstration under grant agreement No 644852, 548 project ARMOUR. 550 The authors are grateful to Thomas Watteyne and Goeran Selander for 551 reviewing the draft. The authors would also like to thank Francesca 552 Palombini and Ludwig Seitz for participating in the discussions that 553 have helped shape the document. 555 11. References 557 11.1. Normative References 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, 561 DOI 10.17487/RFC2119, March 1997, 562 . 564 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 565 Application Protocol (CoAP)", RFC 7252, 566 DOI 10.17487/RFC7252, June 2014, 567 . 569 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 570 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 571 October 2013, . 573 [I-D.ietf-cose-msg] 574 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 575 draft-ietf-cose-msg-24 (work in progress), November 2016. 577 [I-D.ietf-core-object-security] 578 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 579 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 580 object-security-01 (work in progress), December 2016. 582 11.2. Informative References 584 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 585 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 586 Internet of Things (IoT): Problem Statement", RFC 7554, 587 DOI 10.17487/RFC7554, May 2015, 588 . 590 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 591 Bormann, "Neighbor Discovery Optimization for IPv6 over 592 Low-Power Wireless Personal Area Networks (6LoWPANs)", 593 RFC 6775, DOI 10.17487/RFC6775, November 2012, 594 . 596 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 597 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 598 January 2012, . 600 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 601 Key Derivation Function (HKDF)", RFC 5869, 602 DOI 10.17487/RFC5869, May 2010, 603 . 605 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 606 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 607 RFC 4231, DOI 10.17487/RFC4231, December 2005, 608 . 610 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 611 Considerations for IPv6 Address Generation Mechanisms", 612 RFC 7721, DOI 10.17487/RFC7721, March 2016, 613 . 615 [I-D.ietf-6tisch-minimal] 616 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 617 6TiSCH Configuration", draft-ietf-6tisch-minimal-19 (work 618 in progress), January 2017. 620 [I-D.ietf-6tisch-6top-protocol] 621 Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- 622 ietf-6tisch-6top-protocol-03 (work in progress), October 623 2016. 625 [I-D.ietf-6tisch-terminology] 626 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 627 "Terminology in IPv6 over the TSCH mode of IEEE 628 802.15.4e", draft-ietf-6tisch-terminology-08 (work in 629 progress), December 2016. 631 [I-D.selander-ace-cose-ecdhe] 632 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 633 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 634 cose-ecdhe-04 (work in progress), October 2016. 636 [IEEE802154-2015] 637 IEEE standard for Information Technology, ., "IEEE Std 638 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 639 Networks (WPANs)", 2015. 641 Appendix A. Example 643 Figure 3 illustrates a join protocol exchange in case PSKs are used. 644 JN instantiates the OSCOAP context and derives the traffic keys and 645 nonces from the PSK. It uses the instantiated context to protect the 646 CoAP request addressed with Proxy-Scheme option and well-known host 647 name of JCE in the Uri-Host option. The example assumes a JA that is 648 already aware of JCE's IPv6 address and does not need to resolve the 649 well-known "6tisch.jce" host name. Triggered by the presence of 650 Proxy-Scheme option, JA forwards the request to the JCE. Once JCE 651 receives the request, it looks up the correct context based on the 652 context identifier (cid) field. It reconstructs OSCOAP's external 653 Additional Authenticated Data (AAD) needed for verification based on: 655 o Version field of the received CoAP header. 657 o Code field of the received CoAP header. 659 o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg] 661 o Request URI reconstructed following 662 [I-D.ietf-core-object-security]. 664 Replay protection is ensured by OSCOAP and the tracking of sequence 665 numbers at each side. In the example below, the response contains 666 sequence number 7 meaning that there have already been some attempts 667 to join under a given context, not coming from the JN. Once JA 668 receives the response, it looks up and decodes the cid field in order 669 to decide where to forward it. JA constructs the CoAP response to JN 670 by setting the CoAP token to the value decoded from cid and 671 constructs the link-local IPv6 address of JN from the EUI64 address 672 found in the cid. Note that JA does not posses the key to decrypt 673 the COSE object present in the payload so the join_response object is 674 opaque to it. The response is matched to the request and verified 675 for replay protection at JN using OSCOAP processing rules. Namely, 676 to verify the response JN reconstructs the AAD based on: 678 o Version field of the received CoAP header. 680 o Code field of the received CoAP header. 682 o Algorithm being the AES-CCM-16-64-128 from [I-D.ietf-cose-msg]. 684 o Transaction identifier (Tid) of the corresponding CoAP request. 685 Tid contains the context identifier (origin_info object), Sender 686 ID (0x00 for JN), and Sender Sequence number (set to 1 in the 687 example). 689 In addition to AAD, JN also uses the explicit, protected fields in 690 the COSE message, present in the payload of the response. For more 691 details, see [I-D.ietf-core-object-security] and [I-D.ietf-cose-msg]. 693 <--E2E OSCOAP--> 694 Client Proxy Server 695 JN JA JCE 696 | | | 697 +----->| | Code: [0.01] (GET) 698 | GET | | Token: 0x8c 699 | | | Proxy-Scheme: [coap] 700 | | | Uri-Host: [6tisch.jce] 701 | | | Object-Security: [cid:origin_info, seq:1, 702 | | | {Uri-Path:"j"}, 703 | | | ] 704 | | | Payload: - 705 | | | 706 | +----->| Code: [0.01] (GET) 707 | | GET | Token: 0x7b 708 | | | Uri-Host: [6tisch.jce] 709 | | | Object-Security: [cid:origin_info, seq:1, 710 | | | {Uri-Path:"j"}, 711 | | | ] 712 | | | Payload: - 713 | | | 714 | |<-----+ Code: [2.05] (Content) 715 | | 2.05 | Token: 0x7b 716 | | | Object-Security: - 717 | | | Payload: [cid: origin_info, seq:7, 718 | | | {join_response}, ] 719 | | | 720 |<-----+ | Code: [2.05] (Content) 721 | 2.05 | | Token: 0x8c 722 | | | Object-Security: - 723 | | | Payload: [cid: origin_info, seq:7, 724 | | | {join_response}, ] 725 | | | 727 Figure 3: Example of a join protocol exchange with a PSK. {} denotes 728 encryption and authentication, [] denotes authentication. 730 Where origin_info and join_response are as follows. 732 origin_info: 733 [ 734 h'00170d00060d9f0e', / JN's EUI64 / 735 49152, / JN's UDP source port / 736 0x8c / JN's CoAP token / 737 ] 739 Encodes to h'834800170d00060d9f0e19c000188c' with a size of 15 bytes. 741 join_response: 742 [ 743 [ / COSE Key Set array with a single key / 744 { 745 1:4, / key type symmetric / 746 -1:h'e6bf4287c2d7618d6a9687445ffd33e6' / key value / 747 } 748 ], 749 h'af93' / assigned short address / 750 ] 752 Encodes to h'8281a201042050e6bf4287c2d7618d6a9687445ffd33e642af93' 753 with a size of 26 bytes. 755 Authors' Addresses 757 Malisa Vucinic 758 Inria 759 2 Rue Simone Iff 760 Paris 75012 761 France 763 Email: malisa.vucinic@inria.fr 765 Jonathan Simon 766 Linear Technology 767 32990 Alvarado-Niles Road, Suite 910 768 Union City, CA 94587 769 USA 771 Email: jsimon@linear.com 773 Kris Pister 774 University of California Berkeley 775 512 Cory Hall 776 Berkeley, CA 94720 777 USA 779 Email: pister@eecs.berkeley.edu