idnits 2.17.1 draft-irtf-t2trg-iot-seccons-06.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 (September 19, 2017) is 2410 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-07 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-12 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-07 == Outdated reference: A later version (-11) exists of draft-sarikaya-t2trg-sbootstrapping-03 == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-02 == Outdated reference: A later version (-25) exists of draft-ietf-opsawg-mud-10 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-04 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-11 == Outdated reference: A later version (-16) exists of draft-ietf-core-senml-10 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Garcia-Morchon 3 Internet-Draft Philips IP&S 4 Intended status: Informational S. Kumar 5 Expires: March 23, 2018 Philips Research 6 M. Sethi 7 Ericsson 8 September 19, 2017 10 State-of-the-Art and Challenges for the Internet of Things Security 11 draft-irtf-t2trg-iot-seccons-06 13 Abstract 15 The Internet of Things (IoT) concept refers to the usage of standard 16 Internet protocols to allow for human-to-thing and thing-to-thing 17 communication. The security needs for the IoT are well-recognized 18 and many standardization steps for providing security have been 19 taken, for example, the specification of Constrained Application 20 Protocol (CoAP) over Datagram Transport Layer Security (DTLS). 21 However, security challenges still exist and there are some use cases 22 that lack a suitable solution. In this document, we first discuss 23 the various stages in the lifecycle of a thing. Next, we document 24 the various security threats to a thing and the challenges that one 25 might face to protect against these threats. Lastly, we discuss the 26 next steps needed to facilitate the deployment of secure IoT systems. 28 This document is a product of the IRTF Thing-to-Thing Research Group 29 (T2TRG). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 23, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Motivation and background . . . . . . . . . . . . . . . . . . 4 67 2.1. The Thing Lifecycle . . . . . . . . . . . . . . . . . . . 4 68 2.2. Security building blocks . . . . . . . . . . . . . . . . 5 69 3. Security Threats and Managing Risk . . . . . . . . . . . . . 9 70 4. State-of-the-Art . . . . . . . . . . . . . . . . . . . . . . 13 71 4.1. IP-based IoT Protocols and Standards . . . . . . . . . . 13 72 4.2. Existing IP-based Security Protocols and Solutions . . . 16 73 4.3. IoT Security Guidelines . . . . . . . . . . . . . . . . . 19 74 5. Challenges for a Secure IoT . . . . . . . . . . . . . . . . . 22 75 5.1. Constraints and Heterogeneous Communication . . . . . . . 22 76 5.1.1. Resource Constraints . . . . . . . . . . . . . . . . 23 77 5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . 24 78 5.1.3. End-to-end security, protocol translation, and the 79 role of middleboxes . . . . . . . . . . . . . . . . . 24 80 5.1.4. New network architectures and paradigm . . . . . . . 26 81 5.2. Bootstrapping of a Security Domain . . . . . . . . . . . 27 82 5.3. Operational Challenges . . . . . . . . . . . . . . . . . 27 83 5.3.1. Group Membership and Security . . . . . . . . . . . . 27 84 5.3.2. Mobility and IP Network Dynamics . . . . . . . . . . 28 85 5.4. Software update . . . . . . . . . . . . . . . . . . . . . 29 86 5.5. Verifying device behavior . . . . . . . . . . . . . . . . 30 87 5.6. End-of-Life . . . . . . . . . . . . . . . . . . . . . . . 31 88 5.7. Testing: bug hunting and vulnerabilities . . . . . . . . 31 89 5.8. Quantum-resistance . . . . . . . . . . . . . . . . . . . 31 90 5.9. Privacy protection . . . . . . . . . . . . . . . . . . . 32 91 5.10. Data leakage . . . . . . . . . . . . . . . . . . . . . . 33 92 5.11. Trustworthy IoT Operation . . . . . . . . . . . . . . . . 34 93 6. Conclusions and Next Steps . . . . . . . . . . . . . . . . . 34 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 97 10. Informative References . . . . . . . . . . . . . . . . . . . 35 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 100 1. Introduction 102 The Internet of Things (IoT) denotes the interconnection of highly 103 heterogeneous networked entities and networks that follow a number of 104 different communication patterns such as: human-to-human (H2H), 105 human-to-thing (H2T), thing-to-thing (T2T), or thing-to-things 106 (T2Ts). The term IoT was first coined by the Auto-ID center 107 [AUTO-ID] in 1999 which had envisioned a world where every physical 108 object is tagged with a radio-frequency identification (RFID) tag 109 having a globally unique identifier. This would not only allow 110 tracking of objects in real-time but also allow querying of data 111 about them over the Internet. However, since then, the meaning of 112 the Internet of Things has expanded and now encompasses a wide 113 variety of technologies, objects and protocols. It is not surprising 114 that the IoT has received significant attention from the research 115 community to (re)design, apply, and use standard Internet technology 116 and protocols for the IoT. 118 The things that are part of the Internet of Things are no longer 119 unresponsive and have transformed into computing devices that 120 understand and react to the environment they reside in. These things 121 are also often referred to as smart objects or smart devices. 123 The introduction of IPv6 [RFC6568] and CoAP [RFC7252] as fundamental 124 building blocks for IoT applications allows connecting IoT hosts to 125 the Internet. This brings several advantages including: (i) a 126 homogeneous protocol ecosystem that allows simple integration with 127 other Internet hosts; (ii) simplified development for devices that 128 significantly vary in their capabilities; (iii) a unified interface 129 for applications, removing the need for application-level proxies. 130 These building blocks greatly simplify the deployment of the 131 envisioned scenarios which range from building automation to 132 production environments and personal area networks. 134 This document presents an overview of important security aspects for 135 the Internet of Things. We begin by discussing the lifecycle of a 136 thing and giving general definitions of the security building blocks 137 in Section 2. In Section 3, we discuss security threats for the IoT 138 and methodologies for managing these threats when designing a secure 139 system. Section 4 reviews existing IP-based (security) protocols for 140 the IoT and briefly summarizes existing guidelines and regulations. 141 Section 5 identifies remaining challenges for a secure IoT and 142 discusses potential solutions. Section 6 includes final remarks and 143 conclusions. 145 The first draft version of this document was submitted in March 2011. 146 Initial draft versions of this document were presented and discussed 147 during the CORE meetings at IETF 80 and later. Discussions on 148 security lifecycle at IETF 92 (March 2015) evolved into more general 149 security considerations. Thus, the draft was selected to address the 150 T2TRG work item on the security considerations and challenges for the 151 Internet of Things. Further updates of the draft were presented and 152 discussed during the T2TRG meetings at IETF 96 (July 2016) and IETF 153 97 (November 2016) and at the joint interim in Amsterdam (March 154 2017). This document has been reviewed by, commented on, and 155 discussed extensively for a period of nearly six years by a vast 156 majority of T2TRG and related group members; the number of which 157 certainly exceeds 100 individuals. It is the consensus of T2TRG that 158 the security considerations described in this document should be 159 published in the IRTF Stream of the RFC series. This document does 160 not constitute a standard. 162 2. Motivation and background 164 2.1. The Thing Lifecycle 166 The lifecycle of a thing refers to the operational phases of a thing 167 in the context of a given application or use case. Figure 1 shows 168 the generic phases of the lifecycle of a thing. This generic 169 lifecycle is applicable to very different IoT applications and 170 scenarios. For instance, [RFC7744] provides an overview of relevant 171 IoT use cases. 173 In this document, we consider a Building Automation and Control (BAC) 174 system to illustrate the lifecycle and the meaning of these different 175 phases. A BAC system consists of a network of interconnected nodes 176 that performs various functions in the domains of HVAC (Heating, 177 Ventilating, and Air Conditioning), lighting, safety, etc. The nodes 178 vary in functionality and a large majority of them represent 179 resource-constrained devices such as sensors and luminaries. Some 180 devices may be battery operated or may rely on energy harvesting. 181 This requires us to also consider devices that sleep during their 182 operation to save energy. In our example, the life of a thing starts 183 when it is manufactured. Due to the different application areas 184 (i.e., HVAC, lighting, or safety) nodes/things are tailored to a 185 specific task. It is therefore unlikely that one single manufacturer 186 will create all nodes in a building. Hence, interoperability as well 187 as trust bootstrapping between nodes of different vendors is 188 important. 190 The thing is later installed and commissioned within a network by an 191 installer during the bootstrapping phase. Specifically, the device 192 identity and the secret keys used during normal operation may be 193 provided to the device during this phase. Different subcontractors 194 may install different IoT devices for different purposes. 195 Furthermore, the installation and bootstrapping procedures may not be 196 a discrete event and may stretch over an extended period. After 197 being bootstrapped, the device and the system of things are in 198 operational mode and execute the functions of the BAC system. During 199 this operational phase, the device is under the control of the system 200 owner and used by multiple system users. For devices with lifetimes 201 spanning several years, occasional maintenance cycles may be 202 required. During each maintenance phase, the software on the device 203 can be upgraded or applications running on the device can be 204 reconfigured. The maintenance tasks can be performed either locally 205 or from a backend system. Depending on the operational changes to 206 the device, it may be required to re-bootstrap at the end of a 207 maintenance cycle. The device continues to loop through the 208 operational phase and the eventual maintenance phases until the 209 device is decommissioned at the end of its lifecycle. However, the 210 end-of-life of a device does not necessarily mean that it is 211 defective and rather denotes a need to replace and upgrade the 212 network to the next-generation devices for additional functionality. 213 Therefore, the device can be removed and re-commissioned to be used 214 in a different system under a different owner thereby starting the 215 lifecycle all over again. 217 _Manufactured _SW update _Decommissioned 218 / / / 219 | _Installed | _ Application | _Removed & 220 | / | / reconfigured | / replaced 221 | | _Commissioned | | | | 222 | | / | | | | _Reownership & 223 | | | _Application | | _Application | | / recommissioned 224 | | | / running | | / running | | | 225 | | | | | | | | | | \\ 226 +##+##+###+#############+##+##+#############+##+##+##############>>> 227 \/ \______________/ \/ \_____________/ \___/ time // 228 / / \ \ \ 229 Bootstrapping / Maintenance & \ Maintenance & 230 / re-bootstrapping \ re-bootstrapping 231 Operational Operational 233 Figure 1: The lifecycle of a thing in the Internet of Things 235 2.2. Security building blocks 237 Security is a key requirement in any communication system. However, 238 security is an even more critical requirement in real-world IoT 239 deployments for several reasons. First, compromised IoT systems can 240 not only endanger the privacy and security of a user, but can also 241 cause physical harm. This is because IoT systems often comprise 242 sensors, actuators and other connected devices in the physical 243 environment of the user which could adversely affect the user if they 244 are compromised. Second, a vulnerable IoT system means that an 245 attacker can alter the functionality of a device from a given 246 manufacturer. This not only affects the manufacturer's brand image, 247 but can also leak information that is very valuable for the 248 manufacturer (such as proprietary algorithms). Third, the impact of 249 attacking an IoT system goes beyond a specific device or an isolated 250 system since compromised IoT systems can be misused at scale. For 251 example, they may be used to perform a Distributed Denial of Service 252 (DDoS) attack that limits the availability of other networks and 253 services. The fact that many IoT systems rely on standard IP 254 protocols allows for easier system integration, but this also makes 255 standard attacks applicable to a wide number of devices deployed in 256 multiple systems. This results in new requirements regarding the 257 implementation of security. 259 The term security subsumes a wide range of primitives, protocols, and 260 procedures. Firstly, it includes the basic provision of security 261 services that include confidentiality, authentication, integrity, 262 authorization, non-repudiation, and availability along with some 263 augmented services, such as duplicate detection and detection of 264 stale packets (timeliness). These security services can be 265 implemented by means of a combination of cryptographic mechanisms, 266 such as block ciphers, hash functions, or signature algorithms, and 267 non-cryptographic mechanisms, which implement authorization and other 268 security policy enforcement aspects. For ensuring security in IoT 269 networks, we should not only focus on the required security services, 270 but also pay special attention to how these services are realized in 271 the overall system and how the security functionalities are executed 272 in practice. To this end, we consider five major "building blocks" 273 to analyze and classify security aspects for IoT: 275 1. IoT security architecture: refers to the system-level elements 276 involved in the management of security relationships between 277 things (for example, centralized or distributed). For instance, 278 a smart home could rely on a centralized key distribution center 279 in charge of managing cryptographic keys, devices, users, access 280 control and privacy policies. 282 2. The security model within a thing: describes the way security 283 parameters, keys, processes, and applications are managed within 284 a smart object. This includes aspects such as application 285 process separation, secure storage of key materials, etc. For 286 instance, some smart objects might have extremely limited 287 resources and limited capabilities to protect secret keys. In 288 contrast, other devices used in critical applications, such as a 289 pacemaker, may rely on methods to protect cryptographic keys and 290 functionality. 292 3. Security bootstrapping: denotes the process by which a thing 293 securely joins an IoT system at a given location and point of 294 time. For instance, bootstrapping of a connected camera can 295 include the authentication and authorization of the device as 296 well as the transfer of security parameters necessary for 297 operation in a given network. 299 4. Network security: describes the mechanisms applied within a 300 network to ensure secure operation. Specifically, it prevents 301 attackers from endangering or modifying the expected operation of 302 a smart object. It also protects the network itself from 303 malicious things. Network security can include several 304 mechanisms ranging from data link layer security, secure routing, 305 and network layer security. 307 5. Application security: describes mechanisms to allow secure 308 transfer of application data. The security may be implemented at 309 different layers of the Internet protocol suite. For instance, 310 assume a smart object such as an environmental sensor that is 311 connected to a backend system. Application security here can 312 refer to the exchange of secure blocks of data such as 313 measurements between the sensor and the backed, or it can also 314 refer to a software update for the smart object. This data is 315 exchanged end-to-end independently of the underlying network 316 infrastructure, for example through proxies or other store-and- 317 forward mechanisms. 319 .......................... 320 : +-----------+: 321 : *+*>|Application|***** 322 : *| +-----------+: * 323 : *| +-----------+: * 324 : *|->| Transport |: * 325 : * _*| +-----------+: * 326 : *| | +-----------+: * 327 : *| |->| Network |: * 328 : *| | +-----------+: * 329 : *| | +-----------+: * *** Bootstrapping 330 : *| +->| L2 |: * ~~~ Transport Security 331 : *| +-----------+: * ''' Object Security 332 :+--------+ : * 333 :|Security| Configuration: * 334 :|Service | Entity : * 335 :+--------+ : * 336 :........................: * 337 * 338 ......................... * ......................... 339 :+--------+ : * : +--------+: 340 :|Security| Node B : * : Node A |Security|: 341 :|Service | : * : |Service |: 342 :+--------+ : * : +--------+: 343 : | +-----------+: * :+-----------+ |* : 344 : | +->|Application|: ****|Application|<*+* |* : 345 : | | +-----------+:''''''''''''''''''''+-----------+ |* |* : 346 : | | +-----------+: :+-----------+ |* |* : 347 : | |->| Transport |~~~~~~~~~~~~~~~~~~~~~| Transport |<-|* |* : 348 : |__| +-----------+: ................. :+-----------+ |*_|* : 349 : | +-----------+: : +-----------+ : :+-----------+ | * : 350 : |->| Network |: : | Network | : :| Network |<-| : 351 : | +-----------+: : +-----------+ : :+-----------+ | : 352 : | +-----------+: : +-----------+ : :+-----------+ | : 353 : +->| L2 |: : | L2 | : :| L2 |<-+ : 354 : +-----------+: : +-----------+ : :+-----------+ : 355 :.......................: :...............: :.......................: 357 Figure 2: Overview of Security Mechanisms 359 Inspired by the security framework for routing over low power and 360 lossy network [RFC7416], we show an example security model of a smart 361 object and illustrate how different security concepts and lifecycle 362 phases map to the Internet communication stack. Assume a centralized 363 architecture in which a configuration entity stores and manages the 364 identities of the things associated with the system along with their 365 cryptographic keys. During the bootstrapping phase, each thing 366 executes the bootstrapping protocol with the configuration entity, 367 thus obtaining the required device identities and the keying 368 material. The security service on a thing in turn stores the 369 received keying material for the network layer and application 370 security mechanisms for secure communication. Things can then 371 securely communicate with each other during their operational phase 372 by means of the employed network and application security mechanisms. 374 3. Security Threats and Managing Risk 376 Security threats in related IP protocols have been analyzed in 377 multiple documents including HTTPS [RFC2818], COAP [RFC7252], 6LoWPAN 378 [RFC4919], ANCP [RFC5713], DNS security threats [RFC3833], IPv6 ND 379 [RFC3756], and PANA [RFC4016]. In this section, we specifically 380 discuss the threats that could compromise an individual thing, or the 381 network as a whole. Note that these set of threats might go beyond 382 the scope of Internet protocols but we gather them here for the sake 383 of completeness. We also note that these threats can be classified 384 according to either (i) the thing's lifecycle phases (when does the 385 threat occur?) or (ii) the security building blocks (which 386 functionality is affected by the threat?). All these threats are 387 summarized in Figure 3. 389 1. Cloning of things: During the manufacturing process of a thing, 390 an untrusted factory can easily clone the physical 391 characteristics, firmware/software, or security configuration of 392 the thing. Deployed things might also be compromised and their 393 software reverse engineered allowing for cloning or software 394 modifications. Such a cloned thing may be sold at a cheaper 395 price in the market, and yet can function normally as a genuine 396 thing. For example, two cloned devices can still be associated 397 and work with each other. In the worst-case scenario, a cloned 398 device can be used to control a genuine device or perform an 399 attack. One should note here, that an untrusted factory may also 400 change functionality of the cloned thing, resulting in degraded 401 functionality with respect to the genuine thing (thereby, 402 inflicting potential damage to the reputation of the original 403 thing manufacturer). Moreover, additional functionality can be 404 introduced in the cloned thing, an example of such functionality 405 is a backdoor. 407 2. Malicious substitution of things: During the installation of a 408 thing, a genuine thing may be substituted with a similar variant 409 (of lower quality) without being detected. The main motivation 410 may be cost savings, where the installation of lower-quality 411 things (for example, non-certified products) may significantly 412 reduce the installation and operational costs. The installers 413 can subsequently resell the genuine things to gain further 414 financial benefits. Another motivation may be to inflict damage 415 to the reputation of a competitor's offerings. 417 3. Eavesdropping attack: During the commissioning of a thing into a 418 network, it may be susceptible to eavesdropping, especially if 419 operational keying materials, security parameters, or 420 configuration settings, are exchanged in clear using a wireless 421 medium or if used cryptographic algorithms are not suitable for 422 the envisioned lifetime of the device and the system. After 423 obtaining the keying material, the attacker might be able to 424 recover the secret keys established between the communicating 425 entities, thereby compromising the authenticity and 426 confidentiality of the communication channel, as well as the 427 authenticity of commands and other traffic exchanged over this 428 communication channel. When the network is in operation, T2T 429 communication may be eavesdropped upon if the communication 430 channel is not sufficiently protected or in the event of session 431 key compromise due to protocol weaknesses or a long period of 432 usage without key renewal or updates. 434 4. Man-in-the-middle attack: Both the commissioning phase and 435 operational phases may also be vulnerable to man-in-the-middle 436 attacks, for example, when keying material between communicating 437 entities is exchanged in the clear and the security of the key 438 establishment protocol depends on the tacit assumption that no 439 third party can eavesdrop during the execution of this protocol. 440 Additionally, device authentication or device authorization may 441 be non-trivial, or may need support of a human decision process, 442 since things usually do not have a-priori knowledge about each 443 other and cannot always differentiate friends and foes via 444 completely automated mechanisms. Thus, even if the key 445 establishment protocol provides cryptographic device 446 authentication, this knowledge on device identities may still 447 need complementing with a human-assisted authorization step 448 (thereby, presenting a weak link and offering the potential of 449 man-in-the-middle attacks this way). 451 5. Firmware attacks: When a thing is in operation or maintenance 452 phase, its firmware or software may be updated to allow for new 453 functionality or new features. An attacker may be able to 454 exploit such a firmware upgrade by replacing the thing's software 455 with malicious software, thereby influencing the operational 456 behavior of the thing. For example, an attacker could add a 457 piece of malicious code to the firmware that will cause it to 458 periodically report the energy usage of the lamp to a data 459 repository for analysis. Similarly, devices whose software has 460 not been properly maintained and updated might contain 461 vulnerabilities that might be exploited by attackers to replace 462 the firmware on the device. 464 6. Extraction of private information: IoT devices (such as sensors, 465 actuators, etc.) are often physically unprotected in their 466 ambient environment and they could easily be captured by an 467 attacker. An attacker with physical access may then attempt to 468 extract private information such as keys (for example, device's 469 key, private-key, group key), sensed data (for example, 470 healthcare status of a user), configuration parameters (for 471 example, the Wi-Fi key), or proprietary algorithms (for example, 472 algorithm performing some data analytics task). Even when the 473 data originating from a thing is encrypted, attackers can perform 474 traffic analysis to deduce meaningful information which might 475 compromise the privacy of the thing's owner and/or user. 477 7. Routing attack: As highlighted in [ID-Daniel], routing 478 information in IoT can be spoofed, altered, or replayed, in order 479 to create routing loops, attract/repel network traffic, extend/ 480 shorten source routes, etc. Other relevant routing attacks 481 include 1) Sinkhole attack (or blackhole attack), where an 482 attacker declares himself to have a high-quality route/path to 483 the base station, thus allowing him to do manipulate all packets 484 passing through it. 2) Selective forwarding, where an attacker 485 may selectively forward packets or simply drop a packet. 3) 486 Wormhole attack, where an attacker may record packets at one 487 location in the network and tunnel them to another location, 488 thereby influencing perceived network behavior and potentially 489 distorting statistics, thus greatly impacting the functionality 490 of routing. 4) Sybil attack, whereby an attacker presents 491 multiple identities to other things in the network. 493 8. Privacy threat: The tracking of a thing's location and usage may 494 pose a privacy risk to its users. For instance, an attacker can 495 infer information based on the information gathered about 496 individual things, thus deducing behavioral patterns of the user 497 of interest to him. Such information may subsequently be sold to 498 interested parties for marketing purposes and targeted 499 advertising. In extreme cases, such information might be used to 500 track dissidents in oppressive regimes. 502 9. Denial-of-Service (DoS) attack: Often things have very limited 503 memory and computation capabilities. Therefore, they are 504 vulnerable to resource exhaustion attack. Attackers can 505 continuously send requests to specific things so as to deplete 506 their resources. This is especially dangerous in the Internet of 507 Things since an attacker might be located in the backend and 508 target resource-constrained devices that are part of a 509 constrained node network [RFC7228]. DoS attack can also be 510 launched by physically jamming the communication channel. 511 Network availability can also be disrupted by flooding the 512 network with a large number of packets. On the other hand, 513 things compromised by attackers can be used to disrupt the 514 operation of other networks or systems by means of a Distributed 515 DoS (DDoS) attack. 517 The following table summarizes the above generic security threats and 518 the potential point of vulnerabilities at different layers of the 519 communication stack. We also include related documents that include 520 a threat model that might apply to the IoT. 522 +------------------+------------------+------------------+ 523 | Manufacturing | Installation/ | Operation | 524 | | Commissioning | | 525 +------------+------------------+------------------+------------------+ 526 |System-level| Device Cloning |Substitution |Privacy threat | 527 | | | |Extraction of | 528 | | | |private inform. | 529 +------------+------------------+------------------+------------------+ 530 |Application | |RFC2818, |RFC2818, Firmware | 531 |Layer | |RFC4016 |replacement | 532 +------------+------------------+------------------+------------------+ 533 |Transport | | Eavesdropping & |Eavesdropping | 534 |Layer | | Man-in-the-middle|Man-in-the-middle | 535 +------------+------------------| attack, |------------------+ 536 |Network | | RFC4919, RFC5713 |RFC4919,DoS attack| 537 |Layer | | RFC3833, RFC3756 |Routing attack | 538 | | | |RFC3833 | 539 +------------+------------------+------------------+------------------+ 540 |Physical | | |DoS attack | 541 |Layer | | | | 542 +-------------------------------+------------------+------------------+ 544 Figure 3: Classification of threats according to the lifecycle phases 546 Dealing with above threats and finding suitable security mitigations 547 is challenging. New threats and exploits also appear on a daily 548 basis. Therefore, the existence of proper secure product creation 549 processes that allow managing and minimizing risks during the 550 lifecycle of IoT devices is at least as important as being aware of 551 the threats. A non-exhaustive list of relevant processes include: 553 1. A Business Impact Analysis (BIA) assesses the consequences of the 554 loss of basic security attributes: confidentiality, integrity and 555 availability in an IoT system. These consequences might include 556 the impact from lost data, reduced sales, increased expenses, 557 regulatory fines, customer dissatisfaction, etc. Performing a 558 business impact analysis allows a business to determine the 559 relevance of having a proper security design. 561 2. A Risk Assessment (RA) analyzes security threats to an IoT system 562 while considering their likelihood and impact. It also includes 563 categorizing each of them with a risk level. Risks classified as 564 moderate or high must be mitigated, i.e., the security 565 architecture should be able to deal with those threat. 567 3. A privacy impact assessment (PIA) aims at assessing the 568 Personally Identifiable Information (PII) that is collected, 569 processed, or used in an IoT system. By doing so, the goal is to 570 fulfill applicable legal requirements, determine risks and 571 effects of manipulation and loss of PII. 573 4. Procedures for incident reporting and mitigation refer to the 574 methodologies that allow becoming aware of any security issues 575 that affect an IoT system. Furthermore, this includes steps 576 towards the actual deployment of patches that mitigate the 577 identified vulnerabilities. 579 BIA, RA, and PIA should generally be realized during the creation of 580 a new IoT system or when deploying significant system/feature 581 upgrades. In general, it is recommended to re-assess them on a 582 regular basis taking into account new use cases and/or threats. 584 4. State-of-the-Art 586 This section is organized as follows. Section 4.1 summarizes state- 587 of-the-art on IP-based IoT systems, within IETF and in other 588 standardization bodies. Section 4.2 summarizes state-of-the-art on 589 IP-based security protocols and their usage. Section 4.3 discusses 590 guidelines and regulations for securing IoT as proposed by other 591 bodies. 593 4.1. IP-based IoT Protocols and Standards 595 Nowadays, there exists a multitude of control protocols for IoT. For 596 BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI 597 [DALI] play key roles. Recent trends, however, focus on an all-IP 598 approach for system control. 600 In this setting, a number of IETF working groups are designing new 601 protocols for resource-constrained networks of smart things. The 602 6LoWPAN working group [WG-6LoWPAN] for example has defined methods 603 and protocols for the efficient transmission and adaptation of IPv6 604 packets over IEEE 802.15.4 networks [RFC4944]. 606 The CoRE working group [WG-CoRE] has specified the Constrained 607 Application Protocol (CoAP) [RFC7252]. CoAP is a RESTful protocol 608 for constrained devices that is modeled after HTTP and typically runs 609 over UDP to enable efficient application-level communication for 610 things. 612 In many smart object networks, the smart objects are dispersed and 613 have intermittent reachability either because of network outages or 614 because they sleep during their operational phase to save energy. In 615 such scenarios, direct discovery of resources hosted on the 616 constrained server might not be possible. To overcome this barrier, 617 the CoRE working group is specifying the concept of a Resource 618 Directory (RD) [ID-rd]. The Resource Directory hosts descriptions of 619 resources which are located on other nodes. These resource 620 descriptions are specified as CoRE link format [RFC6690]. 622 While CoAP defines a standard communication protocol, a format for 623 representing sensor measurements and parameters over CoAP is 624 required. The Sensor Measurement Lists (SenML) [ID-senml] is a 625 specification that defines media types for simple sensor measurements 626 and parameters. It has a minimalistic design so that constrained 627 devices with limited computational capabilities can easily encode 628 their measurements and, at the same time, servers can efficiently 629 collect large number of measurements. 631 In many IoT deployments, the resource-constrained smart objects are 632 connected to the Internet via a gateway that is directly reachable. 633 For example, an IEEE 802.11 Access Point (AP) typically connects the 634 client devices to the Internet over just one wireless hop. However, 635 some deployments of smart object networks require routing between the 636 smart objects themselves. The IETF has therefore defined the IPv6 637 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550]. 638 RPL provides support for multipoint-to-point traffic from resource- 639 constrained smart objects towards a more resourceful central control 640 point, as well as point-to-multipoint traffic in the reverse 641 direction. It also supports point-to-point traffic between the 642 resource-constrained devices. A set of routing metrics and 643 constraints for path calculation in RPL are also specified [RFC6551]. 645 The IPv6 over Networks of Resource-constrained Nodes (6lo) [WG-6lo] 646 working group of the IETF has specified how IPv6 packets can be 647 transmitted over various link layer protocols that are commonly 648 employed for resource-constrained smart object networks. There is 649 also ongoing work to specify IPv6 connectivity for a Non-Broadcast 650 Multi-Access (NBMA) mesh network that is formed by IEEE 802.15.4 651 TimeSlotted Channel Hopping (TSCH} links [ID-6tisch]. Other link 652 layer protocols for which IETF has specified or is currently 653 specifying IPv6 support include Bluetooth [RFC7668], Digital Enhanced 654 Cordless Telecommunications (DECT) Ultra Low Energy (ULE) air 655 interface [RFC8105], and Near Field Communication (NFC) [ID-6lonfc]. 657 [RFC6272] identifies IP protocols that can be used in smart grid 658 environments. It gives advice to smart grid network designers on how 659 they can decide on a profile of the Internet protocol suite for smart 660 grid networks. 662 JavaScript Object Notation (JSON) is a lightweight text 663 representation format for structured data [RFC7159]. It is often 664 used for transmitting serialized structured data over the network. 665 IETF has defined specifications for encoding public keys, signed 666 content, and claims to be transferred between two parties as JSON 667 objects. They are referred to as JSON Web Keys (JWK) [RFC7517], JSON 668 Web Signatures (JWS) [RFC7515] and JSON Web Token (JWT) [RFC7519]. 670 An alternative to JSON, Concise Binary Object Representation (CBOR) 671 [RFC7049] is a concise binary data format that is used for 672 serialization of structured data. It is designed for resource- 673 constrained nodes and therefore it aims to provide a fairly small 674 message size with minimal implementation code, and extensibility 675 without the need for version negotiation. CBOR Object Signing and 676 Encryption (COSE) [RFC8152] specifies how to encode public keys and 677 signed content with CBOR. 679 The Light-Weight Implementation Guidance (LWIG) working group 680 [WG-LWIG] is collecting experiences from implementers of IP stacks in 681 constrained devices. The working group has already produced 682 documents such as RFC7815 [RFC7815] which defines how a minimal 683 Internet Key Exchange Version 2 (IKEv2) initiator can be implemented. 685 The Thing-2-Thing Research Group (T2TRG) [RG-T2TRG] is investigating 686 the remaining research issues that need to be addressed to quickly 687 turn the vision of IoT into a reality where resource-constrained 688 nodes can communicate with each other and with other more capable 689 nodes on the Internet. 691 Additionally, industry alliances and other standardization bodies are 692 creating constrained IP protocol stacks based on the IETF work. Some 693 important examples of this include: 695 1. Thread [Thread]: Specifies the Thread protocol that is intended 696 for a variety of IoT devices. It is an IPv6-based network 697 protocol that runs over IEEE 802.15.4. 699 2. Industrial Internet Consortium [IIoT]: The consortium defines 700 reference architectures and security frameworks for development, 701 adoption and widespread use of Industrial Internet technologies 702 based on existing IETF standards. 704 3. Internet Protocol for Smart Objects IPSO [IPSO]: The alliance 705 specifies a common object model that enables application software 706 on any device to interoperate with other conforming devices. 708 4. OneM2M [OneM2M]: The standards body defines technical and API 709 specifications for IoT devices. It aims to create a service 710 layer that can run on any IoT device hardware and software. 712 5. Open Connectivity Foundation (OCF) [OCF]: The foundation develops 713 standards and certifications primarily for IoT devices that use 714 Constrained Application Protocol (CoAP) as the application layer 715 protocol. 717 6. Fairhair Alliance [Fairhair]: Specifies an IoT middleware to 718 enable interoperability between different application standards 719 used in building automation and lighting systems. 721 7. OMA LWM2M [LWM2M]: OMA Lightweight M2M is a standard from the 722 Open Mobile Alliance for M2M and IoT device management. LWM2M 723 relies on CoAP as the application layer protocol and uses a 724 RESTful architecture for remote management of IoT devices. 726 4.2. Existing IP-based Security Protocols and Solutions 728 There are thee main security objectives for IoT networks: 1. 729 protecting the IoT network from attackers. 2. protecting IoT 730 applications and thus, the things and users. 3. protecting the rest 731 of the Internet and other things from attacks that use compromised 732 things as an attack platform. 734 In the context of the IP-based IoT deployments, consideration of 735 existing Internet security protocols is important. There are a wide 736 range of specialized as well as general-purpose security solutions 737 for the Internet domain such as IKEv2/IPsec [RFC7296], TLS [RFC5246], 738 DTLS [RFC6347], HIP [RFC7401], PANA [RFC5191], and EAP [RFC3748]. 740 There is ongoing work to define an authorization and access-control 741 framework for resource-constrained nodes. The Authentication and 742 Authorization for Constrained Environments (ACE) [WG-ACE] working 743 group is defining a solution to allow only authorized access to 744 resources that are hosted on a smart object server and are identified 745 by a URI. The current proposal [ID-aceoauth] is based on the OAuth 746 2.0 framework [RFC6749] and it comes with profiles intended for 747 different communication scenarios, e.g. DTLS Profile for 748 Authentication and Authorization for Constrained Environments 749 [ID-acedtls]. 751 The CoAP base specification [RFC7252] provides a description of how 752 DTLS can be used for securing CoAP. It proposes three different 753 modes for using DTLS: the PreSharedKey mode, where nodes have pre- 754 provisioned keys for initiating a DTLS session with another node, 755 RawPublicKey mode, where nodes have asymmetric-key pairs but no 756 certificates to verify the ownership, and Certificate mode, where 757 public keys are certified by a certification authority. An IoT 758 implementation profile [RFC7925] is defined for TLS version 1.2 and 759 DTLS version 1.2 that offers communication security for resource- 760 constrained nodes. 762 Transport Layer Security (TLS) and its datagram-oriented variant DTLS 763 secure transport-layer connections. TLS provides security for TCP 764 and requires a reliable transport, while DTLS secures and uses 765 datagram-oriented protocols such as UDP. Both protocols are 766 intentionally kept similar and share the same ideology and cipher 767 suites. 769 OSCOAP [ID-OSCOAP] is a proposal that protects CoAP messages by 770 wrapping them in the CBOR Object Signing and Encryption (COSE) 771 [RFC8152] format. Thus, OSCOAP falls in the category of object 772 security and it can be applied wherever CoAP can. The advantage of 773 OSCOAP compared with DTLS resides in some more flexibility when 774 dealing with e2e security as it will be discussed in 775 Section Section 5.1.3. 777 The Automated Certificate Management Environment (ACME) [WG-ACME] 778 working group is specifying conventions for automated X.509 779 certificate management. This includes automatic validation of 780 certificate issuance, certificate renewal, and certificate 781 revocation. While the initial focus of working group is on domain 782 name certificates (as used by web servers), other uses in some IoT 783 deployments is possible. 785 The Internet Key Exchange (IKEv2)/IPsec and the Host Identity 786 protocol (HIP) reside at or above the network layer in the OSI model. 787 Both protocols are able to perform an authenticated key exchange and 788 set up the IPsec for secure payload delivery. Currently, there are 789 also ongoing efforts to create a HIP variant coined Diet HIP 790 [ID-HIP-DEX] that takes constrained networks and nodes into account 791 at the authentication and key exchange level. 793 Migault et al. [ID-dietesp] are working on a compressed version of 794 IPsec so that it can easily be used by resource-constrained IoT 795 devices. They rely on the Internet Key Exchange Protocol version 2 796 (IKEv2) for negotiating the compression format. 798 The Extensible Authentication Protocol (EAP) is an authentication 799 framework supporting multiple authentication methods. EAP runs 800 directly over the data link layer and, thus, does not require the 801 deployment of IP. It supports duplicate detection and 802 retransmission, but does not allow for packet fragmentation. The 803 Protocol for Carrying Authentication for Network Access (PANA) is a 804 network-layer transport for EAP that enables network access 805 authentication between clients and the network infrastructure. In 806 EAP terms, PANA is a UDP-based EAP lower layer that runs between the 807 EAP peer and the EAP authenticator. 809 Figure 4 depicts the relationships between the discussed protocols in 810 the context of the security terminology introduced in Section 2. 812 .......................... 813 : +-----------+: 814 : *+*>|Application|***** *** Bootstrapping 815 : *| +-----------+: * ### Transport Security 816 : *| +-----------+: * === Network security 817 : *|->| Transport |: * ''' Object security 818 : * _*| +-----------+: * 819 : *| | +-----------+: * 820 : *| |->| Network |: *--> -PANA/EAP 821 : *| | +-----------+: * -HIP 822 : *| | +-----------+: * 823 : *| +->| L2 |: * ## DTLS 824 : *| +-----------+: * '' OSCOAP 825 :+--------+ : * 826 :|Security| Configuration: * [] HIP,IKEv2 827 :|Service | Entity : * [] ESP/AH 828 :+--------+ : * 829 :........................: * 830 * 831 ......................... * ......................... 832 :+--------+ : * : +--------+: 833 :|Security| Node B : Secure * : Node A |Security|: 834 :|Service | : routing * : |Service |: 835 :+--------+ : framework * : +--------+: 836 : | +-----------+: | **** :+-----------+ |* : 837 : | +->|Application|:''''''''|'''''''''''':|Application|<*+* |* : 838 : | | +----##-----+: | :+----##-----+ |* |* : 839 : | | +----##-----+: | :+----##-----+ |* |* : 840 : | |->| Transport |#########|#############| Transport |<-|* |* : 841 : |__| +----[]-----+: ......|.......... :+----[]-----+ |*_|* : 842 : | +====[]=====+=====+===========+=====+====[]=====+ | * : 843 : |->|| Network |: : | Network | : :| Network ||<-| : 844 : | +|----------+: : +-----------+ : :+----------|+ | : 845 : | +|----------+: : +-----------+ : :+----------|+ | : 846 : +->|| L2 |: : | L2 | : :| L2 ||<-+ : 847 : +===========+=====+===========+=====+===========+ : 848 :.......................: :...............: :.......................: 850 Figure 4: Relationships between IP-based security protocols 852 4.3. IoT Security Guidelines 854 Attacks on and from IoT devices have become common in the last years, 855 for instance, large scale Denial of Service (DoS) attacks on the 856 Internet Infrastructure from compromised IoT devices. This fact has 857 prompted many different standards bodies and consortia to provide 858 guidelines for developers and the Internet community at large to 859 build secure IoT devices and services. A subset of the different 860 guidelines and ongoing projects are as follows: 862 1. GSMA IoT security guidelines [GSMAsecurity]: GSMA has published 863 a set of security guidelines for the benefit of new IoT product 864 and service providers. The guidelines are aimed at device 865 manufacturers, service providers, developers and network 866 operators. An enterprise can complete an IoT Security Self- 867 Assessment to demonstrate that its products and services are 868 aligned with the security guidelines of the GSMA. 870 2. BITAG Internet of Things (IoT) Security and Privacy 871 Recommendations [BITAG]: Broadband Internet Technical Advisory 872 Group (BITAG) has also published recommendations for ensuring 873 security and privacy of IoT device users. BITAG observes that 874 many IoT devices are shipped from the factory with software that 875 is already outdated and vulnerable. The report also states that 876 many devices with vulnerabilities will not be fixed either 877 because the manufacturer does not provide updates or because the 878 user does not apply them. The recommendations include that IoT 879 devices should function without cloud and Internet connectivity, 880 and that all IoT devices should have methods for automatic 881 secure software updates. 883 3. CSA New Security Guidance for Early Adopters of the IoT [CSA]: 884 The Cloud Security Alliance (CSA) recommendations for early 885 adopters of IoT encourages enterprises to implement security at 886 different layers of the protocol stack. It also recommends 887 implementation of an authentication/authorization framework for 888 IoT deployments. A complete list of recommendations is 889 available in the report [CSA]. 891 4. U.S. Department of Homeland Security [DHS]: DHS has put forth 892 six strategic principles that would enable IoT developers, 893 manufacturers, service providers and consumers to maintain 894 security as they develop, manufacture, implement or use network- 895 connected IoT devices. 897 5. NIST [NIST-Guide]: The NIST special publication urges enterprise 898 and US federal agencies to address security throughout the 899 systems engineering process. The publication builds upon the 900 ISO/IEC 15288 standard and augments each process in the system 901 lifecycle with security enhancements. 903 6. NIST [nist_lightweight_project]: NIST is running a project on 904 lightweight cryptography with the purpose of: (i) identifying 905 application areas for which standard cryptographic algorithms 906 are too heavy, classifying them according to some application 907 profiles to be determined; (ii) determining limitations in those 908 existing cryptographic standards; and (iii) standardizing 909 lightweight algorithms that can be used in specific application 910 profiles. 912 7. OWASP [OWASP]: Open Web Application Security Project (OWASP) 913 provides security guidance for IoT manufactures, developers and 914 consumers. OWASP also includes guidelines for those who intend 915 to test and analyze IoT devices and applications. 917 8. IoT Security foundation [IoTSecFoundation]: IoT security 918 foundation has published a document that enlists various 919 considerations that need to be taken into account when 920 developing IoT applications. For example, the document states 921 that IoT devices could use hardware-root of trust to ensure that 922 only authorized software runs on the devices. 924 9. NHTSA [NHTSA]: The US National Highway Traffic Safety 925 Administration provides a set of non-binding guidance to the 926 automotive industry for improving the cyber security of 927 vehicles. While some of the guidelines are general, the 928 document provides specific recommendations for the automotive 929 industry such as how various automotive manufacturer can share 930 cyber security vulnerabilities discovered. 932 10. Best Current Practices (BCP) for IoT devices [ID-Moore]: This 933 document provides a list of minimum requirements that vendors of 934 Internet of Things (IoT) devices should to take into account 935 while developing applications, services and firmware updates in 936 order to reduce the frequency and severity of security incidents 937 that arise from compromised IoT devices. 939 11. ENISA [ENISA_ICS]: The European Union Agency for Network and 940 Information Security published a document on communication 941 network dependencies for ICS/SCADA systems in which security 942 vulnerabilities, guidelines and general recommendations are 943 summarized. 945 Other guideline and recommendation documents may exist or may later 946 be published. This list should be considered non-exhaustive. 947 Despite the acknowledgment that security in the Internet is needed 948 and the existence of multiple guidelines, the fact is that many IoT 949 devices and systems have very limited security. There are multiple 950 reasons for this. For instance, some manufactures focus on 951 delivering a product without paying enough attention to security. 952 This may be because of lack of expertise or limited budget. However, 953 the deployment of such insecure devices poses a severe threat on the 954 privacy and safety of users. The vast amount of devices and their 955 inherent mobile nature also implies that an initially secure system 956 can become insecure if a compromised device gains access to the 957 system at some point in time. Even if all other devices in a given 958 environment are secure, this does not prevent external (passive) 959 attacks caused by insecure devices. 961 Recently the Federal Communications Commission (FCC) [FCC] has stated 962 the need for additional regulation of IoT systems. FCC identifies 963 this as a missing component, especially for Federal Information 964 Systems (FIS). Today, security in the US FIS is regulated according 965 to Federal Information Security Management Act (FISMA). From this 966 law, NIST has derived a number of new documents to categorize FIS and 967 determine minimum security requirements for each category. These 968 minimum security requirements are specified in NIST SP 800-53r4 969 [NIST-SP80053]. 971 Even with strong regulations in place, the question remains as to how 972 such regulations can be applied in practice to non-federal 973 deployments, such as industrial, homes, offices, or smart cites. 974 Each of them exhibits unique features, involves very diverse types of 975 users, has different operational requirements, and combines IoT 976 devices from multiple manufacturers. Future regulations should 977 therefore consider such diverse deployment scenarios. 979 5. Challenges for a Secure IoT 981 In this section, we take a closer look at the various security 982 challenges in the operational and technical features of IoT and then 983 discuss how existing Internet security protocols cope with these 984 technical and conceptual challenges through the lifecycle of a thing. 985 This discussion should neither be understood as a comprehensive 986 evaluation of all protocols, nor can it cover all possible aspects of 987 IoT security. Yet, it aims at showing concrete limitations and 988 challenges in some IoT design areas rather than giving an abstract 989 discussion. In this regard, the discussion handles issues that are 990 most important from the authors' perspectives. 992 5.1. Constraints and Heterogeneous Communication 994 Coupling resource-constrained networks and the powerful Internet is a 995 challenge because the resulting heterogeneity of both networks 996 complicates protocol design and system operation. In the following 997 we briefly discuss the resource constraints of IoT devices and the 998 consequences for the use of Internet Protocols in the IoT domain. 1000 5.1.1. Resource Constraints 1002 IoT deployments are often characterized by lossy and low-bandwidth 1003 communication channels. IoT devices are also often constrained in 1004 terms of CPU, memory, and energy budget available [RFC7228]. These 1005 characteristics directly impact the threats to and the design of 1006 security protocols for the IoT domain. First, the use of small 1007 packets, for example, IEEE 802.15.4 supports 127-byte sized packets 1008 at the physical layer, may result in fragmentation of larger packets 1009 required by security protocols. This may open new attack vectors for 1010 state exhaustion DoS attacks, which is especially tragic, for 1011 example, if the fragmentation is caused by large key exchange 1012 messages of security protocols. Moreover, packet fragmentation 1013 commonly downgrades the overall system performance due to fragment 1014 losses and the need for retransmissions. For instance, fate-sharing 1015 packet flight as implemented by DTLS might aggravate the resulting 1016 performance loss. 1018 The size and number of messages should be minimized to reduce memory 1019 requirements and optimize bandwidth usage. In this context, layered 1020 approaches involving a number of protocols might lead to worse 1021 performance in resource-constrained devices since they combine the 1022 headers of the different protocols. In some settings, protocol 1023 negotiation can increase the number of exchanged messages. To 1024 improve performance during basic procedures such as, for example, 1025 bootstrapping, it might be a good strategy to perform those 1026 procedures at a lower layer. 1028 Small CPUs and scarce memory limit the usage of resource-expensive 1029 crypto primitives such as public-key cryptography as used in most 1030 Internet security standards. This is especially true if the basic 1031 crypto blocks need to be frequently used or the underlying 1032 application demands a low delay. 1034 Independently from the development in the IoT domain, all discussed 1035 security protocols show efforts to reduce the cryptographic cost of 1036 the required public-key-based key exchanges and signatures with 1037 Elliptic Curve Cryptography (ECC) [RFC5246], [RFC5903], [RFC7401], 1038 and [ID-HIP-DEX]. Moreover, all protocols have been revised in the 1039 last years to enable crypto agility, making cryptographic primitives 1040 interchangeable. However, these improvements are only a first step 1041 in reducing the computation and communication overhead of Internet 1042 protocols. The question remains if other approaches can be applied 1043 to leverage key agreement in these heavily resource-constrained 1044 environments. 1046 A further fundamental need refers to the limited energy budget 1047 available to IoT nodes. Careful protocol (re)design and usage is 1048 required to reduce not only the energy consumption during normal 1049 operation, but also under DoS attacks. Since the energy consumption 1050 of IoT devices differs from other device classes, judgments on the 1051 energy consumption of a particular protocol cannot be made without 1052 tailor-made IoT implementations. 1054 5.1.2. Denial-of-Service Resistance 1056 The tight memory and processing constraints of things naturally 1057 alleviate resource exhaustion attacks. Especially in unattended T2T 1058 communication, such attacks are difficult to notice before the 1059 service becomes unavailable (for example, because of battery or 1060 memory exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and 1061 Diet HIP implement return routability checks based on a cookie 1062 mechanism to delay the establishment of state at the responding host 1063 until the address of the initiating host is verified. The 1064 effectiveness of these defenses strongly depend on the routing 1065 topology of the network. Return routability checks are particularly 1066 effective if hosts cannot receive packets addressed to other hosts 1067 and if IP addresses present meaningful information as is the case in 1068 today's Internet. However, they are less effective in broadcast 1069 media or when attackers can influence the routing and addressing of 1070 hosts (for example, if hosts contribute to the routing infrastructure 1071 in ad-hoc networks and meshes). 1073 In addition, HIP implements a puzzle mechanism that can force the 1074 initiator of a connection (and potential attacker) to solve 1075 cryptographic puzzles with variable difficulties. Puzzle-based 1076 defense mechanisms are less dependent on the network topology but 1077 perform poorly if CPU resources in the network are heterogeneous (for 1078 example, if a powerful Internet host attacks a thing). Increasing 1079 the puzzle difficulty under attack conditions can easily lead to 1080 situations where a powerful attacker can still solve the puzzle while 1081 weak IoT clients cannot and are excluded from communicating with the 1082 victim. Still, puzzle-based approaches are a viable option for 1083 sheltering IoT devices against unintended overload caused by 1084 misconfiguration or malfunctioning things. 1086 5.1.3. End-to-end security, protocol translation, and the role of 1087 middleboxes 1089 The term end-to-end security often has multiple interpretations. 1090 Here, we consider end-to-end security in the context end-to-end IP 1091 connectivity, from a sender to a receiver. Services such as 1092 confidentiality and integrity protection on packet data, message 1093 authentication codes or encryption are typically used to provide end- 1094 to-end security. These protection methods render the protected parts 1095 of the packets immutable as rewriting is either not possible because 1096 a) the relevant information is encrypted and inaccessible to the 1097 gateway or b) rewriting integrity-protected parts of the packet would 1098 invalidate the end-to-end integrity protection. 1100 Protocols for constrained IoT networks are not exactly identical to 1101 their larger Internet counterparts for efficiency and performance 1102 reasons. Hence, more or less subtle differences between protocols 1103 for constrained IoT networks and Internet protocols will remain. 1104 While these differences can be bridged with protocol translators at 1105 middleboxes, they may become major obstacles if end-to-end security 1106 measures between IoT devices and Internet hosts are needed. 1108 If access to data or messages by the middleboxes is required or 1109 acceptable, then a diverse set of approaches for handling such a 1110 scenario are available. Note that some of these approaches affect 1111 the meaning of end-to-end security in terms of integrity and 1112 confidentiality since the middleboxes will be able to either decrypt 1113 or modify partially the exchanged messages: 1115 1. Sharing credentials with middleboxes enables them to transform 1116 (for example, decompress, convert, etc.) packets and re-apply the 1117 security measures after transformation. This method abandons 1118 end-to-end security and is only applicable to simple scenarios 1119 with a rudimentary security model. 1121 2. Reusing the Internet wire format for IoT makes conversion between 1122 IoT and Internet protocols unnecessary. However, it can lead to 1123 poor performance in some use cases because IoT specific 1124 optimizations (for example, stateful or stateless compression) 1125 are not possible. 1127 3. Selectively protecting vital and immutable packet parts with a 1128 message authentication code or with encryption requires a careful 1129 balance between performance and security. Otherwise this 1130 approach might either result in poor performance or poor security 1131 depending on which parts are selected for protection, where they 1132 are located in the original packet, and how they are processed. 1133 [ID-OSCOAP] proposes a solution in this direction by encrypting 1134 and integrity protecting most of the message fields except those 1135 parts that a middlebox needs to read or change. 1137 4. Homomorphic encryption techniques can be used in the middlebox to 1138 perform certain operations. However, this is limited to data 1139 processing involving arithmetic operations. Furthermore, 1140 performance of existing libraries, for example, SEAL [SEAL] is 1141 still too limited and it is is not widely applicable yet. 1143 5. Message authentication codes that sustain transformation can be 1144 realized by considering the order of transformation and 1145 protection (for example, by creating a signature before 1146 compression so that the gateway can decompress the packet without 1147 recalculating the signature). Such an approach enables IoT 1148 specific optimizations but is more complex and may require 1149 application-specific transformations before security is applied. 1150 Moreover, the usage of encrypted or integrity-protected data 1151 prevents middleboxes from transforming packets. 1153 6. Mechanisms based on object security can bridge the protocol 1154 worlds, but still require that the two worlds use the same object 1155 security formats. Currently the object security format based on 1156 CBOR Object Signing and Encryption (COSE) [RFC8152] (IoT 1157 protocol) is different from JSON Object Signing and Encryption 1158 (JOSE) [RFC7520] or Cryptographic Message Syntax (CMS) [RFC5652]. 1159 Legacy devices relying on traditional Internet protocols will 1160 need to update to the newer protocols for constrained 1161 environments to enable real end-to-end security. Furthermore, 1162 middleboxes do not have any access to the data and this approach 1163 does not prevent an attacker from modifying relevant fields in 1164 CoAP. 1166 To the best of our knowledge, none of the mentioned security 1167 approaches that focus on the confidentiality and integrity of the 1168 communication exchange between two IP end-points provide the perfect 1169 solution in this problem space. 1171 We finally note that end-to-end security can also be considered in 1172 the context of availability: making sure that the messages are 1173 delivered. In this case, the end-points cannot control this, but the 1174 middleboxes play a fundamental role to make sure that exchanged 1175 messages are not dropped, for example, due to a DDoS attack. 1177 5.1.4. New network architectures and paradigm 1179 There is a multitude of new link layer protocols that aim to address 1180 the resource-constrained nature of IoT devices. For example, the 1181 IEEE 802.11 ah [IEEE802ah] has been specified for extended range and 1182 lower energy consumption to support Internet of Things (IoT) devices. 1183 Similarly, Low-Power Wide-Area Network (LPWAN) protocols such as LoRa 1184 [lora], Sigfox [sigfox], NarrowBand IoT (NB-IoT) [nbiot] are all 1185 designed for resource-constrained devices that require long range and 1186 low bit rates. While these protocols allow IoT devices to conserve 1187 energy and operate efficiently, they also add additional security 1188 challenges. For example, the relatively small MTU can make security 1189 handshakes with large X509 certificates a significant overhead. At 1190 the same time, new communication paradigms also allow IoT devices to 1191 communicate directly amongst themselves with or without support from 1192 the network. This communication paradigm is also referred to as 1193 Device-to-Device (D2D) or Machine-to-Machine (M2M) or Thing-to-Thing 1194 (T2T) communication. D2D is primarily driven by network operators 1195 that want to utilize short range communication to improve the network 1196 performance and for supporting proximity based service 1198 5.2. Bootstrapping of a Security Domain 1200 Creating a security domain from a set of previously unassociated IoT 1201 devices is a key operation in the lifecycle of a thing in an IoT 1202 network. This aspect is further elaborated and discussed in the 1203 T2TRG draft on bootstrapping [ID-bootstrap]. 1205 5.3. Operational Challenges 1207 After the bootstrapping phase, the system enters the operational 1208 phase. During the operational phase, things can use the state 1209 information created during the bootstrapping phase in order to 1210 exchange information securely. In this section, we discuss the 1211 security challenges during the operational phase. Note that many of 1212 the challenges discussed in Section 5.1 apply during the operational 1213 phase. 1215 5.3.1. Group Membership and Security 1217 Group key negotiation is an important security service for IoT 1218 communication patterns in which a thing sends some data to multiple 1219 things or data flows from multiple things towards a thing. All 1220 discussed protocols only cover unicast communication and therefore, 1221 do not focus on group-key establishment. This applies in particular 1222 to (D)TLS and IKEv2. Thus, a solution is required in this area. A 1223 potential solution might be to use the Diffie-Hellman keys - that are 1224 used in IKEv2 and HIP to setup a secure unicast link - for group 1225 Diffie-Hellman key-negotiations. However, Diffie-Hellman is a 1226 relatively heavy solution, especially if the group is large. 1228 Conceptually, solutions that provide secure group communication at 1229 the network layer (IPsec/IKEv2, HIP/Diet HIP) may have an advantage 1230 in terms of the cryptographic overhead when compared to application- 1231 focused security solutions (TLS/ DTLS). This is due to the fact that 1232 application-focused solutions require cryptographic operations per 1233 group application, whereas network layer approaches may allow sharing 1234 secure group associations between multiple applications (for example, 1235 for neighbor discovery and routing or service discovery). Hence, 1236 implementing shared features lower in the communication stack can 1237 avoid redundant security measures. In the case of OSCOAP, it 1238 provides security for CoAP group communication as defined in RFC7390, 1239 i.e., based on multicast IP. If the same security association is 1240 reused for each application, then this solution does not seem to have 1241 more cryptographic overhead compared to IPsec. 1243 Several group key solutions have been developed by the MSEC working 1244 group [WG-MSEC] of the IETF. The MIKEY architecture [RFC4738] is one 1245 example. While these solutions are specifically tailored for 1246 multicast and group broadcast applications in the Internet, they 1247 should also be considered as candidate solutions for group key 1248 agreement in IoT. The MIKEY architecture for example describes a 1249 coordinator entity that disseminates symmetric keys over pair-wise 1250 end-to-end secured channels. However, such a centralized approach 1251 may not be applicable in a distributed IoT environment, where the 1252 choice of one or several coordinators and the management of the group 1253 key is not trivial. 1255 5.3.2. Mobility and IP Network Dynamics 1257 It is expected that many things (for example, wearable sensors, and 1258 user devices) will be mobile in the sense that they are attached to 1259 different networks during the lifetime of a security association. 1260 Built-in mobility signaling can greatly reduce the overhead of the 1261 cryptographic protocols because unnecessary and costly re- 1262 establishments of the session (possibly including handshake and key 1263 agreement) can be avoided. IKEv2 supports host mobility with the 1264 MOBIKE [RFC4555] and [RFC4621] extension. MOBIKE refrains from 1265 applying heavyweight cryptographic extensions for mobility. However, 1266 MOBIKE mandates the use of IPsec tunnel mode which requires to 1267 transmit an additional IP header in each packet. This additional 1268 overhead could be alleviated by using header compression methods or 1269 the Bound End- to-End Tunnel (BEET) mode [ID-Nikander], a hybrid of 1270 tunnel and transport mode with smaller packet headers. 1272 HIP offers a simple yet effective mobility management by allowing 1273 hosts to signal changes to their associations [RFC8046]. However, 1274 slight adjustments might be necessary to reduce the cryptographic 1275 costs, for example, by making the public-key signatures in the 1276 mobility messages optional. Diet HIP does not define mobility yet 1277 but it is sufficiently similar to HIP and can use the same 1278 mechanisms. TLS and DTLS do not have native mobility support, 1279 however, work on DTLS mobility exists in the form of an Internet 1280 draft [ID-Williams]. The specific need for IP-layer mobility mainly 1281 depends on the scenario in which the nodes operate. In many cases, 1282 mobility supported by means of a mobile gateway may suffice to enable 1283 mobile IoT networks, such as body sensor networks. 1285 5.4. Software update 1287 IoT devices have a reputation for being insecure, and yet, they are 1288 expected to stay functional for years and even decades. 1289 Additionally, these devices typically operate unattended with direct 1290 Internet connectivity. Therefore, a remote software update mechanism 1291 to fix vulnerabilities, to update configuration settings, and for 1292 adding new functionality is needed. 1294 Schneier [SchneierSecurity] in his essay expresses concerns about the 1295 status of software and firmware update mechanisms for Internet of 1296 Things (IoT) devices. He highlights several challenges that hinder 1297 mechanisms for secure software update of IoT devices. First, there 1298 is a lack of incentives for manufactures, vendors and others on the 1299 supply chain to issue updates for their devices. Second, parts of 1300 the software running on IoT devices is simply a binary blob without 1301 any source code available. Since the complete source code is not 1302 available, no patches can be written for that piece of code. Lastly 1303 Schneier points out that even when updates are available, users 1304 generally have to manually download and install them. However, users 1305 are never alerted about security updates and at many times do not 1306 have the necessary expertise to manually administer the required 1307 updates. 1309 The FTC staff report on Internet of Things - Privacy & Security in a 1310 Connected World [FTCreport] and the Article 29 Working Party Opinion 1311 8/2014 on the Recent Developments on the Internet of Things 1312 [Article29] also document the challenges for secure remote software 1313 update of IoT devices. They note that even providing such a software 1314 update capability may add new vulnerabilities for constrained 1315 devices. For example, a buffer overflow vulnerability in the 1316 implementation of a software update protocol (TR69) [TR69] and an 1317 expired certificate in a hub device [wink] demonstrate how the 1318 software update process itself can introduce vulnerabilities. 1320 Powerful IoT devices that run general purpose operating systems can 1321 make use of sophisticated software update mechanisms known from the 1322 desktop world. However, resource-constrained devices that do not 1323 have any operating system and are typically not equipped with a 1324 memory management unit or similar tools require more specialized 1325 solutions. 1327 It is important to mention previous and ongoing work in the area of 1328 secure software and firmware updates at the IETF. [RFC4108] 1329 describes how Cryptographic Message Syntax (CMS) [RFC5652] can be 1330 used to protect firmware packages. The IAB has also organized a 1331 workshop to understand the challenges for secure software update of 1332 IoT devices. A summary of the workshop and the proposed next steps 1333 have been documented [iotsu]. Finally, a new working group called 1334 Firmware UpDate (fud) [WG-FUD] is currently being chartered at the 1335 IETF. The working group aims to standardize a new version [RFC4108] 1336 that reflects the best current practices for firmware update based on 1337 experience with IoT deployments. It will specifically work on 1338 describing an IoT firmware update architecture and specifying a 1339 manifest format that contains meta-data about the firmware update 1340 package. 1342 5.5. Verifying device behavior 1344 Users often have a false sense of privacy when using new IoT 1345 appliances such as Internet-connected smart televisions, speakers and 1346 cameras. Recent revelations have shown that this user belief is 1347 often unfounded. Many IoT device vendors have been caught collecting 1348 sensitive private data through these connected appliances with or 1349 without appropriate user warnings [cctv]. 1351 An IoT device user/owner would like to monitor and verify its 1352 operational behavior. For instance, the user might want to know if 1353 the device is connecting to the server of the manufacturer for any 1354 reason. This feature - connected to the manufacturer's server - may 1355 be necessary in some scenarios, such as during the initial 1356 configuration of the device. However, the user should be kept aware 1357 of the data that the device is sending back to the vendor. For 1358 example, the user might want to know if his/her TV is sending data 1359 when he/she inserts a new USB stick. 1361 Providing such information to the users in an understandable fashion 1362 is challenging. This is because IoT devices are not only resource- 1363 constrained in terms of their computational capability, but also in 1364 terms of the user interface available. Also, the network 1365 infrastructure where these devices are deployed will vary 1366 significantly from one user environment to another. Therefore, where 1367 and how this monitoring feature is implemented still remains an open 1368 question. 1370 Manufacturer Usage Description (MUD) files [ID-MUD] are perhaps a 1371 first step towards implementation of such a monitoring service. The 1372 idea behind MUD files is relatively simple: IoT devices would 1373 disclose the location of their MUD file to the network during 1374 installation. The network can then retrieve those files, and learn 1375 about the intended behavior of the devices stated by the device 1376 manufacturer. A network monitoring service could then warn the user/ 1377 owner of devices if they don't behave as expected. 1379 5.6. End-of-Life 1381 Like all commercial devices, IoT devices have a given useful 1382 lifetime. The term end-of-life (EOL) is used by vendors or network 1383 operators to indicate the point of time in which they limit or end 1384 support for the IoT product. This may be planned or unplanned (for 1385 example when the vendor or manufacturer goes bankrupt or when a 1386 network operator moves to a different type of networking technology). 1387 A user should still be able to use and perhaps even update the 1388 device. This requires for some form of authorization handover. 1390 Although this may seem far-fetched given the commercial interests and 1391 market dynamics, we have examples from the mobile world where the 1392 devices have been functional and up-to-date long after the original 1393 vendor stopped supporting the device. CyanogenMod for Android 1394 devices, and OpenWrt for home routers are two such instances where 1395 users have been able to use and update their devices even after the 1396 official EOL. Admittedly it is not easy for an average user to 1397 install and configure their devices on their own. With the 1398 deployment of millions of IoT devices, simpler mechanisms are needed 1399 to allow users to add new root-of-trusts and install software and 1400 firmware from other sources once the device is EOL. 1402 5.7. Testing: bug hunting and vulnerabilities 1404 Given that IoT devices often have inadvertent vulnerabilities, both 1405 users and developers would want to perform extensive testing on their 1406 IoT devices, networks, and systems. Nonetheless, since the devices 1407 are resource-constrained and manufactured by multiple vendors, some 1408 of them very small, devices might be shipped with very limited 1409 testing, so that bugs can remain and can be exploited at a later 1410 stage. This leads to two main types of challenges: 1412 1. It remains to be seen how the software testing and quality 1413 assurance mechanisms used from the desktop and mobile world will 1414 be applied to IoT devices to give end users the confidence that 1415 the purchased devices are robust. 1417 2. It is also an open question how the combination of devices from 1418 multiple vendors might actually lead to dangerous network 1419 configurations, for example, if combination of specific devices 1420 can trigger unexpected behavior. 1422 5.8. Quantum-resistance 1424 Many IoT systems that are being deployed today will remain 1425 operational for many years. With the advancements made in the field 1426 of quantum computers, it is possible that large-scale quantum 1427 computers are available in the future for performing cryptanalysis on 1428 existing cryptographic algorithms and cipher suites. If this 1429 happens, it will have two consequences. First, functionalities 1430 enabled by means of RSA/ECC - namely key exchange, public-key 1431 encryption and signature - would not be secure anymore due to Shor's 1432 algorithm. Second, the security level of symmetric algorithms will 1433 decrease, for example, the security of a block cipher with a key size 1434 of b bits will only offer b/2 bits of security due to Grover's 1435 algorithm. 1437 The above scenario becomes more urgent when we consider the so called 1438 "harvest and decrypt" attack in which an attacker can start to 1439 harvest (store) encrypted data today, before a quantum-computer is 1440 available, and decrypt it years later, once a quantum computer is 1441 available. 1443 This situation would require us to move to quantum-resistant 1444 alternatives, in particular, for those functionalities involving key 1445 exchange, public-key encryption and signatures. [ID-c2pq] describes 1446 when quantum computers may become widely available and what steps are 1447 necessary for transition to cryptographic algorithms that provide 1448 security even in presence of quantum computers. While future 1449 planning is hard, it may be a necessity in certain critical IoT 1450 deployments which are expected to last decades or more. Although 1451 increasing the key-size of the different algorithms is definitely an 1452 option, it would also incur additional computational overhead and 1453 network traffic. This would be undesirable in most scenarios. There 1454 have been recent advancements in quantum-resistant cryptography. 1456 We refer to [ETSI_GR_QSC_001] for an extensive overview of existing 1457 quantum-resistant cryptography. [RFC7696] provides guidelines for 1458 cryptographic algorithm agility. 1460 5.9. Privacy protection 1462 Users will be surrounded by hundreds of connected IoT devices. Even 1463 if the communication links are encrypted and protected, information 1464 about the users might be collected for different purposes affecting 1465 their privacy. In [Ziegeldorf], privacy in IoT is defined as the 1466 threefold guarantee to the user for: 1. awareness of privacy risks 1467 imposed by smart things and services surrounding the data subject, 2. 1468 individual control over the collection and processing of personal 1469 information by the surrounding smart things, 3. awareness and control 1470 of subsequent use and dissemination of personal information by those 1471 entities to any entity outside the subject's personal control sphere. 1473 Based on this definition, several privacy threats and challenges have 1474 been documented [Ziegeldorf] and [RFC6973]: 1476 1. Identification - refers to the identification of the users and 1477 their objects. 1479 2. Localization - relates to the capability of locating a user and 1480 even tracking them. 1482 3. Profiling - is about creating a profile of the user and their 1483 preferences. 1485 4. Interaction - occurs when a user has been profiled and a given 1486 interaction is preferred, presenting (for example, visually) some 1487 information that discloses private information. 1489 5. Lifecycle transitions - take place when devices are, for example, 1490 sold without properly removing private data. 1492 6. Inventory attacks - happen if specific information about (smart) 1493 objects in possession of a user is disclosed. 1495 7. Linkage - is about when information of two of more IoT systems is 1496 combined so that a broader view on the personal data is created. 1498 When IoT systems are deployed, the above issues should be considered 1499 to ensure that private data remains private. How to achieve this in 1500 practice is still an area of ongoing research. 1502 5.10. Data leakage 1504 Many IoT devices are resource-constrained and often deployed in 1505 unattended environments. Some of these devices can also be purchased 1506 off-the-shelf or online without any credential-provisioning process. 1507 Therefore, an attacker can have direct access to the device and apply 1508 advanced techniques to retrieve information that a traditional black 1509 box model does not consider. Example of those techniques are side- 1510 channel attacks or code disassembly. By doing this, the attacker can 1511 try to retrieve data such as: 1513 1. long term keys that might be used to perform attacks on devices 1514 deployed in other locations. 1516 2. source code that might allow the attacker to determine bugs or 1517 find exploits to perform other types of attacks. The attacker 1518 might also just sell the source code. 1520 3. proprietary algorithms that could be counterfeited or modified to 1521 perform advanced attacks. 1523 Protection against such data leakage patterns is not trivial since 1524 devices are inherently resource-constrained. An open question is 1525 whether there are any viable techniques to protect IoT devices and 1526 the data in the devices in such an adversarial model. 1528 5.11. Trustworthy IoT Operation 1530 Flaws in the design and implementation of a secure IoT device and 1531 network can lead to security vulnerabilities. For instance, a flaw 1532 is the distribution of an Internet-connected IoT device in which a 1533 default password is used in all devices. Many IoT devices can be 1534 found in the Internet by means of tools such as Shodan [shodan], and 1535 if they have any vulnerability, it can then be exploited at scale, 1536 for example, to launch DDoS attacks. This is not fiction but reality 1537 as Dyn, a mayor DNS was attacked by means of a DDoS attack originated 1538 from a large IoT botnet composed of thousands of compromised IP- 1539 cameras [dyn-attack]. Open questions in this area are: 1541 1. How to prevent large scale vulnerabilities in IoT devices? 1543 2. How to prevent attackers from exploiting vulnerabilities in IoT 1544 devices at large scale? 1546 3. If the vulnerability has been exploited, how do we stop a large 1547 scale attack before any damage is caused? 1549 Some ideas are being explored to address this issue. One of this 1550 approaches refers to the specification of Manufacturer Usage 1551 Description (MUD) files [ID-MUD]. As explained earlier, this 1552 proposal requires IoT devices to disclose the location of their MUD 1553 file to the network during installation. The network can then (i) 1554 retrieve those files, (ii) learn from the manufacturers the intended 1555 usage of the devices, for example, which services they require to 1556 access, and then (iii) create suitable filters such as firewall 1557 rules. 1559 6. Conclusions and Next Steps 1561 This Internet Draft provides IoT security researchers, system 1562 designers and implementers with an overview of both operational and 1563 security requirements in the IP-based Internet of Things. We discuss 1564 a general threat model, threats, state-of-the-art, and security 1565 challenges. 1567 Although plenty of steps have been realized during the last few years 1568 (summarized in Section 4.1) and many organizations are publishing 1569 general recommendations (Section 4.3) describing how IoT should be 1570 secured, there are many challenges ahead that require further 1571 attention. Challenges of particular importance are bootstrapping of 1572 security, group security, secure software updates, long-term security 1573 and quantum-resistance, privacy protection, data leakage prevention - 1574 where data could be cryptographic keys, personal data, or even 1575 algorithms - and ensuring trustworthy IoT operation. All these 1576 problems are important; however, different deployment environments 1577 have different operational and security demands. Thus, a potential 1578 approach is the definition and standardization of security profiles, 1579 each with specific mitigation strategies according to the risk 1580 assessment associated with the security profile. Such an approach 1581 would ensure minimum security capabilities in different environments 1582 while ensuring interoperability. 1584 7. Security Considerations 1586 This document reflects upon the requirements and challenges of the 1587 security architectural framework for the Internet of Things. 1589 8. IANA Considerations 1591 This document contains no request to IANA. 1593 9. Acknowledgments 1595 We gratefully acknowledge feedback and fruitful discussion with 1596 Tobias Heer, Robert Moskowitz, Thorsten Dahm, Hannes Tschofenig, 1597 Carsten Bormann, Barry Raveendran, Ari Keranen, Goran Selander, Fred 1598 Baker and Eliot Lear. We acknowledge the additional authors of the 1599 previous version of this document Sye Loong Keoh, Rene Hummen and 1600 Rene Struik. 1602 10. Informative References 1604 [Article29] 1605 "Opinion 8/2014 on the on Recent Developments on the 1606 Internet of Things", Web http://ec.europa.eu/justice/data- 1607 protection/article-29/documentation/opinion- 1608 recommendation/files/2014/wp223_en.pdf, n.d.. 1610 [AUTO-ID] "AUTO-ID LABS", Web http://www.autoidlabs.org/, September 1611 2010. 1613 [BACNET] "BACnet", Web http://www.bacnet.org/, February 2011. 1615 [BITAG] "Internet of Things (IoT) Security and Privacy 1616 Recommendations", Web http://www.bitag.org/report- 1617 internet-of-things-security-privacy-recommendations.php, 1618 n.d.. 1620 [cctv] "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an 1621 Email Address In China", Web 1622 https://hardware.slashdot.org/story/16/02/17/0422259/ 1623 backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an- 1624 email-address-in-china, n.d.. 1626 [CSA] "Security Guidance for Early Adopters of the Internet of 1627 Things (IoT)", Web 1628 https://downloads.cloudsecurityalliance.org/whitepapers/Se 1629 curity_Guidance_for_Early_Adopters_of_the_Internet_of_Thin 1630 gs.pdf, n.d.. 1632 [DALI] "DALI", Web http://www.dalibydesign.us/dali.html, February 1633 2011. 1635 [DHS] "Strategic Principles For Securing the Internet of Things 1636 (IoT)", Web 1637 https://www.dhs.gov/sites/default/files/publications/ 1638 Strategic_Principles_for_Securing_the_Internet_of_Things- 1639 2016-1115-FINAL....pdf, n.d.. 1641 [dyn-attack] 1642 "Dyn Analysis Summary Of Friday October 21 Attack", Web 1643 https://dyn.com/blog/dyn-analysis-summary-of-friday- 1644 october-21-attack/, n.d.. 1646 [ENISA_ICS] 1647 "Communication network dependencies for ICS/SCADA 1648 Systems", European Union Agency For Network And 1649 Information Security , February 2017. 1651 [ETSI_GR_QSC_001] 1652 "Quantum-Safe Cryptography (QSC);Quantum-safe algorithmic 1653 framework", European Telecommunications Standards 1654 Institute (ETSI) , June 2016. 1656 [Fairhair] 1657 "Fairhair Alliance", Web https://www.fairhair- 1658 alliance.org/, n.d.. 1660 [FCC] "Federal Communications Comssion Response 12-05-2016", 1661 FCC , February 2016. 1663 [FTCreport] 1664 "FTC Report on Internet of Things Urges Companies to Adopt 1665 Best Practices to Address Consumer Privacy and Security 1666 Risks", Web https://www.ftc.gov/news-events/press- 1667 releases/2015/01/ftc-report-internet-things-urges- 1668 companies-adopt-best-practices, n.d.. 1670 [GSMAsecurity] 1671 "GSMA IoT Security Guidelines", Web 1672 http://www.gsma.com/connectedliving/future-iot-networks/ 1673 iot-security-guidelines/, n.d.. 1675 [ID-6lonfc] 1676 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 1677 "Transmission of IPv6 Packets over Near Field 1678 Communication", draft-ietf-6lo-nfc-07 (work in progress), 1679 June 2017. 1681 [ID-6tisch] 1682 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1683 of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work 1684 in progress), August 2017. 1686 [ID-acedtls] 1687 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1688 L. Seitz, "Datagram Transport Layer Security (DTLS) 1689 Profile for Authentication and Authorization for 1690 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1691 authorize-01 (work in progress), July 2017. 1693 [ID-aceoauth] 1694 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1695 H. Tschofenig, "Authentication and Authorization for 1696 Constrained Environments (ACE)", draft-ietf-ace-oauth- 1697 authz-07 (work in progress), August 2017. 1699 [ID-bootstrap] 1700 Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT 1701 Bootstrapping: A Survey", draft-sarikaya-t2trg- 1702 sbootstrapping-03 (work in progress), February 2017. 1704 [ID-c2pq] Hoffman, P., "The Transition from Classical to Post- 1705 Quantum Cryptography", draft-hoffman-c2pq-02 (work in 1706 progress), August 2017. 1708 [ID-Daniel] 1709 Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. 1710 Laganier, "IPv6 over Low Power WPAN Security Analysis", 1711 draft-daniel-6lowpan-security-analysis-05 (work in 1712 progress), March 2011. 1714 [ID-dietesp] 1715 Migault, D., Guggemos, T., and C. Bormann, "Diet-ESP: a 1716 flexible and compressed format for IPsec/ESP", draft-mglt- 1717 6lo-diet-esp-02 (work in progress), July 2016. 1719 [ID-HIP-DEX] 1720 Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz- 1721 hip-rg-dex-06 (work in progress), May 2012. 1723 [ID-Moore] 1724 Moore, K., Barnes, R., and H. Tschofenig, "Best Current 1725 Practices for Securing Internet of Things (IoT) Devices", 1726 draft-moore-iot-security-bcp-01 (work in progress), July 1727 2017. 1729 [ID-MUD] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1730 Description Specification", draft-ietf-opsawg-mud-10 (work 1731 in progress), September 2017. 1733 [ID-Nikander] 1734 Nikander, P. and J. Melen, "A Bound End-to-End Tunnel 1735 (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 1736 (work in progress), August 2008. 1738 [ID-OSCOAP] 1739 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1740 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 1741 object-security-04 (work in progress), July 2017. 1743 [ID-rd] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1744 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1745 resource-directory-11 (work in progress), July 2017. 1747 [ID-senml] 1748 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 1749 Bormann, "Media Types for Sensor Measurement Lists 1750 (SenML)", draft-ietf-core-senml-10 (work in progress), 1751 July 2017. 1753 [ID-Williams] 1754 Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett- 1755 mobile-dtls-00 (work in progress), March 2009. 1757 [IEEE802ah] 1758 "Status of Project IEEE 802.11ah, IEEE P802.11- Task Group 1759 AH-Meeting Update.", 1760 Web http://www.ieee802.org/11/Reports/tgah_update.htm, 1761 n.d.. 1763 [IIoT] "Industrial Internet Consortium", 1764 Web http://www.iiconsortium.org/, n.d.. 1766 [IoTSecFoundation] 1767 "Establishing Principles for Internet of Things Security", 1768 Web https://iotsecurityfoundation.org/establishing- 1769 principles-for-internet-of-things-security/, n.d.. 1771 [iotsu] "Patching the Internet of Things: IoT Software Update 1772 Workshop 2016", Web 1773 https://www.ietf.org/blog/2016/07/patching-the-internet- 1774 of-things-iot-software-update-workshop-2016/, n.d.. 1776 [IPSO] "IPSO Alliance", Web http://www.ipso-alliance.org, n.d.. 1778 [lora] "LoRa - Wide Area Networks for IoT", Web https://www.lora- 1779 alliance.org/, n.d.. 1781 [LWM2M] "OMA LWM2M", Web http://openmobilealliance.org/iot/ 1782 lightweight-m2m-lwm2m, n.d.. 1784 [nbiot] "NarrowBand IoT", Web 1785 http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/ 1786 RP-151621.zip, n.d.. 1788 [NHTSA] "Cybersecurity Best Practices for Modern Vehicles", Web 1789 https://www.nhtsa.gov/staticfiles/nvs/ 1790 pdf/812333_CybersecurityForModernVehicles.pdf, n.d.. 1792 [NIST-Guide] 1793 Ross, R., McEvilley, M., and J. Oren, "Systems Security 1794 Engineering", Web 1795 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 1796 NIST.SP.800-160.pdf, n.d.. 1798 [NIST-SP80053] 1799 "Security and Privacy Controls for Federal Information 1800 Systems and Organizations", 1801 Web http://dx.doi.org/10.6028/NIST.SP.800-53r4, n.d.. 1803 [nist_lightweight_project] 1804 "NIST lightweight Project", Web www.nist.gov/programs- 1805 projects/lightweight-cryptography, 1806 www.nist.gov/sites/default/files/documents/2016/10/17/ 1807 sonmez-turan-presentation-lwc2016.pdf, n.d.. 1809 [OCF] "Open Connectivity Foundation", 1810 Web https://openconnectivity.org/, n.d.. 1812 [OneM2M] "OneM2M", Web http://www.onem2m.org/, n.d.. 1814 [OWASP] "IoT Security Guidance", 1815 Web https://www.owasp.org/index.php/IoT_Security_Guidance, 1816 n.d.. 1818 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1819 DOI 10.17487/RFC2818, May 2000, . 1822 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1823 Levkowetz, Ed., "Extensible Authentication Protocol 1824 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1825 . 1827 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1828 Neighbor Discovery (ND) Trust Models and Threats", 1829 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1830 . 1832 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1833 Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 1834 2004, . 1836 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1837 and Network Access (PANA) Threat Analysis and Security 1838 Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005, 1839 . 1841 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1842 Protect Firmware Packages", RFC 4108, 1843 DOI 10.17487/RFC4108, August 2005, . 1846 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1847 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1848 . 1850 [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 1851 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, 1852 DOI 10.17487/RFC4621, August 2006, . 1855 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1856 RSA-R: An Additional Mode of Key Distribution in 1857 Multimedia Internet KEYing (MIKEY)", RFC 4738, 1858 DOI 10.17487/RFC4738, November 2006, . 1861 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1862 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1863 Overview, Assumptions, Problem Statement, and Goals", 1864 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1865 . 1867 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1868 "Transmission of IPv6 Packets over IEEE 802.15.4 1869 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1870 . 1872 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1873 and A. Yegin, "Protocol for Carrying Authentication for 1874 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1875 May 2008, . 1877 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1878 (TLS) Protocol Version 1.2", RFC 5246, 1879 DOI 10.17487/RFC5246, August 2008, . 1882 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1883 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1884 . 1886 [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 1887 Threats and Security Requirements for the Access Node 1888 Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713, 1889 January 2010, . 1891 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 1892 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 1893 DOI 10.17487/RFC5903, June 2010, . 1896 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 1897 Grid", RFC 6272, DOI 10.17487/RFC6272, June 2011, 1898 . 1900 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1901 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1902 January 2012, . 1904 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1905 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1906 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1907 Low-Power and Lossy Networks", RFC 6550, 1908 DOI 10.17487/RFC6550, March 2012, . 1911 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1912 and D. Barthel, "Routing Metrics Used for Path Calculation 1913 in Low-Power and Lossy Networks", RFC 6551, 1914 DOI 10.17487/RFC6551, March 2012, . 1917 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 1918 Application Spaces for IPv6 over Low-Power Wireless 1919 Personal Area Networks (6LoWPANs)", RFC 6568, 1920 DOI 10.17487/RFC6568, April 2012, . 1923 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1924 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1925 . 1927 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1928 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1929 . 1931 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1932 Morris, J., Hansen, M., and R. Smith, "Privacy 1933 Considerations for Internet Protocols", RFC 6973, 1934 DOI 10.17487/RFC6973, July 2013, . 1937 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1938 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1939 October 2013, . 1941 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1942 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1943 2014, . 1945 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1946 Constrained-Node Networks", RFC 7228, 1947 DOI 10.17487/RFC7228, May 2014, . 1950 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1951 Application Protocol (CoAP)", RFC 7252, 1952 DOI 10.17487/RFC7252, June 2014, . 1955 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1956 Kivinen, "Internet Key Exchange Protocol Version 2 1957 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1958 2014, . 1960 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1961 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1962 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1963 . 1965 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1966 and M. Richardson, Ed., "A Security Threat Analysis for 1967 the Routing Protocol for Low-Power and Lossy Networks 1968 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1969 . 1971 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1972 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1973 2015, . 1975 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1976 DOI 10.17487/RFC7517, May 2015, . 1979 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1980 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1981 . 1983 [RFC7520] Miller, M., "Examples of Protecting Content Using JSON 1984 Object Signing and Encryption (JOSE)", RFC 7520, 1985 DOI 10.17487/RFC7520, May 2015, . 1988 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1989 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1990 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1991 . 1993 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1994 Agility and Selecting Mandatory-to-Implement Algorithms", 1995 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1996 . 1998 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 1999 and S. Kumar, "Use Cases for Authentication and 2000 Authorization in Constrained Environments", RFC 7744, 2001 DOI 10.17487/RFC7744, January 2016, . 2004 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 2005 (IKEv2) Initiator Implementation", RFC 7815, 2006 DOI 10.17487/RFC7815, March 2016, . 2009 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 2010 Security (TLS) / Datagram Transport Layer Security (DTLS) 2011 Profiles for the Internet of Things", RFC 7925, 2012 DOI 10.17487/RFC7925, July 2016, . 2015 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 2016 with the Host Identity Protocol", RFC 8046, 2017 DOI 10.17487/RFC8046, February 2017, . 2020 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 2021 M., and D. Barthel, "Transmission of IPv6 Packets over 2022 Digital Enhanced Cordless Telecommunications (DECT) Ultra 2023 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2024 2017, . 2026 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2027 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2028 . 2030 [RG-T2TRG] 2031 "IRTF Thing-to-Thing (T2TRG) Research Group", 2032 Web https://datatracker.ietf.org/rg/t2trg/charter/, n.d.. 2034 [SchneierSecurity] 2035 "The Internet of Things Is Wildly Insecure--And Often 2036 Unpatchable", Web 2037 https://www.schneier.com/essays/archives/2014/01/ 2038 the_internet_of_thin.html, n.d.. 2040 [SEAL] "Simple Encrypted Arithmetic Library - SEAL", 2041 Web https://sealcrypto.codeplex.com/, n.d.. 2043 [shodan] "Shodan", Web https://www.shodan.io/, n.d.. 2045 [sigfox] "Sigfox - The Global Communications Service Provider for 2046 the Internet of Things (IoT)", 2047 Web https://www.sigfox.com/, n.d.. 2049 [Thread] "Thread Group", Web http://threadgroup.org/, n.d.. 2051 [TR69] "Too Many Cooks - Exploiting the Internet-of-TR- 2052 069-Things", Web https://media.ccc.de/v/31c3_-_6166_-_en_- 2053 _saal_6_-_201412282145_-_too_many_cooks_- 2054 _exploiting_the_internet-of-tr-069-things_- 2055 _lior_oppenheim_-_shahar_tal, n.d.. 2057 [WG-6lo] "IETF IPv6 over Networks of Resource-constrained Nodes 2058 (6lo) Working Group", 2059 Web https://datatracker.ietf.org/wg/6lo/charter/, n.d.. 2061 [WG-6LoWPAN] 2062 "IETF IPv6 over Low power WPAN (6lowpan) Working Group", 2063 Web http://tools.ietf.org/wg/6lowpan/, n.d.. 2065 [WG-ACE] "IETF Authentication and Authorization for Constrained 2066 Environments (ACE) Working Group", 2067 Web https://datatracker.ietf.org/wg/ace/charter/, n.d.. 2069 [WG-ACME] "Automated Certificate Management Environment Working 2070 Group", Web https://datatracker.ietf.org/wg/acme/about/, 2071 n.d.. 2073 [WG-CoRE] "IETF Constrained RESTful Environment (CoRE) Working 2074 Group", Web https://datatracker.ietf.org/wg/core/charter/, 2075 n.d.. 2077 [WG-FUD] "IETF Firmware UpDate (fud)", 2078 Web https://datatracker.ietf.org/wg/fud/about/, n.d.. 2080 [WG-LWIG] "IETF Light-Weight Implementation Guidance (LWIG) Working 2081 Group", Web https://datatracker.ietf.org/wg/lwig/charter/, 2082 n.d.. 2084 [WG-MSEC] "IETF MSEC Working Group", 2085 Web https://datatracker.ietf.org/wg/msec/, n.d.. 2087 [wink] "Wink's Outage Shows Us How Frustrating Smart Homes Could 2088 Be", 2089 Web http://www.wired.com/2015/04/smart-home-headaches/, 2090 n.d.. 2092 [ZB] "ZigBee Alliance", Web http://www.zigbee.org/, February 2093 2011. 2095 [Ziegeldorf] 2096 Ziegeldorf, J., Garcia-Morchon, O., and K. Wehrle,, 2097 "Privacy in the Internet of Things: Threats and 2098 Challenges", Security and Communication Networks - Special 2099 Issue on Security in a Completely Interconnected World , 2100 2013. 2102 Authors' Addresses 2104 Oscar Garcia-Morchon 2105 Philips IP&S 2106 High Tech Campus 5 2107 Eindhoven, 5656 AA 2108 The Netherlands 2110 Email: oscar.garcia-morchon@philips.com 2112 Sandeep S. Kumar 2113 Philips Research 2114 High Tech Campus 2115 Eindhoven, 5656 AA 2116 The Netherlands 2118 Email: sandeep.kumar@philips.com 2120 Mohit Sethi 2121 Ericsson 2122 Hirsalantie 11 2123 Jorvas, 02420 2124 Finland 2126 Email: mohit@piuha.net