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