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