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