idnits 2.17.1 draft-irtf-t2trg-iot-seccons-14.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 21, 2018) is 2194 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-20 == 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 23, 2018 Philips Research 6 M. Sethi 7 Ericsson 8 April 21, 2018 10 State-of-the-Art and Challenges for the Internet of Things Security 11 draft-irtf-t2trg-iot-seccons-14 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 23, 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. Some of these threats 299 might go beyond the scope of Internet protocols but we gather them 300 here for the sake of completeness. The threats in the following list 301 are not in any particular order and some threats might be more 302 critical than others depending on the deployment scenario under 303 consideration: 305 1. Vulnerable Software/Code: Things in the Internet of Things rely 306 on software that might contain severe bugs and/or bad design 307 choices. This makes the things vulnerable to many different 308 types of attacks, depending on the criticality of the bugs, 309 e.g., buffer overflows or lack of authentication. This can be 310 considered as one of the most important security threat. The 311 large-scale distributed denial-of-service (DDoS) attack, 312 popularly known as the Mirai botnet, was caused by things that 313 had well-known or easy-to-guess passwords for configuration. 315 2. Privacy threat: The tracking of a thing's location and usage may 316 pose a privacy risk to people around it. For instance, an 317 attacker can infer privacy sensitive information from the data 318 gathered and communicated by individual things. Such 319 information may subsequently be sold to interested parties for 320 marketing purposes and targeted advertising. In extreme cases, 321 such information might be used to track dissidents in oppressive 322 regimes. Unlawful surveillance and interception of traffic to/ 323 from a thing by intelligence agencies is also a privacy threat. 325 3. Cloning of things: During the manufacturing process of a thing, 326 an untrusted factory can easily clone the physical 327 characteristics, firmware/software, or security configuration of 328 the thing. Deployed things might also be compromised and their 329 software reverse engineered allowing for cloning or software 330 modifications. Such a cloned thing may be sold at a cheaper 331 price in the market, and yet can function normally as a genuine 332 thing. For example, two cloned devices can still be associated 333 and work with each other. In the worst-case scenario, a cloned 334 device can be used to control a genuine device or perform an 335 attack. One should note here, that an untrusted factory may 336 also change functionality of the cloned thing, resulting in 337 degraded functionality with respect to the genuine thing 338 (thereby, inflicting potential damage to the reputation of the 339 original thing manufacturer). Moreover, additional 340 functionality can be introduced in the cloned thing, an example 341 of such functionality is a backdoor. 343 4. Malicious substitution of things: During the installation of a 344 thing, a genuine thing may be substituted with a similar variant 345 (of lower quality) without being detected. The main motivation 346 may be cost savings, where the installation of lower-quality 347 things (for example, non-certified products) may significantly 348 reduce the installation and operational costs. The installers 349 can subsequently resell the genuine things to gain further 350 financial benefits. Another motivation may be to inflict damage 351 to the reputation of a competitor's offerings. 353 5. Eavesdropping attack: During the commissioning of a thing into a 354 network, it may be susceptible to eavesdropping, especially if 355 operational keying materials, security parameters, or 356 configuration settings, are exchanged in clear using a wireless 357 medium or if used cryptographic algorithms are not suitable for 358 the envisioned lifetime of the device and the system. After 359 obtaining the keying material, the attacker might be able to 360 recover the secret keys established between the communicating 361 entities, thereby compromising the authenticity and 362 confidentiality of the communication channel, as well as the 363 authenticity of commands and other traffic exchanged over this 364 communication channel. When the network is in operation, T2T 365 communication may be eavesdropped upon if the communication 366 channel is not sufficiently protected or in the event of session 367 key compromise due to protocol weaknesses or a long period of 368 usage without key renewal or updates. Messages can also be 369 recorded and processed offline at a later time. 371 6. Man-in-the-middle attack: Both the commissioning phase and 372 operational phases may also be vulnerable to man-in-the-middle 373 attacks. For example, when keying material between 374 communicating entities is exchanged in the clear and the 375 security of the key establishment protocol depends on the tacit 376 assumption that no third party can eavesdrop during the 377 execution of this protocol. Additionally, device authentication 378 or device authorization may be non-trivial, or may need support 379 of a human decision process, since things usually do not have 380 a-priori knowledge about each other and cannot always 381 differentiate friends and foes via completely automated 382 mechanisms. 384 7. Firmware attacks: When a thing is in operation or maintenance 385 phase, its firmware or software may be updated to allow for new 386 functionality or new features. An attacker may be able to 387 exploit such a firmware upgrade by replacing the thing's 388 software with malicious software, thereby influencing the 389 operational behavior of the thing. For example, an attacker 390 could add a piece of malicious code to the firmware that will 391 cause it to periodically report the energy usage of the lamp to 392 a data repository for analysis. Similarly, devices whose 393 software has not been properly maintained and updated might 394 contain vulnerabilities that might be exploited by attackers to 395 replace the firmware on the device. 397 8. Extraction of private information: IoT devices (such as sensors, 398 actuators, etc.) are often physically unprotected in their 399 ambient environment and they could easily be captured by an 400 attacker. An attacker with physical access may then attempt to 401 extract private information such as keys (for example, device's 402 key, private-key, group key), sensed data (for example, 403 healthcare status of a user), configuration parameters (for 404 example, the Wi-Fi key), or proprietary algorithms (for example, 405 algorithm performing some data analytics task). Even when the 406 data originating from a thing is encrypted, attackers can 407 perform traffic analysis to deduce meaningful information which 408 might compromise the privacy of the thing's owner and/or user. 410 9. Routing attack: As highlighted in [ID-Daniel], routing 411 information in IoT networks can be spoofed, altered, or 412 replayed, in order to create routing loops, attract/repel 413 network traffic, extend/shorten source routes, etc. Other 414 relevant routing attacks include 1) Sinkhole attack (or 415 blackhole attack), where an attacker declares himself to have a 416 high-quality route/path to the base station, thus allowing him 417 to do manipulate all packets passing through it. 2) Selective 418 forwarding, where an attacker may selectively forward packets or 419 simply drop a packet. 3) Wormhole attack, where an attacker may 420 record packets at one location in the network and tunnel them to 421 another location, thereby influencing perceived network behavior 422 and potentially distorting statistics, thus greatly impacting 423 the functionality of routing. 4) Sybil attack, whereby an 424 attacker presents multiple identities to other things in the 425 network. 427 10. Elevation of privilege: An attacker with low privileges can 428 misuse additional flaws in the implemented authentication and 429 authorization mechanisms of a thing to gain more privileged 430 access to the thing and its data. 432 11. Denial-of-Service (DoS) attack: Often things have very limited 433 memory and computation capabilities. Therefore, they are 434 vulnerable to resource exhaustion attack. Attackers can 435 continuously send requests to specific things so as to deplete 436 their resources. This is especially dangerous in the Internet 437 of Things since an attacker might be located in the backend and 438 target resource-constrained devices that are part of a 439 constrained node network [RFC7228]. DoS attack can also be 440 launched by physically jamming the communication channel. 441 Network availability can also be disrupted by flooding the 442 network with a large number of packets. On the other hand, 443 things compromised by attackers can be used to disrupt the 444 operation of other networks or systems by means of a Distributed 445 DoS (DDoS) attack. 447 To deal with above threats it is required to find and apply suitable 448 security mitigations. However, new threats and exploits appear on a 449 daily basis and products are deployed in different environments prone 450 to different types of threats. Thus, ensuring a proper level of 451 security in an IoT system at any point of time is challenging. To 452 address this challenge, some of the following methodologies can be 453 used: 455 1. A Business Impact Analysis (BIA) assesses the consequences of the 456 loss of basic security attributes: confidentiality, integrity and 457 availability in an IoT system. These consequences might include 458 the impact from lost data, reduced sales, increased expenses, 459 regulatory fines, customer dissatisfaction, etc. Performing a 460 business impact analysis allows a business to determine the 461 relevance of having a proper security design. 463 2. A Risk Assessment (RA) analyzes security threats to an IoT system 464 while considering their likelihood and impact. It also includes 465 categorizing each of them with a risk level. Risks classified as 466 moderate or high must be mitigated, i.e., the security 467 architecture should be able to deal with those threat. 469 3. A privacy impact assessment (PIA) aims at assessing the 470 Personally Identifiable Information (PII) that is collected, 471 processed, or used in an IoT system. By doing so, the goal is to 472 fulfill applicable legal requirements, determine risks and 473 effects of manipulation and loss of PII. 475 4. Procedures for incident reporting and mitigation refer to the 476 methodologies that allow becoming aware of any security issues 477 that affect an IoT system. Furthermore, this includes steps 478 towards the actual deployment of patches that mitigate the 479 identified vulnerabilities. 481 BIA, RA, and PIA should generally be realized during the creation of 482 a new IoT system or when deploying significant system/feature 483 upgrades. In general, it is recommended to re-assess them on a 484 regular basis taking into account new use cases and/or threats. 486 4. State-of-the-Art 488 This section is organized as follows. Section 4.1 summarizes state- 489 of-the-art on IP-based IoT systems, within IETF and in other 490 standardization bodies. Section 4.2 summarizes state-of-the-art on 491 IP-based security protocols and their usage. Section 4.3 discusses 492 guidelines and regulations for securing IoT as proposed by other 493 bodies. 495 4.1. IP-based IoT Protocols and Standards 497 Nowadays, there exists a multitude of control protocols for IoT. For 498 BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI 499 [DALI] play key roles. Recent trends, however, focus on an all-IP 500 approach for system control. 502 In this setting, a number of IETF working groups are designing new 503 protocols for resource-constrained networks of smart things. The 504 6LoWPAN working group [WG-6LoWPAN] for example has defined methods 505 and protocols for the efficient transmission and adaptation of IPv6 506 packets over IEEE 802.15.4 networks [RFC4944]. 508 The CoRE working group [WG-CoRE] has specified the Constrained 509 Application Protocol (CoAP) [RFC7252]. CoAP is a RESTful protocol 510 for constrained devices that is modeled after HTTP and typically runs 511 over UDP to enable efficient application-level communication for 512 things. 514 In many smart object networks, the smart objects are dispersed and 515 have intermittent reachability either because of network outages or 516 because they sleep during their operational phase to save energy. In 517 such scenarios, direct discovery of resources hosted on the 518 constrained server might not be possible. To overcome this barrier, 519 the CoRE working group is specifying the concept of a Resource 520 Directory (RD) [ID-rd]. The Resource Directory hosts descriptions of 521 resources which are located on other nodes. These resource 522 descriptions are specified as CoRE link format [RFC6690]. 524 While CoAP defines a standard communication protocol, a format for 525 representing sensor measurements and parameters over CoAP is 526 required. The Sensor Measurement Lists (SenML) [ID-senml] is a 527 specification that defines media types for simple sensor measurements 528 and parameters. It has a minimalistic design so that constrained 529 devices with limited computational capabilities can easily encode 530 their measurements and, at the same time, servers can efficiently 531 collect large number of measurements. 533 In many IoT deployments, the resource-constrained smart objects are 534 connected to the Internet via a gateway that is directly reachable. 535 For example, an IEEE 802.11 Access Point (AP) typically connects the 536 client devices to the Internet over just one wireless hop. However, 537 some deployments of smart object networks require routing between the 538 smart objects themselves. The IETF has therefore defined the IPv6 539 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550]. 540 RPL provides support for multipoint-to-point traffic from resource- 541 constrained smart objects towards a more resourceful central control 542 point, as well as point-to-multipoint traffic in the reverse 543 direction. It also supports point-to-point traffic between the 544 resource-constrained devices. A set of routing metrics and 545 constraints for path calculation in RPL are also specified [RFC6551]. 547 The IPv6 over Networks of Resource-constrained Nodes (6lo) [WG-6lo] 548 working group of the IETF has specified how IPv6 packets can be 549 transmitted over various link layer protocols that are commonly 550 employed for resource-constrained smart object networks. There is 551 also ongoing work to specify IPv6 connectivity for a Non-Broadcast 552 Multi-Access (NBMA) mesh network that is formed by IEEE 802.15.4 553 TimeSlotted Channel Hopping (TSCH} links [ID-6tisch]. Other link 554 layer protocols for which IETF has specified or is currently 555 specifying IPv6 support include Bluetooth [RFC7668], Digital Enhanced 556 Cordless Telecommunications (DECT) Ultra Low Energy (ULE) air 557 interface [RFC8105], and Near Field Communication (NFC) [ID-6lonfc]. 559 Baker and Meyer [RFC6272] identify which IP protocols can be used in 560 smart grid environments. They give advice to smart grid network 561 designers on how they can decide on a profile of the Internet 562 protocol suite for smart grid networks. 564 The Low Power Wide-Area Network (LPWAN) working [WG-LPWAN] group is 565 analyzing features, requirements, and solutions to adapt IP-based 566 protocols to networks such as LORA [lora], SigFox [sigfox], NB-IoT 567 [nbiot], etc. These networking technologies enable a smart thing to 568 run for years on a single coin-cell by relying on a star network 569 topology and using optimized radio modulation with frame sizes in the 570 order of tens of bytes. Such networks bring new security challenges 571 since most existing security mechanism do not work well with such 572 resource constraints. 574 JavaScript Object Notation (JSON) is a lightweight text 575 representation format for structured data [RFC8259]. It is often 576 used for transmitting serialized structured data over the network. 577 IETF has defined specifications for encoding cryptographic keys, 578 encrypted content, signed content, and claims to be transferred 579 between two parties as JSON objects. They are referred to as JSON 580 Web Keys (JWK) [RFC7517], JSON Web Encryption (JWE) [RFC7516], JSON 581 Web Signatures (JWS) [RFC7515] and JSON Web Token (JWT) [RFC7519]. 583 An alternative to JSON, Concise Binary Object Representation (CBOR) 584 [RFC7049] is a concise binary data format that is used for 585 serialization of structured data. It is designed for resource- 586 constrained nodes and therefore it aims to provide a fairly small 587 message size with minimal implementation code, and extensibility 588 without the need for version negotiation. CBOR Object Signing and 589 Encryption (COSE) [RFC8152] specifies how to encode cryptographic 590 keys, message authentication codes, encrypted content, and signatures 591 with CBOR. 593 The Light-Weight Implementation Guidance (LWIG) working group 594 [WG-LWIG] is collecting experiences from implementers of IP stacks in 595 constrained devices. The working group has already produced 596 documents such as RFC7815 [RFC7815] which defines how a minimal 597 Internet Key Exchange Version 2 (IKEv2) initiator can be implemented. 599 The Thing-2-Thing Research Group (T2TRG) [RG-T2TRG] is investigating 600 the remaining research issues that need to be addressed to quickly 601 turn the vision of IoT into a reality where resource-constrained 602 nodes can communicate with each other and with other more capable 603 nodes on the Internet. 605 Additionally, industry alliances and other standardization bodies are 606 creating constrained IP protocol stacks based on the IETF work. Some 607 important examples of this include: 609 1. Thread [Thread]: Specifies the Thread protocol that is intended 610 for a variety of IoT devices. It is an IPv6-based network 611 protocol that runs over IEEE 802.15.4. 613 2. Industrial Internet Consortium [IIoT]: The consortium defines 614 reference architectures and security frameworks for development, 615 adoption and widespread use of Industrial Internet technologies 616 based on existing IETF standards. 618 3. Internet Protocol for Smart Objects IPSO [IPSO]: The alliance 619 specifies a common object model that enables application software 620 on any device to interoperate with other conforming devices. 622 4. OneM2M [OneM2M]: The standards body defines technical and API 623 specifications for IoT devices. It aims to create a service 624 layer that can run on any IoT device hardware and software. 626 5. Open Connectivity Foundation (OCF) [OCF]: The foundation develops 627 standards and certifications primarily for IoT devices that use 628 Constrained Application Protocol (CoAP) as the application layer 629 protocol. 631 6. Fairhair Alliance [Fairhair]: Specifies an IoT middleware to 632 enable interoperability between different application standards 633 used in building automation and lighting systems. 635 7. OMA LWM2M [LWM2M]: OMA Lightweight M2M is a standard from the 636 Open Mobile Alliance for M2M and IoT device management. LWM2M 637 relies on CoAP as the application layer protocol and uses a 638 RESTful architecture for remote management of IoT devices. 640 4.2. Existing IP-based Security Protocols and Solutions 642 There are three main security objectives for IoT networks: 1. 643 protecting the IoT network from attackers. 2. protecting IoT 644 applications and thus, the things and users. 3. protecting the rest 645 of the Internet and other things from attacks that use compromised 646 things as an attack platform. 648 In the context of the IP-based IoT deployments, consideration of 649 existing Internet security protocols is important. There are a wide 650 range of specialized as well as general-purpose security solutions 651 for the Internet domain such as IKEv2/IPsec [RFC7296], TLS [RFC5246], 652 DTLS [RFC6347], HIP [RFC7401], PANA [RFC5191], and EAP [RFC3748]. 654 TLS provides security for TCP and requires a reliable transport. 655 DTLS secures and uses datagram-oriented protocols such as UDP. Both 656 protocols are intentionally kept similar and share the same ideology 657 and cipher suites. The CoAP base specification [RFC7252] provides a 658 description of how DTLS can be used for securing CoAP. It proposes 659 three different modes for using DTLS: the PreSharedKey mode, where 660 nodes have pre-provisioned keys for initiating a DTLS session with 661 another node, RawPublicKey mode, where nodes have asymmetric-key 662 pairs but no certificates to verify the ownership, and Certificate 663 mode, where public keys are certified by a certification authority. 664 An IoT implementation profile [RFC7925] is defined for TLS version 665 1.2 and DTLS version 1.2 that offers communication security for 666 resource-constrained nodes. 668 There is ongoing work to define an authorization and access-control 669 framework for resource-constrained nodes. The Authentication and 670 Authorization for Constrained Environments (ACE) [WG-ACE] working 671 group is defining a solution to allow only authorized access to 672 resources that are hosted on a smart object server and are identified 673 by a URI. The current proposal [ID-aceoauth] is based on the OAuth 674 2.0 framework [RFC6749] and it comes with profiles intended for 675 different communication scenarios, e.g. DTLS Profile for 676 Authentication and Authorization for Constrained Environments 677 [ID-acedtls]. 679 The CoAP base specification [RFC7252] provides a description of how 680 DTLS can be used for securing CoAP. It proposes three different 681 modes for using DTLS: the PreSharedKey mode, where nodes have pre- 682 provisioned keys for initiating a DTLS session with another node, 683 RawPublicKey mode, where nodes have asymmetric-key pairs but no 684 certificates to verify the ownership, and Certificate mode, where 685 public keys are certified by a certification authority. An IoT 686 implementation profile [RFC7925] is defined for TLS version 1.2 and 687 DTLS version 1.2 that offers communication security for resource- 688 constrained nodes. 690 OSCORE [ID-OSCORE] is a proposal that protects CoAP messages by 691 wrapping them in the CBOR Object Signing and Encryption (COSE) 692 [RFC8152] format. Thus, OSCORE falls in the category of object 693 security and it can be applied wherever CoAP can be used. The 694 advantage of OSCORE over DTLS is that it provides some more 695 flexibility when dealing with end-to-end security. Section 5.1.3 696 discusses this further. 698 The Automated Certificate Management Environment (ACME) [WG-ACME] 699 working group is specifying conventions for automated X.509 700 certificate management. This includes automatic validation of 701 certificate issuance, certificate renewal, and certificate 702 revocation. While the initial focus of working group is on domain 703 name certificates (as used by web servers), other uses in some IoT 704 deployments is possible. 706 The Internet Key Exchange (IKEv2)/IPsec - as well as the less used 707 Host Identity protocol (HIP) - reside at or above the network layer 708 in the OSI model. Both protocols are able to perform an 709 authenticated key exchange and set up the IPsec for secure payload 710 delivery. Currently, there are also ongoing efforts to create a HIP 711 variant coined Diet HIP [ID-HIP-DEX] that takes constrained networks 712 and nodes into account at the authentication and key exchange level. 714 Migault et al. [ID-dietesp] are working on a compressed version of 715 IPsec so that it can easily be used by resource-constrained IoT 716 devices. They rely on the Internet Key Exchange Protocol version 2 717 (IKEv2) for negotiating the compression format. 719 The Extensible Authentication Protocol (EAP) [RFC3748] is an 720 authentication framework supporting multiple authentication methods. 721 EAP runs directly over the data link layer and, thus, does not 722 require the deployment of IP. It supports duplicate detection and 723 retransmission, but does not allow for packet fragmentation. The 724 Protocol for Carrying Authentication for Network Access (PANA) is a 725 network-layer transport for EAP that enables network access 726 authentication between clients and the network infrastructure. In 727 EAP terms, PANA is a UDP-based EAP lower layer that runs between the 728 EAP peer and the EAP authenticator. 730 4.3. IoT Security Guidelines 732 Attacks on and from IoT devices have become common in the last years, 733 for instance, large scale Denial of Service (DoS) attacks on the 734 Internet Infrastructure from compromised IoT devices. This fact has 735 prompted many different standards bodies and consortia to provide 736 guidelines for developers and the Internet community at large to 737 build secure IoT devices and services. A subset of the different 738 guidelines and ongoing projects are as follows: 740 1. GSMA IoT security guidelines [GSMAsecurity]: GSMA has published 741 a set of security guidelines for the benefit of new IoT product 742 and service providers. The guidelines are aimed at device 743 manufacturers, service providers, developers and network 744 operators. An enterprise can complete an IoT Security Self- 745 Assessment to demonstrate that its products and services are 746 aligned with the security guidelines of the GSMA. 748 2. BITAG Internet of Things (IoT) Security and Privacy 749 Recommendations [BITAG]: Broadband Internet Technical Advisory 750 Group (BITAG) has also published recommendations for ensuring 751 security and privacy of IoT device users. BITAG observes that 752 many IoT devices are shipped from the factory with software that 753 is already outdated and vulnerable. The report also states that 754 many devices with vulnerabilities will not be fixed either 755 because the manufacturer does not provide updates or because the 756 user does not apply them. The recommendations include that IoT 757 devices should function without cloud and Internet connectivity, 758 and that all IoT devices should have methods for automatic 759 secure software updates. 761 3. CSA New Security Guidance for Early Adopters of the IoT [CSA]: 762 The Cloud Security Alliance (CSA) recommendations for early 763 adopters of IoT encourages enterprises to implement security at 764 different layers of the protocol stack. It also recommends 765 implementation of an authentication/authorization framework for 766 IoT deployments. A complete list of recommendations is 767 available in the report [CSA]. 769 4. U.S. Department of Homeland Security [DHS]: DHS has put forth 770 six strategic principles that would enable IoT developers, 771 manufacturers, service providers and consumers to maintain 772 security as they develop, manufacture, implement or use network- 773 connected IoT devices. 775 5. NIST [NIST-Guide]: The NIST special publication urges enterprise 776 and US federal agencies to address security throughout the 777 systems engineering process. The publication builds upon the 778 ISO/IEC 15288 standard and augments each process in the system 779 lifecycle with security enhancements. 781 6. NIST [nist_lightweight_project]: NIST is running a project on 782 lightweight cryptography with the purpose of: (i) identifying 783 application areas for which standard cryptographic algorithms 784 are too heavy, classifying them according to some application 785 profiles to be determined; (ii) determining limitations in those 786 existing cryptographic standards; and (iii) standardizing 787 lightweight algorithms that can be used in specific application 788 profiles. 790 7. OWASP [OWASP]: Open Web Application Security Project (OWASP) 791 provides security guidance for IoT manufactures, developers and 792 consumers. OWASP also includes guidelines for those who intend 793 to test and analyze IoT devices and applications. 795 8. IoT Security foundation [IoTSecFoundation]: IoT security 796 foundation has published a document that enlists various 797 considerations that need to be taken into account when 798 developing IoT applications. For example, the document states 799 that IoT devices could use hardware-root of trust to ensure that 800 only authorized software runs on the devices. 802 9. NHTSA [NHTSA]: The US National Highway Traffic Safety 803 Administration provides a set of non-binding guidance to the 804 automotive industry for improving the cyber security of 805 vehicles. While some of the guidelines are general, the 806 document provides specific recommendations for the automotive 807 industry such as how various automotive manufacturer can share 808 cyber security vulnerabilities discovered. 810 10. Best Current Practices (BCP) for IoT devices [ID-Moore]: This 811 document provides a list of minimum requirements that vendors of 812 Internet of Things (IoT) devices should to take into account 813 while developing applications, services and firmware updates in 814 order to reduce the frequency and severity of security incidents 815 that arise from compromised IoT devices. 817 11. ENISA [ENISA_ICS]: The European Union Agency for Network and 818 Information Security published a document on communication 819 network dependencies for ICS/SCADA systems in which security 820 vulnerabilities, guidelines and general recommendations are 821 summarized. 823 Other guideline and recommendation documents may exist or may later 824 be published. This list should be considered non-exhaustive. 825 Despite the acknowledgment that security in the Internet is needed 826 and the existence of multiple guidelines, the fact is that many IoT 827 devices and systems have very limited security. There are multiple 828 reasons for this. For instance, some manufactures focus on 829 delivering a product without paying enough attention to security. 830 This may be because of lack of expertise or limited budget. However, 831 the deployment of such insecure devices poses a severe threat on the 832 privacy and safety of users. The vast amount of devices and their 833 inherent mobile nature also implies that an initially secure system 834 can become insecure if a compromised device gains access to the 835 system at some point in time. Even if all other devices in a given 836 environment are secure, this does not prevent external (passive) 837 attacks caused by insecure devices. Recently the Federal 838 Communications Commission (FCC) [FCC] has stated the need for 839 additional regulation of IoT systems. It is possible that we may see 840 other such regional regulations in the future. 842 5. Challenges for a Secure IoT 844 In this section, we take a closer look at the various security 845 challenges in the operational and technical features of IoT and then 846 discuss how existing Internet security protocols cope with these 847 technical and conceptual challenges through the lifecycle of a thing. 848 This discussion should neither be understood as a comprehensive 849 evaluation of all protocols, nor can it cover all possible aspects of 850 IoT security. Yet, it aims at showing concrete limitations and 851 challenges in some IoT design areas rather than giving an abstract 852 discussion. In this regard, the discussion handles issues that are 853 most important from the authors' perspectives. 855 5.1. Constraints and Heterogeneous Communication 857 Coupling resource-constrained networks and the powerful Internet is a 858 challenge because the resulting heterogeneity of both networks 859 complicates protocol design and system operation. In the following 860 we briefly discuss the resource constraints of IoT devices and the 861 consequences for the use of Internet Protocols in the IoT domain. 863 5.1.1. Resource Constraints 865 IoT deployments are often characterized by lossy and low-bandwidth 866 communication channels. IoT devices are also often constrained in 867 terms of CPU, memory, and energy budget available [RFC7228]. These 868 characteristics directly impact the threats to and the design of 869 security protocols for the IoT domain. First, the use of small 870 packets, for example, IEEE 802.15.4 supports 127-byte sized packets 871 at the physical layer, may result in fragmentation of larger packets 872 required by security protocols. This may open new attack vectors for 873 state exhaustion DoS attacks, which is especially tragic, for 874 example, if the fragmentation is caused by large key exchange 875 messages of security protocols. Moreover, packet fragmentation 876 commonly downgrades the overall system performance due to fragment 877 losses and the need for retransmissions. For instance, fate-sharing 878 packet flight as implemented by DTLS might aggravate the resulting 879 performance loss. 881 The size and number of messages should be minimized to reduce memory 882 requirements and optimize bandwidth usage. In this context, layered 883 approaches involving a number of protocols might lead to worse 884 performance in resource-constrained devices since they combine the 885 headers of the different protocols. In some settings, protocol 886 negotiation can increase the number of exchanged messages. To 887 improve performance during basic procedures such as, for example, 888 bootstrapping, it might be a good strategy to perform those 889 procedures at a lower layer. 891 Small CPUs and scarce memory limit the usage of resource-expensive 892 cryptographic primitives such as public-key cryptography as used in 893 most Internet security standards. This is especially true if the 894 basic cryptographic blocks need to be frequently used or the 895 underlying application demands low delay. 897 There are ongoing efforts to reduce the resource consumption of 898 security protocols by using more efficient underlying cryptographic 899 primitives such as Elliptic Curve Cryptography [RFC5246]. The 900 specification of elliptic curve X25519 [ecc25519], stream ciphers 901 such as ChaCha [ChaCha], Diet HIP [ID-HIP-DEX], and [RFC5903] are all 902 examples of efforts to make security protocols more resource 903 efficient. Additionally, all security protocols have been revised in 904 the last few years to enable cryptographic agility, making 905 cryptographic primitives interchangeable. However, these 906 improvements are only a first step in reducing the computation and 907 communication overhead of Internet protocols. The question remains 908 if other approaches can be applied to leverage key agreement in these 909 heavily resource-constrained environments. 911 A further fundamental need refers to the limited energy budget 912 available to IoT nodes. Careful protocol (re)design and usage is 913 required to reduce not only the energy consumption during normal 914 operation, but also under DoS attacks. Since the energy consumption 915 of IoT devices differs from other device classes, judgments on the 916 energy consumption of a particular protocol cannot be made without 917 tailor-made IoT implementations. 919 5.1.2. Denial-of-Service Resistance 921 The tight memory and processing constraints of things naturally 922 alleviate resource exhaustion attacks. Especially in unattended T2T 923 communication, such attacks are difficult to notice before the 924 service becomes unavailable (for example, because of battery or 925 memory exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and 926 Diet HIP implement return routability checks based on a cookie 927 mechanism to delay the establishment of state at the responding host 928 until the address of the initiating host is verified. The 929 effectiveness of these defenses strongly depend on the routing 930 topology of the network. Return routability checks are particularly 931 effective if hosts cannot receive packets addressed to other hosts 932 and if IP addresses present meaningful information as is the case in 933 today's Internet. However, they are less effective in broadcast 934 media or when attackers can influence the routing and addressing of 935 hosts (for example, if hosts contribute to the routing infrastructure 936 in ad-hoc networks and meshes). 938 In addition, HIP implements a puzzle mechanism that can force the 939 initiator of a connection (and potential attacker) to solve 940 cryptographic puzzles with variable difficulties. Puzzle-based 941 defense mechanisms are less dependent on the network topology but 942 perform poorly if CPU resources in the network are heterogeneous (for 943 example, if a powerful Internet host attacks a thing). Increasing 944 the puzzle difficulty under attack conditions can easily lead to 945 situations where a powerful attacker can still solve the puzzle while 946 weak IoT clients cannot and are excluded from communicating with the 947 victim. Still, puzzle-based approaches are a viable option for 948 sheltering IoT devices against unintended overload caused by 949 misconfiguration or malfunctioning things. 951 5.1.3. End-to-end security, protocol translation, and the role of 952 middleboxes 954 The term end-to-end security often has multiple interpretations. 955 Here, we consider end-to-end security in the context end-to-end IP 956 connectivity, from a sender to a receiver. Services such as 957 confidentiality and integrity protection on packet data, message 958 authentication codes or encryption are typically used to provide end- 959 to-end security. These protection methods render the protected parts 960 of the packets immutable as rewriting is either not possible because 961 a) the relevant information is encrypted and inaccessible to the 962 gateway or b) rewriting integrity-protected parts of the packet would 963 invalidate the end-to-end integrity protection. 965 Protocols for constrained IoT networks are not exactly identical to 966 their larger Internet counterparts for efficiency and performance 967 reasons. Hence, more or less subtle differences between protocols 968 for constrained IoT networks and Internet protocols will remain. 969 While these differences can be bridged with protocol translators at 970 middleboxes, they may become major obstacles if end-to-end security 971 measures between IoT devices and Internet hosts are needed. 973 If access to data or messages by the middleboxes is required or 974 acceptable, then a diverse set of approaches for handling such a 975 scenario are available. Note that some of these approaches affect 976 the meaning of end-to-end security in terms of integrity and 977 confidentiality since the middleboxes will be able to either decrypt 978 or modify partially the exchanged messages: 980 1. Sharing credentials with middleboxes enables them to transform 981 (for example, decompress, convert, etc.) packets and re-apply the 982 security measures after transformation. This method abandons 983 end-to-end security and is only applicable to simple scenarios 984 with a rudimentary security model. 986 2. Reusing the Internet wire format for IoT makes conversion between 987 IoT and Internet protocols unnecessary. However, it can lead to 988 poor performance in some use cases because IoT specific 989 optimizations (for example, stateful or stateless compression) 990 are not possible. 992 3. Selectively protecting vital and immutable packet parts with a 993 message authentication code or with encryption requires a careful 994 balance between performance and security. Otherwise this 995 approach might either result in poor performance or poor security 996 depending on which parts are selected for protection, where they 997 are located in the original packet, and how they are processed. 998 [ID-OSCORE] proposes a solution in this direction by encrypting 999 and integrity protecting most of the message fields except those 1000 parts that a middlebox needs to read or change. 1002 4. Homomorphic encryption techniques can be used in the middlebox to 1003 perform certain operations. However, this is limited to data 1004 processing involving arithmetic operations. Furthermore, 1005 performance of existing libraries, for example, SEAL [SEAL] is 1006 still too limited and it is is not widely applicable yet. 1008 5. Message authentication codes that sustain transformation can be 1009 realized by considering the order of transformation and 1010 protection (for example, by creating a signature before 1011 compression so that the gateway can decompress the packet without 1012 recalculating the signature). Such an approach enables IoT 1013 specific optimizations but is more complex and may require 1014 application-specific transformations before security is applied. 1015 Moreover, the usage of encrypted or integrity-protected data 1016 prevents middleboxes from transforming packets. 1018 6. Mechanisms based on object security can bridge the protocol 1019 worlds, but still require that the two worlds use the same object 1020 security formats. Currently the object security format based on 1021 CBOR Object Signing and Encryption (COSE) [RFC8152] (IoT 1022 protocol) is different from JSON Object Signing and Encryption 1023 (JOSE) [RFC7520] or Cryptographic Message Syntax (CMS) [RFC5652]. 1024 Legacy devices relying on traditional Internet protocols will 1025 need to update to the newer protocols for constrained 1026 environments to enable real end-to-end security. Furthermore, 1027 middleboxes do not have any access to the data and this approach 1028 does not prevent an attacker from modifying relevant fields in 1029 CoAP. 1031 To the best of our knowledge, none of the mentioned security 1032 approaches that focus on the confidentiality and integrity of the 1033 communication exchange between two IP end-points provide the perfect 1034 solution in this problem space. 1036 We finally note that end-to-end security can also be considered in 1037 the context of availability: making sure that the messages are 1038 delivered. In this case, the end-points cannot control this, but the 1039 middleboxes play a fundamental role to make sure that exchanged 1040 messages are not dropped, for example, due to a DDoS attack. 1042 5.1.4. New network architectures and paradigm 1044 There is a multitude of new link layer protocols that aim to address 1045 the resource-constrained nature of IoT devices. For example, the 1046 IEEE 802.11 ah [IEEE802ah] has been specified for extended range and 1047 lower energy consumption to support Internet of Things (IoT) devices. 1048 Similarly, Low-Power Wide-Area Network (LPWAN) protocols such as LoRa 1049 [lora], Sigfox [sigfox], NarrowBand IoT (NB-IoT) [nbiot] are all 1050 designed for resource-constrained devices that require long range and 1051 low bit rates. [ID-lpwan] provides an informational overview of the 1052 set of LPWAN technologies being considered by the IETF. It also 1053 identifies the potential gaps that exist between the needs of those 1054 technologies and the goal of running IP in such networks. While 1055 these protocols allow IoT devices to conserve energy and operate 1056 efficiently, they also add additional security challenges. For 1057 example, the relatively small MTU can make security handshakes with 1058 large X509 certificates a significant overhead. At the same time, 1059 new communication paradigms also allow IoT devices to communicate 1060 directly amongst themselves with or without support from the network. 1061 This communication paradigm is also referred to as Device-to-Device 1062 (D2D) or Machine-to-Machine (M2M) or Thing-to-Thing (T2T) 1063 communication and it is motivated by a number of features such as 1064 improved network performance, lower latency and lower energy 1065 requirements. 1067 5.2. Bootstrapping of a Security Domain 1069 Creating a security domain from a set of previously unassociated IoT 1070 devices is a key operation in the lifecycle of a thing in an IoT 1071 network. This aspect is further elaborated and discussed in the 1072 T2TRG draft on bootstrapping [ID-bootstrap]. 1074 5.3. Operational Challenges 1076 After the bootstrapping phase, the system enters the operational 1077 phase. During the operational phase, things can use the state 1078 information created during the bootstrapping phase in order to 1079 exchange information securely. In this section, we discuss the 1080 security challenges during the operational phase. Note that many of 1081 the challenges discussed in Section 5.1 apply during the operational 1082 phase. 1084 5.3.1. Group Membership and Security 1086 Group key negotiation is an important security service for IoT 1087 communication patterns in which a thing sends some data to multiple 1088 things or data flows from multiple things towards a thing. All 1089 discussed protocols only cover unicast communication and therefore, 1090 do not focus on group-key establishment. This applies in particular 1091 to (D)TLS and IKEv2. Thus, a solution is required in this area. A 1092 potential solution might be to use the Diffie-Hellman keys - that are 1093 used in IKEv2 and HIP to setup a secure unicast link - for group 1094 Diffie-Hellman key-negotiations. However, Diffie-Hellman is a 1095 relatively heavy solution, especially if the group is large. 1097 Symmetric and asymmetric keys can be used in group communication. 1098 Asymmetric keys have the advantage that they can provide source 1099 authentication. However, doing broadcast encryption with a single 1100 public/private key pair is also not feasible. Although a single 1101 symmetric key can be used to encrypt the communication or compute a 1102 message authentication code, it has inherent risks since the capture 1103 of a single node can compromise the key shared throughout the 1104 network. The usage of symmetric-keys also does not provide source 1105 authentication. Another factor to consider is that asymmetric 1106 cryptography is more resource-intensive than symmetric key solutions. 1107 Thus, the security risks and performance trade-offs of applying 1108 either symmetric or asymmetric keys to a given IoT use case need to 1109 be well-analyzed according to risk and usability assessments. 1110 [ID-multicast] is looking at a combination of symmetric (for 1111 encryption) and asymmetric (for authentication) in the same packet. 1113 Conceptually, solutions that provide secure group communication at 1114 the network layer (IPsec/IKEv2, HIP/Diet HIP) may have an advantage 1115 in terms of the cryptographic overhead when compared to application- 1116 focused security solutions (TLS/ DTLS). This is due to the fact that 1117 application-focused solutions require cryptographic operations per 1118 group application, whereas network layer approaches may allow sharing 1119 secure group associations between multiple applications (for example, 1120 for neighbor discovery and routing or service discovery). Hence, 1121 implementing shared features lower in the communication stack can 1122 avoid redundant security measures. However, it is important to note 1123 that sharing security contexts among different applications involves 1124 potential security threats, e.g., if one of the applications is 1125 malicious and monitors exchanged messages or injects fake messages. 1126 In the case of OSCORE, it provides security for CoAP group 1127 communication as defined in RFC7390, i.e., based on multicast IP. If 1128 the same security association is reused for each application, then 1129 this solution does not seem to have more cryptographic overhead 1130 compared to IPsec. 1132 Several group key solutions have been developed by the MSEC working 1133 group [WG-MSEC] of the IETF. The MIKEY architecture [RFC4738] is one 1134 example. While these solutions are specifically tailored for 1135 multicast and group broadcast applications in the Internet, they 1136 should also be considered as candidate solutions for group key 1137 agreement in IoT. The MIKEY architecture for example describes a 1138 coordinator entity that disseminates symmetric keys over pair-wise 1139 end-to-end secured channels. However, such a centralized approach 1140 may not be applicable in a distributed IoT environment, where the 1141 choice of one or several coordinators and the management of the group 1142 key is not trivial. 1144 5.3.2. Mobility and IP Network Dynamics 1146 It is expected that many things (for example, wearable sensors, and 1147 user devices) will be mobile in the sense that they are attached to 1148 different networks during the lifetime of a security association. 1149 Built-in mobility signaling can greatly reduce the overhead of the 1150 cryptographic protocols because unnecessary and costly re- 1151 establishments of the session (possibly including handshake and key 1152 agreement) can be avoided. IKEv2 supports host mobility with the 1153 MOBIKE [RFC4555] and [RFC4621] extension. MOBIKE refrains from 1154 applying heavyweight cryptographic extensions for mobility. However, 1155 MOBIKE mandates the use of IPsec tunnel mode which requires the 1156 transmission of an additional IP header in each packet. 1158 HIP offers a simple yet effective mobility management by allowing 1159 hosts to signal changes to their associations [RFC8046]. However, 1160 slight adjustments might be necessary to reduce the cryptographic 1161 costs, for example, by making the public-key signatures in the 1162 mobility messages optional. Diet HIP does not define mobility yet 1163 but it is sufficiently similar to HIP and can use the same 1164 mechanisms. DTLS provides some mobility support by relying on a 1165 connection ID (CID). The use of connection IDs can provide all the 1166 mobility functionality described in [ID-Williams], except, sending 1167 the updated location. The specific need for IP-layer mobility mainly 1168 depends on the scenario in which the nodes operate. In many cases, 1169 mobility supported by means of a mobile gateway may suffice to enable 1170 mobile IoT networks, such as body sensor networks. Using message 1171 based application-layer security solutions such as OSCORE [ID-OSCORE] 1172 can also alleviate the problem of re-establishing lower-layer 1173 sessions for mobile nodes. 1175 5.4. Secure software update and cryptographic agility 1177 IoT devices are often expected to stay functional for several years 1178 and decades even though they might operate unattended with direct 1179 Internet connectivity. Software updates for IoT devices are 1180 therefore not only required for new functionality, but also to 1181 eliminate security vulnerabilities due to software bugs, design 1182 flaws, or deprecated algorithms. Software bugs might remain even 1183 after careful code review. Implementations of security protocols 1184 might contain (design) flaws. Cryptographic algorithms can also 1185 become insecure due to advances in cryptanalysis. Therefore, it is 1186 necessary that devices which are incapable of verifying a 1187 cryptographic signature are not exposed to the Internet (even 1188 indirectly). 1190 Schneier [SchneierSecurity] in his essay highlights several 1191 challenges that hinder mechanisms for secure software update of IoT 1192 devices. First, there is a lack of incentives for manufactures, 1193 vendors and others on the supply chain to issue updates for their 1194 devices. Second, parts of the software running on IoT devices is 1195 simply a binary blob without any source code available. Since the 1196 complete source code is not available, no patches can be written for 1197 that piece of code. Lastly Schneier points out that even when 1198 updates are available, users generally have to manually download and 1199 install them. However, users are never alerted about security 1200 updates and at many times do not have the necessary expertise to 1201 manually administer the required updates. 1203 The FTC staff report on Internet of Things - Privacy & Security in a 1204 Connected World [FTCreport] and the Article 29 Working Party Opinion 1205 8/2014 on the Recent Developments on the Internet of Things 1206 [Article29] also document the challenges for secure remote software 1207 update of IoT devices. They note that even providing such a software 1208 update capability may add new vulnerabilities for constrained 1209 devices. For example, a buffer overflow vulnerability in the 1210 implementation of a software update protocol (TR69) [TR69] and an 1211 expired certificate in a hub device [wink] demonstrate how the 1212 software update process itself can introduce vulnerabilities. 1214 Powerful IoT devices that run general purpose operating systems can 1215 make use of sophisticated software update mechanisms known from the 1216 desktop world. However, resource-constrained devices typically do 1217 not have any operating system and are often not equipped with a 1218 memory management unit or similar tools. Therefore, they might 1219 require more specialized solutions. 1221 An important requirement for secure software and firmware updates is 1222 source authentication. Source authentication requires the resource- 1223 constrained things to implement public-key signature verification 1224 algorithms. As stated in Section 5.1.1, resource-constrained things 1225 have limited amount of computational capabilities and energy supply 1226 available which can hinder the amount and frequency of cryptographic 1227 processing that they can perform. In addition to source 1228 authentication, software updates might require confidential delivery 1229 over a secure (encrypted) channel. The complexity of broadcast 1230 encryption can force the usage of point-to-point secure links - 1231 however, this increases the duration of a software update in a large 1232 system. Alternatively, it may force the usage of solutions in which 1233 the software update is delivered to a gateway, and then distributed 1234 to the rest of the system with a network key. Sending large amounts 1235 of data that later needs to be assembled and verified over a secure 1236 channel can consume a lot of energy and computational resources. 1237 Correct scheduling of the software updates is also a crucial design 1238 challenge. For example, a user of connected light bulbs would not 1239 want them to update and restart at night. More importantly, the user 1240 would not want all the lights to update at the same time. 1242 Software updates in IoT systems are also needed to update old and 1243 insecure cryptographic primitives. However, many IoT systems, some 1244 of which are already deployed, are not designed with provisions for 1245 cryptographic agility. For example, many devices come with a 1246 wireless radio that has an AES128 hardware co-processor. These 1247 devices solely rely on the co-processor for encrypting and 1248 authenticating messages. A software update adding support for new 1249 cryptographic algorithms implemented solely in software might not fit 1250 on these devices due to limited memory, or might drastically hinder 1251 its operational performance. This can lead to the use of old and 1252 insecure devices. Therefore, it is important to account for the fact 1253 that cryptographic algorithms would need to be updated and consider 1254 the following when planning for cryptographic agility: 1256 1. Would it be safe to use the existing cryptographic algorithms 1257 available on the device for updating with new cryptographic 1258 algorithms that are more secure? 1260 2. Will the new software-based implementation fit on the device 1261 given the limited resources? 1263 3. Would the normal operation of existing IoT applications on the 1264 device be severely hindered by the update? 1266 Finally, we would like to highlight the previous and ongoing work in 1267 the area of secure software and firmware updates at the IETF. 1268 [RFC4108] describes how Cryptographic Message Syntax (CMS) [RFC5652] 1269 can be used to protect firmware packages. The IAB has also organized 1270 a workshop to understand the challenges for secure software update of 1271 IoT devices. A summary of the recommendations to the standards 1272 community derived from the discussions during that workshop have been 1273 documented [RFC8240]. Finally, a new working group called Software 1274 Updates for Internet of Things (suit) [WG-SUIT] is currently being 1275 chartered at the IETF. The working group aims to standardize a new 1276 version [RFC4108] that reflects the best current practices for 1277 firmware update based on experience with IoT deployments. It will 1278 specifically work on describing an IoT firmware update architecture 1279 and specifying a manifest format that contains meta-data about the 1280 firmware update package. 1282 5.5. End-of-Life 1284 Like all commercial devices, IoT devices have a given useful 1285 lifetime. The term end-of-life (EOL) is used by vendors or network 1286 operators to indicate the point of time in which they limit or end 1287 support for the IoT device. This may be planned or unplanned (for 1288 example when the vendor or manufacturer goes bankrupt or when a 1289 network operator moves to a different type of networking technology). 1290 A user should still be able to use and perhaps even update the 1291 device. This requires for some form of authorization handover. 1293 Although this may seem far-fetched given the commercial interests and 1294 market dynamics, we have examples from the mobile world where the 1295 devices have been functional and up-to-date long after the original 1296 vendor stopped supporting the device. CyanogenMod for Android 1297 devices, and OpenWrt for home routers are two such instances where 1298 users have been able to use and update their devices even after the 1299 official EOL. Admittedly it is not easy for an average user to 1300 install and configure their devices on their own. With the 1301 deployment of millions of IoT devices, simpler mechanisms are needed 1302 to allow users to add new root-of-trusts and install software and 1303 firmware from other sources once the device is EOL. 1305 5.6. Verifying device behavior 1307 Users using new IoT appliances such as Internet-connected smart 1308 televisions, speakers and cameras are often unaware that these 1309 devices can undermine their privacy. Recent revelations have shown 1310 that many IoT device vendors have been collecting sensitive private 1311 data through these connected appliances with or without appropriate 1312 user warnings [cctv]. 1314 An IoT device user/owner would like to monitor and verify its 1315 operational behavior. For instance, the user might want to know if 1316 the device is connecting to the server of the manufacturer for any 1317 reason. This feature - connecting to the manufacturer's server - may 1318 be necessary in some scenarios, such as during the initial 1319 configuration of the device. However, the user should be kept aware 1320 of the data that the device is sending back to the vendor. For 1321 example, the user might want to know if his/her TV is sending data 1322 when he/she inserts a new USB stick. 1324 Providing such information to the users in an understandable fashion 1325 is challenging. This is because IoT devices are not only resource- 1326 constrained in terms of their computational capability, but also in 1327 terms of the user interface available. Also, the network 1328 infrastructure where these devices are deployed will vary 1329 significantly from one user environment to another. Therefore, where 1330 and how this monitoring feature is implemented still remains an open 1331 question. 1333 Manufacturer Usage Description (MUD) files [ID-MUD] are perhaps a 1334 first step towards implementation of such a monitoring service. The 1335 idea behind MUD files is relatively simple: IoT devices would 1336 disclose the location of their MUD file to the network during 1337 installation. The network can then retrieve those files, and learn 1338 about the intended behavior of the devices stated by the device 1339 manufacturer. A network monitoring service could then warn the user/ 1340 owner of devices if they don't behave as expected. 1342 Many devices and software services that automatically learn and 1343 monitor the behavior of different IoT devices in a given network are 1344 commercially available. Such monitoring devices/services can be 1345 configured by the user to limit network traffic and trigger alarms 1346 when unexpected operation of IoT devices is detected. 1348 5.7. Testing: bug hunting and vulnerabilities 1350 Given that IoT devices often have inadvertent vulnerabilities, both 1351 users and developers would want to perform extensive testing on their 1352 IoT devices, networks, and systems. Nonetheless, since the devices 1353 are resource-constrained and manufactured by multiple vendors, some 1354 of them very small, devices might be shipped with very limited 1355 testing, so that bugs can remain and can be exploited at a later 1356 stage. This leads to two main types of challenges: 1358 1. It remains to be seen how the software testing and quality 1359 assurance mechanisms used from the desktop and mobile world will 1360 be applied to IoT devices to give end users the confidence that 1361 the purchased devices are robust. Bodies such as the European 1362 Cyber Security Organization (ECSO) [ECSO] are working on 1363 processes for security certification of IoT devices. 1365 2. It is also an open question how the combination of devices from 1366 multiple vendors might actually lead to dangerous network 1367 configurations. For example, if combination of specific devices 1368 can trigger unexpected behavior. It is needless to say that the 1369 security of the whole system is limited by its weakest point. 1371 5.8. Quantum-resistance 1373 Many IoT systems that are being deployed today will remain 1374 operational for many years. With the advancements made in the field 1375 of quantum computers, it is possible that large-scale quantum 1376 computers are available in the future for performing cryptanalysis on 1377 existing cryptographic algorithms and cipher suites. If this 1378 happens, it will have two consequences. First, functionalities 1379 enabled by means of RSA/ECC - namely key exchange, public-key 1380 encryption and signature - would not be secure anymore due to Shor's 1381 algorithm. Second, the security level of symmetric algorithms will 1382 decrease, for example, the security of a block cipher with a key size 1383 of b bits will only offer b/2 bits of security due to Grover's 1384 algorithm. 1386 The above scenario becomes more urgent when we consider the so called 1387 "harvest and decrypt" attack in which an attacker can start to 1388 harvest (store) encrypted data today, before a quantum-computer is 1389 available, and decrypt it years later, once a quantum computer is 1390 available. Similarly, many IoT devices that are being deployed today 1391 will remain operational for a decade or even longer. During this 1392 time, digital signatures used to sign software updates might become 1393 obsolete making the secure update of IoT devices challenging. 1395 This situation would require us to move to quantum-resistant 1396 alternatives, in particular, for those functionalities involving key 1397 exchange, public-key encryption and signatures. [ID-c2pq] describes 1398 when quantum computers may become widely available and what steps are 1399 necessary for transition to cryptographic algorithms that provide 1400 security even in presence of quantum computers. While future 1401 planning is hard, it may be a necessity in certain critical IoT 1402 deployments which are expected to last decades or more. Although 1403 increasing the key-size of the different algorithms is definitely an 1404 option, it would also incur additional computational overhead and 1405 network traffic. This would be undesirable in most scenarios. There 1406 have been recent advancements in quantum-resistant cryptography. 1408 We refer to [ETSI_GR_QSC_001] for an extensive overview of existing 1409 quantum-resistant cryptography. [RFC7696] provides guidelines for 1410 cryptographic algorithm agility. 1412 5.9. Privacy protection 1414 People will eventually be surrounded by hundreds of connected IoT 1415 devices. Even if the communication links are encrypted and 1416 protected, information about people might still be collected or 1417 processed for different purposes. The fact that IoT devices in the 1418 vicinity of people might enable more pervasive monitoring can 1419 negatively impact their privacy. For instance, imagine the scenario 1420 where a static presence sensor emits a packet due to the presence or 1421 absence of people in its vicinity. In such a scenario, anyone who 1422 can observe the packet, can gather critical privacy-sensitive 1423 information. 1425 Such information about people is referred to as personal data in the 1426 European Union (EU) or Personally identifiable information (PII) in 1427 the United States (US), In particular, the General Data Protection 1428 Regulation (GDPR) [GDPR] defines personal data as: 'any information 1429 relating to an identified or identifiable natural person ('data 1430 subject'); an identifiable natural person is one who can be 1431 identified, directly or indirectly, in particular by reference to an 1432 identifier such as a name, an identification number, location data, 1433 an online identifier or to one or more factors specific to the 1434 physical, physiological, genetic, mental, economic, cultural or 1435 social identity of that natural person'. 1437 Ziegeldorf [Ziegeldorf] defines privacy in IoT as a threefold 1438 guarantee: 1440 1. Awareness of the privacy risks imposed by IoT devices and 1441 services. This awareness is achieved by means of transparent 1442 practices by the data controller, i.e., the entity that is 1443 providing IoT devices and/or services. 1445 2. Individual control over the collection and processing of personal 1446 information by IoT devices and services. 1448 3. Awareness and control of the subsequent use and dissemination of 1449 personal information by data controllers to any entity outside 1450 the subject's personal control sphere. This point implies that 1451 the data controller must be accountable for its actions on the 1452 personal information. 1454 Based on this definition, several threats to the privacy of users 1455 have been documented [Ziegeldorf] and [RFC6973], in particular 1456 considering the IoT environment and its lifecycle: 1458 1. Identification - refers to the identification of the users, their 1459 IoT devices, and generated data. 1461 2. Localization - relates to the capability of locating a user and 1462 even tracking them, e.g., by tracking MAC addresses in Wi-Fi or 1463 Bluetooth. 1465 3. Profiling - is about creating a profile of the user and their 1466 preferences. 1468 4. Interaction - occurs when a user has been profiled and a given 1469 interaction is preferred, presenting (for example, visually) some 1470 information that discloses private information. 1472 5. Lifecycle transitions - take place when devices are, for example, 1473 is sold without properly removing private data. 1475 6. Inventory attacks - happen if specific information about IoT 1476 devices in possession of a user is disclosed. 1478 7. Linkage - is about when information of two of more IoT systems 1479 (or other data sets) is combined so that a broader view of the 1480 personal data captured can be created. 1482 When IoT systems are deployed, the above issues should be considered 1483 to ensure that private data remains private. These issues are 1484 particularly challenging in environments in which multiple users with 1485 different privacy preferences interact with the same IoT devices. 1486 For example, an IoT device controlled by user A (low privacy 1487 settings) might leak private information about another user B (high 1488 privacy settings). How to deal with these threats in practice is an 1489 area of ongoing research. 1491 5.10. Reverse engineering considerations 1493 Many IoT devices are resource-constrained and often deployed in 1494 unattended environments. Some of these devices can also be purchased 1495 off-the-shelf or online without any credential-provisioning process. 1496 Therefore, an attacker can have direct access to the device and apply 1497 advanced techniques to retrieve information that a traditional black 1498 box model does not consider. Example of those techniques are side- 1499 channel attacks or code disassembly. By doing this, the attacker can 1500 try to retrieve data such as: 1502 1. long term keys. These long term keys can be extracted by means 1503 of a side-channel attack or reverse engineering. If these keys 1504 are exposed, then they might be used to perform attacks on 1505 devices deployed in other locations. 1507 2. source code. Extraction of source code might allow the attacker 1508 to determine bugs or find exploits to perform other types of 1509 attacks. The attacker might also just sell the source code. 1511 3. proprietary algorithms. The attacker can analyze these 1512 algorithms gaining valuable know-how. The attacker can also 1513 create copies of the product (based on those proprietary 1514 algorithms) or modify the algorithms to perform more advanced 1515 attacks. 1517 4. configuration or personal data. The attacker might be able to 1518 read personal data, e.g., heatlhcare data, that has been stored 1519 on a device. 1521 One existing solution to prevent such data leaks is the use of a 1522 secure element, a tamper-resistant device that is capable of securely 1523 hosting applications and their confidential data. Another potential 1524 solution is the usage of of Physical Unclonable Function (PUFs) that 1525 serves as unique digital fingerprint of a hardware device. PUFs can 1526 also enable other functionalities such as secure key storage. 1527 Protection against such data leakage patterns is non-trivial since 1528 devices are inherently resource-constrained. An open question is 1529 whether there are any viable techniques to protect IoT devices and 1530 the data in the devices in such an adversarial model. 1532 5.11. Trustworthy IoT Operation 1534 Flaws in the design and implementation of IoT devices and networks 1535 can lead to security vulnerabilities. A common flaw is the use of 1536 well-known or easy-to-guess passwords for configuration of IoT 1537 devices. Many such compromised IoT devices can be found on the 1538 Internet by means of tools such as Shodan [shodan]. Once discovered, 1539 these compromised devices can be exploited at scale, for example, to 1540 launch DDoS attacks. Dyn, a major DNS , was attacked by means of a 1541 DDoS attack originating from a large IoT botnet composed of thousands 1542 of compromised IP-cameras [dyn-attack]. There are several open 1543 research questions in this area: 1545 1. How to avoid vulnerabilities in IoT devices that can lead to 1546 large-scale attacks? 1548 2. How to detect sophisticated attacks against IoT devices? 1550 3. How to prevent attackers from exploiting known vulnerabilities at 1551 a large scale? 1553 Some ideas are being explored to address this issue. One of the 1554 approaches relies on the use of Manufacturer Usage Description (MUD) 1555 files [ID-MUD]. As explained earlier, this proposal requires IoT 1556 devices to disclose the location of their MUD file to the network 1557 during installation. The network can then (i) retrieve those files, 1558 (ii) learn from the manufacturers the intended usage of the devices, 1559 for example, which services they need to access, and then (iii) 1560 create suitable filters and firewall rules. 1562 6. Conclusions and Next Steps 1564 This Internet Draft provides IoT security researchers, system 1565 designers and implementers with an overview of security requirements 1566 in the IP-based Internet of Things. We discuss the security threats, 1567 state-of-the-art, and challenges. 1569 Although plenty of steps have been realized during the last few years 1570 (summarized in Section 4.1) and many organizations are publishing 1571 general recommendations (Section 4.3) describing how IoT should be 1572 secured, there are many challenges ahead that require further 1573 attention. Challenges of particular importance are bootstrapping of 1574 security, group security, secure software updates, long-term security 1575 and quantum-resistance, privacy protection, data leakage prevention - 1576 where data could be cryptographic keys, personal data, or even 1577 algorithms - and ensuring trustworthy IoT operation. 1579 Authors of new IoT specifications and implementors need to consider 1580 how all the security challenges discussed in this draft (and those 1581 that emerge later) affect their work. The authors of IoT 1582 specifications not only need to put in a real effort towards 1583 addressing the security challenges, but also clearly documenting how 1584 the security challenges are addressed. This would reduce the chances 1585 of security vulnerabilities in the code written by implementors of 1586 those specifications. 1588 7. Security Considerations 1590 This entire memo deals with security issues. 1592 8. IANA Considerations 1594 This document contains no request to IANA. 1596 9. Acknowledgments 1598 We gratefully acknowledge feedback and fruitful discussion with 1599 Tobias Heer, Robert Moskowitz, Thorsten Dahm, Hannes Tschofenig, 1600 Carsten Bormann, Barry Raveendran, Ari Keranen, Goran Selander, Fred 1601 Baker, Vicent Roca, Thomas Fossati and Eliot Lear. We acknowledge 1602 the additional authors of the previous version of this document Sye 1603 Loong Keoh, Rene Hummen and Rene Struik. 1605 10. Informative References 1607 [Article29] 1608 "Opinion 8/2014 on the on Recent Developments on the 1609 Internet of Things", Web http://ec.europa.eu/justice/data- 1610 protection/article-29/documentation/opinion- 1611 recommendation/files/2014/wp223_en.pdf, n.d.. 1613 [AUTO-ID] "AUTO-ID LABS", Web http://www.autoidlabs.org/, September 1614 2010. 1616 [BACNET] "BACnet", Web http://www.bacnet.org/, February 2011. 1618 [BITAG] "Internet of Things (IoT) Security and Privacy 1619 Recommendations", Web http://www.bitag.org/report- 1620 internet-of-things-security-privacy-recommendations.php, 1621 n.d.. 1623 [cctv] "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an 1624 Email Address In China", Web 1625 https://hardware.slashdot.org/story/16/02/17/0422259/ 1626 backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an- 1627 email-address-in-china, n.d.. 1629 [ChaCha] Bernstein, D., "ChaCha, a variant of Salsa20", Web 1630 http://cr.yp.to/chacha/chacha-20080128.pdf, n.d.. 1632 [CSA] "Security Guidance for Early Adopters of the Internet of 1633 Things (IoT)", Web 1634 https://downloads.cloudsecurityalliance.org/whitepapers/Se 1635 curity_Guidance_for_Early_Adopters_of_the_Internet_of_Thin 1636 gs.pdf, n.d.. 1638 [DALI] "DALI", Web http://www.dalibydesign.us/dali.html, February 1639 2011. 1641 [DHS] "Strategic Principles For Securing the Internet of Things 1642 (IoT)", Web 1643 https://www.dhs.gov/sites/default/files/publications/ 1644 Strategic_Principles_for_Securing_the_Internet_of_Things- 1645 2016-1115-FINAL....pdf, n.d.. 1647 [dyn-attack] 1648 "Dyn Analysis Summary Of Friday October 21 Attack", Web 1649 https://dyn.com/blog/dyn-analysis-summary-of-friday- 1650 october-21-attack/, n.d.. 1652 [ecc25519] 1653 Bernstein, D., "Curve25519: new Diffie-Hellman speed 1654 records", 1655 Web https://cr.yp.to/ecdh/curve25519-20060209.pdf, n.d.. 1657 [ECSO] "European Cyber Security Organization", Web 1658 https://www.ecs-org.eu/, n.d.. 1660 [ENISA_ICS] 1661 "Communication network dependencies for ICS/SCADA 1662 Systems", European Union Agency For Network And 1663 Information Security , February 2017. 1665 [ETSI_GR_QSC_001] 1666 "Quantum-Safe Cryptography (QSC);Quantum-safe algorithmic 1667 framework", European Telecommunications Standards 1668 Institute (ETSI) , June 2016. 1670 [Fairhair] 1671 "Fairhair Alliance", Web https://www.fairhair- 1672 alliance.org/, n.d.. 1674 [FCC] "Federal Communications Comssion Response 12-05-2016", 1675 FCC , February 2016. 1677 [FTCreport] 1678 "FTC Report on Internet of Things Urges Companies to Adopt 1679 Best Practices to Address Consumer Privacy and Security 1680 Risks", Web https://www.ftc.gov/news-events/press- 1681 releases/2015/01/ftc-report-internet-things-urges- 1682 companies-adopt-best-practices, n.d.. 1684 [GDPR] "The EU General Data Protection Regulation", 1685 Web https://www.eugdpr.org/, n.d.. 1687 [GSMAsecurity] 1688 "GSMA IoT Security Guidelines", Web 1689 http://www.gsma.com/connectedliving/future-iot- 1690 networks/iot-security-guidelines/, n.d.. 1692 [ID-6lonfc] 1693 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 1694 "Transmission of IPv6 Packets over Near Field 1695 Communication", draft-ietf-6lo-nfc-09 (work in progress), 1696 January 2018. 1698 [ID-6tisch] 1699 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1700 of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work 1701 in progress), November 2017. 1703 [ID-acedtls] 1704 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1705 L. Seitz, "Datagram Transport Layer Security (DTLS) 1706 Profile for Authentication and Authorization for 1707 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1708 authorize-03 (work in progress), March 2018. 1710 [ID-aceoauth] 1711 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1712 H. Tschofenig, "Authentication and Authorization for 1713 Constrained Environments (ACE) using the OAuth 2.0 1714 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-11 1715 (work in progress), March 2018. 1717 [ID-bootstrap] 1718 Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT 1719 Bootstrapping: A Survey", draft-sarikaya-t2trg- 1720 sbootstrapping-03 (work in progress), February 2017. 1722 [ID-c2pq] Hoffman, P., "The Transition from Classical to Post- 1723 Quantum Cryptography", draft-hoffman-c2pq-03 (work in 1724 progress), February 2018. 1726 [ID-Daniel] 1727 Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. 1728 Laganier, "IPv6 over Low Power WPAN Security Analysis", 1729 draft-daniel-6lowpan-security-analysis-05 (work in 1730 progress), March 2011. 1732 [ID-dietesp] 1733 Migault, D., Guggemos, T., and C. Bormann, "Diet-ESP: a 1734 flexible and compressed format for IPsec/ESP", draft-mglt- 1735 6lo-diet-esp-02 (work in progress), July 2016. 1737 [ID-HIP-DEX] 1738 Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz- 1739 hip-rg-dex-06 (work in progress), May 2012. 1741 [ID-lpwan] 1742 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 1743 overview-10 (work in progress), February 2018. 1745 [ID-Moore] 1746 Moore, K., Barnes, R., and H. Tschofenig, "Best Current 1747 Practices for Securing Internet of Things (IoT) Devices", 1748 draft-moore-iot-security-bcp-01 (work in progress), July 1749 2017. 1751 [ID-MUD] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1752 Description Specification", draft-ietf-opsawg-mud-20 (work 1753 in progress), April 2018. 1755 [ID-multicast] 1756 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1757 "Secure group communication for CoAP", draft-ietf-core- 1758 oscore-groupcomm-01 (work in progress), March 2018. 1760 [ID-OSCORE] 1761 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1762 "Object Security for Constrained RESTful Environments 1763 (OSCORE)", draft-ietf-core-object-security-12 (work in 1764 progress), March 2018. 1766 [ID-rd] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1767 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1768 resource-directory-13 (work in progress), March 2018. 1770 [ID-senml] 1771 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 1772 Bormann, "Media Types for Sensor Measurement Lists 1773 (SenML)", draft-ietf-core-senml-14 (work in progress), 1774 April 2018. 1776 [ID-Williams] 1777 Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett- 1778 mobile-dtls-00 (work in progress), March 2009. 1780 [IEEE802ah] 1781 "Status of Project IEEE 802.11ah, IEEE P802.11- Task Group 1782 AH-Meeting Update.", 1783 Web http://www.ieee802.org/11/Reports/tgah_update.htm, 1784 n.d.. 1786 [IIoT] "Industrial Internet Consortium", 1787 Web http://www.iiconsortium.org/, n.d.. 1789 [IoTSecFoundation] 1790 "Establishing Principles for Internet of Things Security", 1791 Web https://iotsecurityfoundation.org/establishing- 1792 principles-for-internet-of-things-security/, n.d.. 1794 [IPSO] "IPSO Alliance", Web http://www.ipso-alliance.org, n.d.. 1796 [lora] "LoRa - Wide Area Networks for IoT", Web https://www.lora- 1797 alliance.org/, n.d.. 1799 [LWM2M] "OMA LWM2M", Web 1800 http://openmobilealliance.org/iot/lightweight-m2m-lwm2m, 1801 n.d.. 1803 [nbiot] "NarrowBand IoT", Web 1804 http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/RP- 1805 151621.zip, n.d.. 1807 [NHTSA] "Cybersecurity Best Practices for Modern Vehicles", Web 1808 https://www.nhtsa.gov/staticfiles/nvs/ 1809 pdf/812333_CybersecurityForModernVehicles.pdf, n.d.. 1811 [NIST-Guide] 1812 Ross, R., McEvilley, M., and J. Oren, "Systems Security 1813 Engineering", Web 1814 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 1815 NIST.SP.800-160.pdf, n.d.. 1817 [nist_lightweight_project] 1818 "NIST lightweight Project", Web www.nist.gov/programs- 1819 projects/lightweight-cryptography, 1820 www.nist.gov/sites/default/files/documents/2016/10/17/ 1821 sonmez-turan-presentation-lwc2016.pdf, n.d.. 1823 [OCF] "Open Connectivity Foundation", 1824 Web https://openconnectivity.org/, n.d.. 1826 [OneM2M] "OneM2M", Web http://www.onem2m.org/, n.d.. 1828 [OWASP] "IoT Security Guidance", 1829 Web https://www.owasp.org/index.php/IoT_Security_Guidance, 1830 n.d.. 1832 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1833 DOI 10.17487/RFC2818, May 2000, 1834 . 1836 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1837 Levkowetz, Ed., "Extensible Authentication Protocol 1838 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1839 . 1841 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1842 Neighbor Discovery (ND) Trust Models and Threats", 1843 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1844 . 1846 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1847 Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 1848 2004, . 1850 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1851 and Network Access (PANA) Threat Analysis and Security 1852 Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005, 1853 . 1855 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1856 Protect Firmware Packages", RFC 4108, 1857 DOI 10.17487/RFC4108, August 2005, 1858 . 1860 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1861 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1862 . 1864 [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 1865 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, 1866 DOI 10.17487/RFC4621, August 2006, 1867 . 1869 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1870 RSA-R: An Additional Mode of Key Distribution in 1871 Multimedia Internet KEYing (MIKEY)", RFC 4738, 1872 DOI 10.17487/RFC4738, November 2006, 1873 . 1875 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1876 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1877 Overview, Assumptions, Problem Statement, and Goals", 1878 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1879 . 1881 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1882 "Transmission of IPv6 Packets over IEEE 802.15.4 1883 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1884 . 1886 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1887 and A. Yegin, "Protocol for Carrying Authentication for 1888 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1889 May 2008, . 1891 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1892 (TLS) Protocol Version 1.2", RFC 5246, 1893 DOI 10.17487/RFC5246, August 2008, 1894 . 1896 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1897 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1898 . 1900 [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 1901 Threats and Security Requirements for the Access Node 1902 Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713, 1903 January 2010, . 1905 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 1906 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 1907 DOI 10.17487/RFC5903, June 2010, 1908 . 1910 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 1911 Grid", RFC 6272, DOI 10.17487/RFC6272, June 2011, 1912 . 1914 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1915 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1916 January 2012, . 1918 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1919 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1920 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1921 Low-Power and Lossy Networks", RFC 6550, 1922 DOI 10.17487/RFC6550, March 2012, 1923 . 1925 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1926 and D. Barthel, "Routing Metrics Used for Path Calculation 1927 in Low-Power and Lossy Networks", RFC 6551, 1928 DOI 10.17487/RFC6551, March 2012, 1929 . 1931 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 1932 Application Spaces for IPv6 over Low-Power Wireless 1933 Personal Area Networks (6LoWPANs)", RFC 6568, 1934 DOI 10.17487/RFC6568, April 2012, 1935 . 1937 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1938 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1939 . 1941 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1942 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1943 . 1945 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1946 Morris, J., Hansen, M., and R. Smith, "Privacy 1947 Considerations for Internet Protocols", RFC 6973, 1948 DOI 10.17487/RFC6973, July 2013, 1949 . 1951 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1952 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1953 October 2013, . 1955 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1956 Constrained-Node Networks", RFC 7228, 1957 DOI 10.17487/RFC7228, May 2014, 1958 . 1960 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1961 Application Protocol (CoAP)", RFC 7252, 1962 DOI 10.17487/RFC7252, June 2014, 1963 . 1965 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1966 Kivinen, "Internet Key Exchange Protocol Version 2 1967 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1968 2014, . 1970 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1971 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1972 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1973 . 1975 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1976 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1977 2015, . 1979 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1980 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1981 . 1983 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1984 DOI 10.17487/RFC7517, May 2015, 1985 . 1987 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1988 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1989 . 1991 [RFC7520] Miller, M., "Examples of Protecting Content Using JSON 1992 Object Signing and Encryption (JOSE)", RFC 7520, 1993 DOI 10.17487/RFC7520, May 2015, 1994 . 1996 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1997 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1998 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1999 . 2001 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 2002 Agility and Selecting Mandatory-to-Implement Algorithms", 2003 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 2004 . 2006 [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., 2007 and S. Kumar, "Use Cases for Authentication and 2008 Authorization in Constrained Environments", RFC 7744, 2009 DOI 10.17487/RFC7744, January 2016, 2010 . 2012 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 2013 (IKEv2) Initiator Implementation", RFC 7815, 2014 DOI 10.17487/RFC7815, March 2016, 2015 . 2017 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 2018 Security (TLS) / Datagram Transport Layer Security (DTLS) 2019 Profiles for the Internet of Things", RFC 7925, 2020 DOI 10.17487/RFC7925, July 2016, 2021 . 2023 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 2024 with the Host Identity Protocol", RFC 8046, 2025 DOI 10.17487/RFC8046, February 2017, 2026 . 2028 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 2029 M., and D. Barthel, "Transmission of IPv6 Packets over 2030 Digital Enhanced Cordless Telecommunications (DECT) Ultra 2031 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2032 2017, . 2034 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2035 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2036 . 2038 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 2039 of Things Software Update (IoTSU) Workshop 2016", 2040 RFC 8240, DOI 10.17487/RFC8240, September 2017, 2041 . 2043 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2044 Interchange Format", STD 90, RFC 8259, 2045 DOI 10.17487/RFC8259, December 2017, 2046 . 2048 [RG-T2TRG] 2049 "IRTF Thing-to-Thing (T2TRG) Research Group", 2050 Web https://datatracker.ietf.org/rg/t2trg/charter/, n.d.. 2052 [SchneierSecurity] 2053 "The Internet of Things Is Wildly Insecure--And Often 2054 Unpatchable", Web 2055 https://www.schneier.com/essays/archives/2014/01/ 2056 the_internet_of_thin.html, n.d.. 2058 [SEAL] "Simple Encrypted Arithmetic Library - SEAL", Web 2059 https://www.microsoft.com/en- 2060 us/research/publication/simple-encrypted-arithmetic- 2061 library-seal-v2-0/, n.d.. 2063 [shodan] "Shodan", Web https://www.shodan.io/, n.d.. 2065 [sigfox] "Sigfox - The Global Communications Service Provider for 2066 the Internet of Things (IoT)", 2067 Web https://www.sigfox.com/, n.d.. 2069 [Thread] "Thread Group", Web http://threadgroup.org/, n.d.. 2071 [TR69] "Too Many Cooks - Exploiting the Internet-of-TR- 2072 069-Things", Web https://media.ccc.de/v/31c3_-_6166_-_en_- 2073 _saal_6_-_201412282145_-_too_many_cooks_- 2074 _exploiting_the_internet-of-tr-069-things_- 2075 _lior_oppenheim_-_shahar_tal, n.d.. 2077 [WG-6lo] "IETF IPv6 over Networks of Resource-constrained Nodes 2078 (6lo) Working Group", 2079 Web https://datatracker.ietf.org/wg/6lo/charter/, n.d.. 2081 [WG-6LoWPAN] 2082 "IETF IPv6 over Low power WPAN (6lowpan) Working Group", 2083 Web http://tools.ietf.org/wg/6lowpan/, n.d.. 2085 [WG-ACE] "IETF Authentication and Authorization for Constrained 2086 Environments (ACE) Working Group", 2087 Web https://datatracker.ietf.org/wg/ace/charter/, n.d.. 2089 [WG-ACME] "Automated Certificate Management Environment Working 2090 Group", Web https://datatracker.ietf.org/wg/acme/about/, 2091 n.d.. 2093 [WG-CoRE] "IETF Constrained RESTful Environment (CoRE) Working 2094 Group", Web https://datatracker.ietf.org/wg/core/charter/, 2095 n.d.. 2097 [WG-LPWAN] 2098 "IETF Low Power Wide-Area Networks Working Group", 2099 Web https://datatracker.ietf.org/wg/lpwan/, n.d.. 2101 [WG-LWIG] "IETF Light-Weight Implementation Guidance (LWIG) Working 2102 Group", Web https://datatracker.ietf.org/wg/lwig/charter/, 2103 n.d.. 2105 [WG-MSEC] "IETF MSEC Working Group", 2106 Web https://datatracker.ietf.org/wg/msec/, n.d.. 2108 [WG-SUIT] "IETF Software Updates for Internet of Things (suit)", 2109 Web https://datatracker.ietf.org/group/suit/about/, n.d.. 2111 [wink] "Wink's Outage Shows Us How Frustrating Smart Homes Could 2112 Be", Web http://www.wired.com/2015/04/smart-home- 2113 headaches/, n.d.. 2115 [ZB] "ZigBee Alliance", Web http://www.zigbee.org/, February 2116 2011. 2118 [Ziegeldorf] 2119 Ziegeldorf, J., Garcia-Morchon, O., and K. Wehrle,, 2120 "Privacy in the Internet of Things: Threats and 2121 Challenges", Security and Communication Networks - Special 2122 Issue on Security in a Completely Interconnected World , 2123 2013. 2125 Authors' Addresses 2126 Oscar Garcia-Morchon 2127 Philips IP&S 2128 High Tech Campus 5 2129 Eindhoven, 5656 AA 2130 The Netherlands 2132 Email: oscar.garcia-morchon@philips.com 2134 Sandeep S. Kumar 2135 Philips Research 2136 High Tech Campus 2137 Eindhoven, 5656 AA 2138 The Netherlands 2140 Email: sandeep.kumar@philips.com 2142 Mohit Sethi 2143 Ericsson 2144 Hirsalantie 11 2145 Jorvas, 02420 2146 Finland 2148 Email: mohit@piuha.net