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