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