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