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