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