idnits 2.17.1 draft-keoh-lwig-dtls-iot-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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 == Line 136 has weird spacing: '...figured with ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 27, 2013) is 3894 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 183, but not defined -- Looks like a reference, but probably isn't: '6345' on line 486 -- Looks like a reference, but probably isn't: '6775' on line 488 == Missing Reference: 'Dunkels-contiki' is mentioned on line 628, but not defined == Unused Reference: 'RFC6775' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'Dunkels-Contiki' is defined on line 869, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-12 -- No information found for draft-keoh-multicast-security - is the name correct? Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group S. Keoh 3 Internet-Draft University of Glasgow 4 Intended Status: Informational S. Kumar 5 Expires: February 27, 2014 O. Garcia-Morchon 6 Philips Research 7 August 27, 2013 9 Securing the IP-based Internet of Things with DTLS 10 draft-keoh-lwig-dtls-iot-02 12 Abstract 14 The IP-based Internet of Things (IoT) refers to the pervasive 15 interaction of smart devices and people enabling new applications by 16 means of IP protocols. Traditional IP protocols will be further 17 complemented by 6LoWPAN and CoAP to make the IoT feasible on small 18 devices. Security and privacy are a must for such an environment. Due 19 to mobility, limited bandwidth, resource constraints, and new 20 communication topologies, existing security solutions need to be 21 adapted. We propose a security architecture for the IoT in order to 22 provide network access control to smart devices, the management of 23 keys and securing unicast/multicast communication. Devices are 24 authenticated and granted network access by means of a pre-shared key 25 (PSK) based security handshake protocol. The solution is based on 26 Datagram Transport Layer Security (DTLS). Through the established 27 secure channels, keying materials, operational and security 28 parameters are distributed, enabling devices to derive session keys 29 and group keys. The solution relies on the DTLS Record Layer for the 30 protection of unicast and multicast data flows. We have prototyped 31 and evaluated the security architecture. The DTLS architecture allows 32 for easier interaction and interoperability with the Internet due to 33 the extensive use of TLS. However, it exhibits performance issues 34 constraining its deployment in some network topologies and hence 35 would require further optimizations. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as 45 Internet-Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/1id-abstracts.html 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 Copyright and License Notice 60 Copyright (c) 2013 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Related Work and Background . . . . . . . . . . . . . . . . . 6 78 3 Use Cases & Problem Statement . . . . . . . . . . . . . . . . . 7 79 3.1 Problem Statement and Requirements . . . . . . . . . . . . . 8 80 3.2 Threat model, Security Goals & Assumptions . . . . . . . . . 8 81 4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 4.2 Secure Network Access . . . . . . . . . . . . . . . . . . . 11 84 4.3 Key Management . . . . . . . . . . . . . . . . . . . . . . . 12 85 4.3.1 Management of unicast keys . . . . . . . . . . . . . . . 12 86 4.3.2 Management of multicast keys . . . . . . . . . . . . . . 13 87 4.4 Secure Uni- and Multicast Communication . . . . . . . . . . 14 88 4.4.1 Unicast Communication . . . . . . . . . . . . . . . . . 14 89 4.4.2 Multicast Communication . . . . . . . . . . . . . . . . 14 90 5 Implementation and Evaluation . . . . . . . . . . . . . . . . . 14 91 5.1 Prototype Implementation . . . . . . . . . . . . . . . . . . 14 92 5.2 Memory Consumption . . . . . . . . . . . . . . . . . . . . . 15 93 5.3 Communication Overhead . . . . . . . . . . . . . . . . . . . 16 94 5.4 Message Delay, Success Rate and Bandwidth . . . . . . . . . 16 95 6. Conclusions and future work . . . . . . . . . . . . . . . . . . 18 96 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 18 97 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 99 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 10.1 Normative References . . . . . . . . . . . . . . . . . . . 18 101 9.2 Informative References . . . . . . . . . . . . . . . . . . 19 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 104 1 Introduction 106 The IP-based Internet of Things (IoT) will enable smart and mobile 107 devices equipped with sensing, acting, and wireless communication 108 capabilities to interact and cooperate with each other in a pervasive 109 way by means of IP connectivity. IP protocols play a key role in this 110 vision since they allow for end-to-end connectivity using standard 111 protocols ensuring that different smart devices can easily 112 communicate with each other in an inexpensive way. Protocols such as 113 IPv6, TCP and HTTP that are commonly used in traditional networks 114 will be complemented by IPv6 over Low power Wireless Personal Area 115 Networks (6LoWPAN) and Constrained Application Protocol (CoAP) 116 currently in development in IETF. 118 This allows smart and mobile devices used for various applications 119 like healthcare monitoring, industrial automation and smart cities to 120 be seamlessly connected to the Internet, thus creating a plethora of 121 IoT applications. An example application is smart-metering, in which 122 a smart-meter can communicate with consumer electronics and other 123 devices in a building/household to retrieve and manage energy 124 consumption. Additionally, a set of lighting devices could be 125 controlled and managed efficiently by the smart-meter, e.g., dimming 126 them down during peak energy periods by means of a multicast message. 128 Security and privacy are mandatory requirements for the IP-based IoT 129 in order to ensure its acceptance. The interaction between devices 130 must be regulated in the sense that authorized devices joining a 131 specific IoT network in a given location will be granted access to 132 only certain resources provided by the IoT. 134 To enable this, the IoT network has to: 135 1. Authorize the joining of the smart device, such that it is 136 provisioned and configured with the corresponding operational 137 parameters, thus providing "network access". 138 2. Establish and derive pairwise keys, application session keys 139 and multicast keys to enable devices to secure its 140 communication links with each other, and for that, "key 141 management" is needed. 142 3. Devices should be able to communicate within the network, 143 either securely pairwise or in a "secure multicast" group. 145 In order to achieve these three security functionalities, there are 146 several challenges: (i) no standard solution exists yet; (ii) 147 mobility of smart devices should be accounted for; (iii) the solution 148 needs to be applicable to large scale deployments; (iv) new 149 communication patterns introduced in IoT such as multicast (beyond 150 just end-to-end communication links), and thus, IP security protocols 151 need to be adapted; and (v) the available resources (bandwidth, 152 memory, and CPU) are tightly constrained. 154 Of course, the three research topics are not new, and indeed, some of 155 them (e.g., key management or secure broadcast) have been extensively 156 analyzed in the wireless sensor network literature during the last 157 decade. However, the last step of applying those results to actual 158 standards to get a working solution is still a missing and crucial 159 step towards the success of the IP-based IoT. This work analyzes how 160 this can be achieved. 162 We present a security architecture for the IP-based IoT in order to 163 explore how these functionalities can be achieved by adapting and 164 extending IP security protocols. With this, our goal is to analyze 165 the trade-offs regarding performance, security, and interoperability 166 so that we obtain a solution that performs reliably, offers high 167 security, and is as interoperable as possible with the standard 168 Internet. 170 The solution is based on Datagram Transport Layer Security (DTLS). We 171 use the DTLS handshake for network access. For key management, we 172 integrate with the Adapted Multimedia Internet KEYing (AMIKEY) 173 protocol for efficient key management and generation of pairwise keys 174 within an IoT network. Secure multicast operation is enabled through 175 the direct use of DTLS record layer with the multicast keys to 176 protect CoAP messages on top of IP multicast. 178 1.1 Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 184 This Internet Draft defines the following terminology: 186 Internet of Things (IoT): A paradigm in which a diverse set of 187 devices with different resources and capabilities (including sensors, 188 actuators, smart phones, etc) are connected to the Internet, each is 189 equipped with a uniquely identifiable IP address that can be 190 contacted from anywhere and at anytime. 192 IoT domain: An IoT network that is connected to the public Internet 193 through a number of 6LoWPAN border routers where the devices and 194 services in the network are managed by a domain manager that could be 195 located within the IoT network itself or in the public Internet. 197 Network access: A joining device is authenticated and then checked 198 whether it is authorized to join a network. An IP address and a link- 199 layer (L2) key are allocated to the joining device upon successful 200 authentication and authorization of the joining device, hence 201 enabling the device to communicate in the secure network. This 202 process is called network access. 204 Key management: A process of distributing, updating and renewing 205 cryptographic materials including keying materials for deriving 206 unicast and multicast keys, random numbers, session keys for unicast 207 communication, and multicast group keys. 209 Security handshake protocol: A security protocol to authenticate two 210 communicating devices and subsequently establishes a shared secret- 211 key between them to secure their communication. The Datagram 212 Transport Layer Security (DTLS) is referred as the security handshake 213 protocol in this specification. 215 Link local address: A stateless IPv6 address that is intended for a 216 point-to-point communication between two devices that are within the 217 communication of each other. The packets with a link local address 218 will not be routed or forwarded further by routers. 220 Pairwise key: A secret symmetric key that is shared between two 221 communicating devices in the network, enabling them to encrypt and 222 authenticate data packets exchanged between them. 224 Multicast key: A secret symmetric key that is shared by a group of 225 devices in the network. It is used to protect the multicast group 226 communication. 228 2. Related Work and Background 230 The "Datagram Transport Layer Security (DTLS)" protocol [RFC4347] is 231 a datagram-compatible adaptation of TLS that runs on top of UDP. DTLS 232 uses similar messages as defined in TLS including the DTLS handshake 233 to establish a secure unicast link and the DTLS record layer to 234 protect this link. The "DTLS handshake" supports different types of 235 authentication mechanisms, e.g., using a pre-shared key, public-key 236 certificates, and raw public-keys. DTLS is the mandatory standard for 237 protection of CoAP [I-D.ietf-core-coap] messages. DTLS differs from 238 TLS mainly in three aspects: 239 (1) DTLS provides DoS protection through a stateless cookie 240 exchange; 241 (2) DTLS adds functionality to ensure a reliable link during its 242 handshake to solve UDP's inherent packet losses and reordering; 243 (3) The record layer includes an explicit sequence number (again, 244 due to the reordering issues in UDP) so that payload integrity 245 and reply protection can be ensured. 247 The Adapted Multimedia KEYing (AMIKEY) [I-D.alexander-roll-mikey] is 248 used to provide keying material for securing uni- and multicast 249 communications within constrained networks and devices. It is based 250 on MIKEY, a Key Management Protocol intended for use in real-time 251 applications [RFC3830]. For this purpose, AMIKEY provides different 252 message exchanges that may be transported directly over UDP and TCP. 253 Essentially, they can be integrated within other protocol like DTLS. 254 Our solutions make use of AMIKEY's key derivation mechanism as we 255 consider it to be efficient for constrained networks. 257 3 Use Cases & Problem Statement 259 +------------------------------+ 260 | +======+ | 261 +-|-->6LBR |Light1| | 262 | | +======+ | 263 | | +======+ | 264 | | |Light2| +======+ | 265 | | +======+ | Win2 | | 266 | | Floor 2 +======+ | 267 +---------+ Internet +-----+ | +------------------------------+ 268 | Backend | <----------> | BMS |-+ 269 +---------+ +-----+ | +---------------------------+ 270 | | +======+ | 271 +-|-->6LBR |Light4| | 272 | +======+ +======+ | 273 | |Light3| | 274 | +======+ +======+ | 275 | | Win1 | | 276 | Floor 1 +======+ | 277 +---------------------------+ 278 Figure 1: Building Management Systems (BMS) Scenario 280 Our work targets an "IoT network" running 6LoWPAN/CoAP over multiple 281 hops with both uni- and multicast links, i.e., typical edge networks 282 in the IoT. Devices in the "IoT network" are mobile or stationary and 283 exhibit tight processing, memory and bandwidth constraints. The "IoT 284 network" is connected to the public Internet through a number of 285 6LoWPAN border routers (6LBR). Further, we consider a centrally 286 managed scenario in which the devices and services in each "IoT 287 network" are managed by a "domain manager". The "domain manager" 288 could be located within the "IoT network" or in the public Internet. 289 The "domain manager" along with the "IoT networks" it manages is 290 denoted as the "IoT domain". Figure 1 illustrates an example of 291 Building Management Systems (BMS) scenario where smart devices within 292 the building (e.g., lighting devices, window blinds) form several 293 multi-hop IoT networks connected to a remote building management 294 system via some border routers. 296 3.1 Problem Statement and Requirements 298 We consider an IoT domain with many devices that dynamically join the 299 network, then provide or request a certain service and finally leave 300 the network. These services are provided or requested using either 301 unicast (e.g., switching on the heater) or multicast group 302 communication (e.g., switching on all lights in a room). We identify 303 three main problems that currently lack a standardized solution for 304 IoT networks: 306 o Network access -- A new joining device must only be able to 307 communicate in a secure IoT network after securely joining the 308 IoT network and receiving all necessary access parameters, 309 e.g., commissioning a new lighting bulb into the building 310 network. 312 The multi-hop nature of IoT networks leads to a key challenge 313 here since a joining device and the domain manager cannot reach 314 each other by means of regular IP routing so that specific 315 approaches are needed. 317 Similarly, devices that leave the IoT network should not be 318 able to access the network with previous access parameters. 320 o Key management -- A lightweight mechanism to derive and manage 321 different keys to secure interactions in the IoT domain is 322 required, e.g., different pairwise, group, and network keys. 324 o Secure uni- and multicast communication -- A secure transport 325 protocol is needed to protect the communication in the IoT 326 domain. 328 This includes both unicast and multicast links, protected using 329 the derived keys, e.g., preserving the integrity and 330 confidentiality of the exchanged commands. 332 Additional requirements are that the solutions need to be scalable 333 for an IoT domain with several hundreds or thousands of resource 334 constrained devices and be based on standard IP protocols for easier 335 interaction and interoperability with the Internet. In this work, we 336 provide a solution to these three problems based on a smart 337 combination of DTLS and AMIKEY with only minimal modifications. 339 3.2 Threat model, Security Goals & Assumptions 341 We assume the Internet Threat Model [RFC3552] in which a malicious 342 adversary can read and forge network traffic between devices at any 343 point during transmission, but assume that devices themselves are 344 secure. In many IoT application areas the network is indeed untrusted 345 (e.g., wireless communications in public places, large factories, 346 office buildings). Security of the end devices is important to create 347 a secure IoT scenario, however device security is not within the 348 scope of this draft. The Internet Threat Model is thus a reasonable 349 choice in our context. 351 We further identify the following threats in an IoT domain and the 352 corresponding security goals: 353 o Secure Network Access -- Attackers can perform network attacks, 354 e.g., flooding the network and using the network for other 355 communication purposes. To this end, only devices that have 356 been authenticated and authorized through a secure network 357 access process should be allowed to communicate within the 358 network. 360 o Key Management -- Attackers can attempt to compromise the 361 keying materials, pairwise keys, or multicast group keys by 362 exploiting the vulnerability on the devices. Therefore, secure 363 key derivation and key update mechanisms are required to manage 364 all cryptographic keys. Similarly, compromising the derived 365 keys does not enable the attackers to obtain information about 366 the keying materials. 368 o Secure Uni- and Multicast -- The adversary can maliciously 369 modify either unicast or multicast traffic in the IoT network. 370 Additionally, the adversary can eavesdrop on the data exchanged 371 within an IoT domain. For unicast, two communicating parties 372 must establish a pairwise key to secure the confidentiality, 373 integrity and authenticity of the information exchanged. 374 Multicast communication is protected using a group key, thus 375 only allowing authenticated and authorized group members to 376 send messages to a multicast group. We assume that the 377 multicast group members can trust each other since they are 378 authenticated and authorized by the domain manager. Therefore, 379 we do not additionally require source authentication in the 380 messages as will be detailed further later on. If a device 381 leaves a multicast group, it must not be able to rejoin and 382 send messages to the group later on. 384 Due to the resource constrained devices in the IoT network, our 385 proposed security architecture is based on the assumption that a 386 device has been configured with a PSK that is known "a priori" to the 387 domain manager of the IoT domain it wants to join. This assumption is 388 reasonable since a PSK could be embedded and registered during the 389 manufacturing process of a device and the domain manager can retrieve 390 it from a central server. If more powerful devices are available, our 391 secure network access can be easily updated to work with public-key 392 cryptography. 394 4 Design 396 In this section, we detail the design of our solution to the three 397 problems (i) secure network access, (ii) key management, and (iii) 398 uni- and multicast communication as identified in Section 3.1. The 399 solution is mainly built on DTLS and AMIKEY. 401 4.1 Overview 403 The first phase accounts for "secure network access". In our 404 architecture, the network is protected at link layer by means of a 405 symmetric-key (L2 key), which is unknown to the joining device "a 406 priori". Using its link local address, the joining device 407 authenticates itself to the domain manager of the IoT domain by means 408 of an initial handshake (DTLS) that is based on a PSK. The PSK is 409 assumed to have been pre-configured in the device (cf. Section 3.2). 410 On success, the domain manager issues access parameters (L2 key) that 411 would allow the joining device to access the secured IoT network and 412 to receive a routable IPv6 address. As the link local address only 413 enables one hop communication, this poses a key challenge in multi- 414 hop networks in that the domain manager cannot be reached directly. 415 In the proposed solution, this issue is dealt with by means of a 416 relay device, e.g., as was done in the PANA protocol by means of the 417 PANA relay element [RFC6345]. Figure 2 shows the generic logic of the 418 relay element. 420 +--------------+ N +--------------------------+ Y +-------+ 421 (S)-->|L2 secure msg?|--->| Network Access Request |--->|Process| 422 +--------------+ | msg & link-local Address?| |& Relay| 423 | +--------------------------+ +-------+ 424 |Y | 425 | |N 426 +-----------------+ | 427 |Normal processing| +------+ 428 +-----------------+ | Drop | 429 +------+ 431 Figure 2: Relay logic for secure network access 433 The second phase deals with "key management". The joining device is 434 provided with keying material to interact with other devices either 435 in pairs or groups. For pairwise key generation, two communicating 436 devices that wish to interact with each other can derive a pairwise 437 key based on their identities, e.g., using a polynomial scheme 438 [Blundo-polynomial]. For group key generation, we assume that the 439 domain manager controls the multicast groups. A joining device that 440 wishes to participate in a multicast group indicates this to the 441 domain manager during the initial handshake, and if authorized, 442 receives the required multicast group keys from the domain manager. 444 Neither pairwise nor group keys are used directly, instead they serve 445 as root keying material in the MIKEY key derivation mechanism in 446 order to derive fresh purpose-specific session keys for any pair or 447 group of devices in the IoT network. The protocol framework for 448 requesting and managing these purpose-specific keys is based on the 449 lightweight MIKEY-extension called AMIKEY [I-D.alexander-roll-mikey]. 451 The final phase, "secure uni- and multicast", is achieved by using 452 CoAP carried over the DTLS record layer. The pairwise or group keys 453 derived in the key management phase are used to protect the 454 communication links. 456 4.2 Secure Network Access 458 We describe the details of the initial DTLS based handshakes as well 459 as how multi-hop environments are handled. 461 IETF CoRE working group defines DTLS for securing the transport of 462 messages in an IoT domain. In this approach, the DTLS handshake 463 protocol is used during the secure network access phase. The DTLS 464 might be based on public-key certificates or raw public-keys as 465 specified in CoAP. Our design uses DTLS-PSK [RFC4279], because it 466 incurs less overhead and reduces the number of exchanged messages. We 467 now describe how DTLS-PSK is used in a single- and multi-hop 468 scenario. 470 Single-hop: In this case, the joining device can be 471 authenticated with the domain manager by performing the DTLS 472 handshake based on the PSK and relying on the link-local 473 address. Once the device has been authenticated and authorized 474 for the network, the established DTLS secure channel between 475 the domain manager and the joining device is used to issue the 476 L2 key to the device. DTLS-PSK provides resiliency against 477 Denial-of-Service attacks through a cookie mechanism. 479 Multi-hop: DTLS runs on UDP but communication is limited to a 480 single hop due to the link local address. To deal with this, a 481 relay device is responsible for forwarding the messages by 482 using a mapping between the link local address of the joining 483 device and the relay's IP address. The relaying logic consists 484 of changing the link local address of the joining device with 485 the relay device's IP address, in a similar way as done in PANA 486 relay element [6345]. This indeed allows for the provisioning 487 of L2 key to the joining device so that it can later receive 488 its IP address through the neighbor discovery protocol [6775]. 489 However, note that the DTLS channel established during the 490 handshake is bound to the relay's IP address and not the new IP 491 address of the joining device. Hence, if the device were to 492 communicate with the domain manager again, it would have to 493 redo the DTLS handshake using its new IP address. This means 494 that the DTLS channel established during network access is 495 transient and it is closed by the relay device once the 496 handshake is finished. 498 4.3 Key Management 500 This section describes the details of key management for unicast and 501 group communication. The goal of this phase is to set up an AMIKEY 502 crypto-session bundle (CSB) for unicast as well as group 503 communication. A CSB is built from some root keying material (the TEK 504 Generation Key (TGK)) and some random bits ("RAND"). AMIKEY then 505 defines a lightweight mechanism for the derivation and management of 506 fresh purpose-specific keys, called Traffic Encryption Keys (TEKs), 507 that are used to secure the communication links. We now explain, for 508 both the unicast and multicast case, how the root keying material, 509 i.e., the TGK, is obtained, how the CSB is negotiated and set up, and 510 finally how TEKs are requested and generated. 512 4.3.1 Management of unicast keys 514 DTLS runs on the transport layer, and thus we can use it directly to 515 protect the applications. Two communicating devices can establish a 516 pairwise keys using a polynomial scheme, in which each device's 517 polynomial share is used to facilitate fast pairwise key agreement 518 between them. This pairwise key serves as the PSK in DTLS-PSK 519 [RFC4279] enabling any two applications running on the devices to 520 derive a session key. In detail: 521 1. Two applications running on the devices "D1" and "D2" start a 522 DTLS-PSK handshake. They exchange their identities ID_D1 and 523 ID_D2 as extensions to the first two handshake messages, the 524 "ClientHello" and "ServerHello". 525 2. Both devices then generate a pairwise key, e.g., if a 526 polynomial scheme is used, they use their polynomial shares and 527 their respective identities to arrive on a pairwise key: 528 K(D1,D2) = F(ID_D1, ID_D2) = F(ID_D2, ID_D1). 529 3. The derived key K(D1,D2) is used as the PSK to complete the 530 DTLS-PSK handshake. This PSK can be regarded as the TGK. 531 4. The result of the DTLS-PSK handshake is a session key used to 532 protect the communication link between the two applications on 533 both devices. 535 4.3.2 Management of multicast keys 537 Joining Device Domain Manager 539 ClientHello + extension --------> 540 <-------- ServerHello + Extension 542 <----------Continue with the rest of DTLS Handshake-----------> 544 Generate AMIKEY 545 parameters 547 DTLS(CSB_ID, TGK, MIC) 548 <-------- protected with DTLS 550 DTLS(ACK, MIC) 551 protected with DTLS --------> 553 DTLS(CSB_ID,KEY_ID,RAND,MIC) 554 <-------- protected with DTLS 556 DTLS(ACK, MIC) 557 protected with DTLS --------> 559 Figure 3: DTLS-based Multicast Key Management 561 The joining device first indicates during the network access phase 562 that it wishes to join a certain multicast group by adding a request 563 with the group id in the extension part of the "ClientHello". The 564 domain manager then issues the multicast group keys to the device, if 565 it has been authorized to join. It is carried as payload over DTLS 566 record layer after the initial handshake has finished as shown in 567 Figure 3. Two new "Content Types" for the DTLS header have been 568 defined for this purpose to distinguish between the DTLS protected 569 application data and key management data. They are the necessary 570 parameters to set up a CSB, i.e. (1) "Master Key Data" (e.g., the 571 TGK) and (2) "Security Parameters Data" (e.g., the "RAND" values). 572 The fresh TEKs can then be derived from the CSB by every group member 573 for secure group communication. 575 When a device leaves a group, the domain manager deletes it from the 576 list of authenticated nodes, increases the TEK_ID and starts a new 577 TEK derivation process. The parameters required for generation of the 578 fresh TEK are encrypted so that the leaving device cannot derive the 579 new TEK and cannot rejoin without re-authorization. 581 4.4 Secure Uni- and Multicast Communication 583 Once the pairwise session keys or multicast group session key has 584 been derived, a secure channel can be created to transport data (CoAP 585 messages) between the devices in the IoT network. For this, we rely 586 on the DTLS record-layer to create a secure transport layer for CoAP. 587 In this case, the standard DTLS is used to secure the unicast 588 communication. 590 For multicast communication, the combination of our proposed 591 handshake protocols with the usage of DTLS record-layer for multicast 592 security is based on [I-D.keoh-multicast-security]. 594 4.4.1 Unicast Communication 596 Any pair of devices in the IoT domain that wish to communicate with 597 each other, establish a CSB and derive a fresh unicast TEK through 598 DTLS as described in Section 4.3.1. The TEK is used in the DTLS 599 record layer (based on AES-CCM) to protect the message exchange 600 between two applications. AES-CCM [RFC3610] is an AES mode of 601 operation that defines the use of AES-CBC for MAC generation with 602 AES-CTR for encryption. The CCM counter (corresponding to the DTLS 603 epoch and sequence number fields) are initialized to 0 upon TEK 604 establishment and used in the nonce construction in a standard way. 606 4.4.2 Multicast Communication 608 The multicast solution relies on IP multicast (i.e., an IP multicast 609 address) for routing purposes and adds a security layer on top. To 610 protect the communication, a group of devices establishes a multicast 611 CSB and fresh TEKs using DTLS as described in Section 4.3.2. The TEK 612 is then used to protect CoAP messages transported over the DTLS 613 record layer in AES-CCM mode and routed via IP-multicast. Each device 614 in the group uses a CCM nonce composed of a fixed common part (the 615 content type from the DTLS record layer and the group identifier) and 616 a variable part (the epoch and sequence number fields in the DTLS 617 record layer). This ensures a unique nonce for each message [RFC3610] 618 in the context of a same key. 620 5 Implementation and Evaluation 622 This section describes the prototype of our security solution and 623 evaluates the memory and communication overheads. 625 5.1 Prototype Implementation 627 The prototype is written in C and run as an application on Contiki OS 628 2.5 [Dunkels-contiki], an event-driven open source operating system 629 for constrained devices. They were tested in the Cooja simulator and 630 then ported to run on Redbee Econotag hardware, which features a 32- 631 bit CPU, 128 KB of ROM, 128 KB of RAM, and an IEEE 802.15.4 enabled- 632 radio with an AES hardware coprocessor. The prototype comprises all 633 necessary functionalities to adapt to the roles as a domain manager 634 or a joining device. 636 The prototype is based on the "TinyDTLS" [Bergmann-Tinydtls] library 637 and includes most of the extensions defined in Section 4 and the 638 adaptation as follows: 640 (1) We disabled the cookie mechanism in order to fit messages 641 to the available packet sizes and hence reducing the total 642 number of messages when performing the DTLS handshake. 644 (2) We used separate delivery instead of flight grouping of 645 messages and redesigned the retransmission mechanism 646 accordingly. 648 (3) We modified the "TinyDTLS" AES-CCM module to use the AES 649 hardware coprocessor. 651 (4) The Relay Element functionality for multi-hop scenario has 652 not been implemented. 654 (5) We expanded the DTLS state machine with the necessary 655 additions for our key management solution. 657 The following subsections further analyze the memory and 658 communication overhead of the solution in a single-hop scenario. 660 5.2 Memory Consumption 662 Table 1 presents the codesize and memory consumption of the prototype 663 differentiating (i) the state machine for the handshake, (ii) the 664 cryptographic primitives, (iii) the key management functionality and 665 (iv) the DTLS record layer mechanism for secure multicast 666 communications. 668 The use of DTLS appears to incur large memory footprint both in ROM 669 and RAM for two reasons. First, DTLS handshake defines many message 670 types and this adds more complexity to its corresponding state 671 machine. The logic for message re-ordering and retransmission also 672 contribute to the complexity of the DTLS state machine. Second, DTLS 673 uses SHA2-based crypto suites which is not available from the 674 hardware crypto co-processor. 676 +----------------------+-----------------+ 677 | | DTLS | 678 | +--------+--------+ 679 | | ROM | RAM | 680 +----------------------+--------+--------+ 681 | State Machine | 8.15 | 1.9 | 682 | Cryptography | 3.3 | 1.5 | 683 | Key Management | 1.0 | 0.0 | 684 | DTLS Record Layer | 3.7 | 0.5 | 685 +----------------------+--------+--------+ 686 | TOTAL | 16.15 | 3.9 | 687 +----------------------+--------+--------+ 688 Table 1: Memory Requirements in KB 690 5.3 Communication Overhead 692 We evaluated the communication overhead in the context of "network 693 access" and multicast "key management". In particular, we examine the 694 message overhead and the number of exchanged bytes under ideal 695 condition without any packet loss in a single-hop scenario, i.e., 696 domain manager and a joining device are in communication range. 698 +-------------------------------+--------+ 699 | | DTLS | 700 +-------------------------------+--------+ 701 | No. of Message | 12 | 702 | No. of round trips | 4 | 703 +-------------------------------+--------+ 704 | 802.15.4 headers | 168B | 705 | 6LowPAN headers | 480B | 706 | UDP headers | 96B | 707 | Application | 487B | 708 +-------------------------------+--------+ 709 | TOTAL | 1231B | 710 +-------------------------------+--------+ 711 Table 2: Communication overhead for Network 712 Access and Multicast Key Management 714 Table 2 summarizes the required number of round trips, number of 715 messages and the total exchanged bytes for the DTLS-based handshake 716 carried out in ideal conditions, i.e., in a network without packet 717 losses. DTLS handshake is considered complex as it involves the 718 exchange of 12 messages to complete the handshake. Further, DTLS runs 719 on top the transport layer, i.e., UDP, and hence this directly 720 increases the overhead due to lower layer per-packet protocol 721 headers. 723 5.4 Message Delay, Success Rate and Bandwidth 724 Section 5.3 provided an evaluation of the protocol in an ideal 725 condition, thus establishing the the baseline protocol overhead. We 726 further examined and simulated the protocol behavior by tuning the 727 packet loss ratio. In particular, we examined the impact of packet 728 loss on message delay, success rate and number of messages exchanged 729 in the handshake. 731 We consider a complete handshake to include the protocols to perform 732 "network access" and "multicast key management". Figure 4 shows the 733 percentage of successful handshakes as a function of timeouts and 734 packet loss ratios. As expected, a higher packet loss ratio and 735 smaller timeout (15s timeout) result in a failure probability of 736 completing the DTLS handshake. When the packet loss ratio reaches 737 0.5, practically no DTLS handshake would be successful. 739 100 |+ 740 P | + 741 E 80 | ++ 742 R | ++ 743 C 60 | + 744 E | + 745 N 40 | + 746 T | ++ 747 A 20 | + 748 G | +++++ 749 E 0 +------------------++++++++--> 750 0 0.1 0.2 0.3 0.4 0.5 752 packet loss ratio (15s timeout) 754 Figure 4: Average % of successful handshakes 756 Delays in network access and communication are intolerable since they 757 lead to higher resource consumption. As the solution relies on PSK, 758 the handshake protocol only incurs a short delay of a few 759 milliseconds when there is no packet loss. However, as the packet 760 loss ratio increases, the delay in completing the handshake becomes 761 significant because loss packets must be retransmitted. Our 762 implementation shows that with a packet loss ratio of 0.5, the the 763 times to perform network access and multicast key management could 764 take up to 24s. 766 Finally, another important criterion is the number of messages 767 exchanged in the presence of packet loss. A successful handshake 768 could incur up to 35 or more messages to be transmitted when the 769 packet loss ratio reaches 0.5. This is mainly because the DTLS 770 retransmission is complex and often requires re-sending multiple 771 messages even when only a single message has been lost. 773 6. Conclusions and future work 775 This Internet Draft presented an approach to secure the IP-based 776 Internet of Things using DTLS with the focus on (i) secure network 777 access, (ii) key management, and (iii) secure uni- and multicast 778 communication. Apart from secure unicast communication with DTLS, 779 there are no standard IP solutions in IETF for these unavoidable 780 problems when deploying an IoT network. We have shown that the 781 existing IP-based security protocol, i.e., DTLS can be used and 782 adapted to cater for low resource devices (bandwidth, memory and CPU) 783 and new communication patterns such as multicast and multi-hop 784 network access. 786 As a proof of concept, we implemented the an architecture based on 787 DTLS over Contiki OS running on a Redbee Econotag. Our work has shown 788 that the re-use of the existing standardized DTLS protocol to solve 789 these problems with a compromise in efficiency is feasible. We hope 790 that our work provides valuable protocol designs and evaluation 791 results (with their pros and cons) which can provide the much needed 792 direction for the standardization effort in IETF to ensure best 793 solutions are adopted. 795 7 Security Considerations 797 This document discusses various design aspects for of DTLS 798 implementations. As such this document, in entirety, concerns 799 security. 801 8 IANA Considerations 803 tbd 805 9. Acknowledgements 807 The authors greatly acknowledge discussion, comments and feedback 808 from Dee Denteneer and Jan Henrik Ziegeldorf. We also appreciate the 809 prototyping and implementation efforts by Pedro Moreno-Sanchez and 810 Francisco Vidal-Meca who worked as interns at Philips Research. 812 10 References 814 10.1 Normative References 816 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 817 Security", RFC 4347, April 2006. 819 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 820 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 821 August 2004. 823 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 824 Text on Security Considerations", BCP 72, RFC 3552, July 825 2003. 827 [RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key 828 Ciphersuites for Transport Layer Security (TLS)", 829 RFC 4279, December 2005. 831 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 832 CBC-MAC (CCM)", RFC 3610, September 2003. 834 9.2 Informative References 836 [I-D.ietf-core-coap] 837 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 838 "Constrained Application Protocol (CoAP)", draft-ietf- 839 core-coap-12 (work in progress), October 2012. 841 [I-D.alexander-roll-mikey] 842 Alexander, R., and Tsao, T. "Adapted Multimedia Internet 843 KEYing (AMIKEY): An extension of Multimedia Internet 844 KEYing (MIKEY) Methods for Generic LLN Environments", 845 draft-alexander-roll-mikey-lln-key-mgmt-04 (work-in- 846 progress), September 2012. 848 [Blundo-polynomial] 849 Blundo, C., De Santis, A., Herzberg, A., Kutten, S., 850 Vaccaro, U., and Yung, M. "Perfectly-Secure Key 851 Distribution for Dynamic Conferences", Advances in 852 Cryptology (CRYPTO'92), 1993. 854 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and 855 Yegin, A. "Protocol for Carrying Authentication for 856 Network Access (PANA) Relay Element", RFC 6345, August 857 2011. 859 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and Bormann, C. 860 "Neighbor Discovery Optimization for IPv6 over Low-Power 861 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 862 November 2012. 864 [I-D.keoh-multicast-security] 865 Keoh, S., Garcia-Morchon, O., and Kumar, S. "DTLS-based 866 Multicast Security for Low-Power and Lossy Networks 867 (LLNs)" (work-in-progress), October 2012. 869 [Dunkels-Contiki] 870 Dunkels, A., Gronvall, B., and Voigt, T. "Contiki - A 871 Lightweight and Flexible Operating System for Tiny 872 Networked Sensors", In Proceedings of the 29th Annual IEEE 873 International Conference on Local Computer Networks, IEEE, 874 2004. 876 [Bergmann-Tinydtls] Bergmann, O. "TinyDTLS - A Basic DTLS Server 877 Template", http://tinydtls.sourceforge.net, 2012. 879 Authors' Addresses 881 Sye Loong Keoh 882 University of Glasgow 883 Republic PolyTechnic, 9 Woodlands Ave 9 884 Singapore 838964 885 SG 887 Email: SyeLoong.Keoh@glasgow.ac.uk 889 Sandeep S. Kumar 890 Philips Research 891 High Tech Campus 34 892 Eindhoven 5656 AE 893 NL 895 Email: sandeep.kumar@philips.com 897 Oscar Garcia-Morchon 898 Philips Research 899 High Tech Campus 34 900 Eindhoven 5656 AE 901 NL 903 Email: oscar.garcia@philips.com