idnits 2.17.1 draft-irtf-t2trg-iot-seccons-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 09, 2016) is 2756 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SPEKE' is mentioned on line 941, but not defined == Unused Reference: 'ID-Hartke' is defined on line 1581, but no explicit reference was found in the text == Unused Reference: 'ID-OFlynn' is defined on line 1594, but no explicit reference was found in the text == Unused Reference: 'JOURNAL-Perrig' is defined on line 1625, but no explicit reference was found in the text == Unused Reference: 'NIST' is defined on line 1630, but no explicit reference was found in the text == Unused Reference: 'PROC-Chan' is defined on line 1633, but no explicit reference was found in the text == Unused Reference: 'PROC-Gupta' is defined on line 1638, but no explicit reference was found in the text == Unused Reference: 'RFC4251' is defined on line 1694, but no explicit reference was found in the text == Unused Reference: 'RFC6345' is defined on line 1754, but no explicit reference was found in the text == Unused Reference: 'RFC7696' is defined on line 1786, but no explicit reference was found in the text == Unused Reference: 'THESIS-Langheinrich' is defined on line 1797, but no explicit reference was found in the text == Unused Reference: 'TinyDTLS' is defined on line 1803, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-sarikaya-t2trg-sbootstrapping-01 == Outdated reference: A later version (-06) exists of draft-selander-ace-object-security-05 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 4 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 S. Kumar 4 Intended status: Informational Philips Research 5 Expires: April 12, 2017 M. Sethi 6 Ericsson 8 October 09, 2016 10 Security Considerations in the IP-based Internet of Things 11 draft-irtf-t2trg-iot-seccons-00 13 Abstract 15 A direct interpretation of the Internet of Things concept refers to 16 the usage of standard Internet protocols to allow for human-to-thing 17 or thing-to-thing communication. Although the security needs are 18 well-recognized, it is still not fully clear how existing IP-based 19 security protocols can be applied to this new setting. This 20 Internet-Draft first provides an overview of security architecture, 21 its deployment model and general security needs in the context of the 22 lifecycle of a thing. Then, it presents challenges and requirements 23 for the successful roll-out of new applications and usage of standard 24 IP-based security protocols when applied to get a functional Internet 25 of Things. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 12, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Conventions and Terminology Used in this Document . . . . . . 3 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. The Thing Lifecycle and Architectural Considerations . . . . 4 64 3.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Security Aspects . . . . . . . . . . . . . . . . . . . . 9 66 4. State of the Art . . . . . . . . . . . . . . . . . . . . . . 12 67 4.1. IP-based Security Solutions . . . . . . . . . . . . . . . 12 68 5. Security Levels for the IP-based Internet of Things . . . . . 14 69 5.1. Security Architecture . . . . . . . . . . . . . . . . . . 18 70 5.2. Security Model . . . . . . . . . . . . . . . . . . . . . 19 71 5.3. Security Bootstrapping and Management . . . . . . . . . . 20 72 5.4. Network Security . . . . . . . . . . . . . . . . . . . . 22 73 5.5. Application Security . . . . . . . . . . . . . . . . . . 23 74 6. Challenges and Security Considerations for a Secure Internet 75 of Things . . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 6.1. Constraints and Heterogeneous Communication . . . . . . . 25 77 6.1.1. Tight Resource Constraints . . . . . . . . . . . . . 25 78 6.1.2. Denial-of-Service Resistance . . . . . . . . . . . . 26 79 6.1.3. Protocol Translation and End-to-End Security . . . . 27 80 6.2. Bootstrapping of a Security Domain . . . . . . . . . . . 28 81 6.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 28 82 6.3.1. End-to-End Security . . . . . . . . . . . . . . . . . 29 83 6.3.2. Group Membership and Security . . . . . . . . . . . . 29 84 6.3.3. Mobility and IP Network Dynamics . . . . . . . . . . 30 85 6.4. Software update . . . . . . . . . . . . . . . . . . . . . 30 86 6.5. Verifying device behavior . . . . . . . . . . . . . . . . 31 87 6.6. End-of-life . . . . . . . . . . . . . . . . . . . . . . . 32 88 6.7. Penetration testing . . . . . . . . . . . . . . . . . . . 32 89 6.8. Quantum-resistance . . . . . . . . . . . . . . . . . . . 32 90 7. Next Steps towards a Flexible and Secure Internet of Things . 33 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 94 11. Informative References . . . . . . . . . . . . . . . . . . . 34 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 97 1. Conventions and Terminology Used in this Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in "Key words for use in 102 RFCs to Indicate Requirement Levels" [RFC2119]. 104 2. Introduction 106 The Internet of Things (IoT) denotes the interconnection of highly 107 heterogeneous networked entities and networks following a number of 108 communication patterns such as: human-to-human (H2H), human-to-thing 109 (H2T), thing-to-thing (T2T), or thing-to-things (T2Ts). The term IoT 110 was first coined by the Auto-ID center [AUTO-ID] in 1999. Since 111 then, the development of the underlying concepts has ever increased 112 its pace. Nowadays, the IoT presents a strong focus of research with 113 various initiatives working on the (re)design, application, and usage 114 of standard Internet technology in the IoT. 116 The introduction of IPv6 and web services as fundamental building 117 blocks for IoT applications [RFC6568] promises to bring a number of 118 basic advantages including: (i) a homogeneous protocol ecosystem that 119 allows simple integration with Internet hosts; (ii) simplified 120 development of very different appliances; (iii) an unified interface 121 for applications, removing the need for application-level proxies. 122 Such features greatly simplify the deployment of the envisioned 123 scenarios ranging from building automation to production environments 124 to personal area networks, in which very different things such as a 125 temperature sensor, a luminaire, or an RFID tag might interact with 126 each other, with a human carrying a smart phone, or with backend 127 services. 129 This Internet Draft presents an overview of the security aspects of 130 the envisioned all-IP architecture as well as of the lifecycle of an 131 IoT device, a thing, within this architecture. In particular, we 132 review the most pressing aspects and functionalities that are 133 required for a secure all-IP solution. 135 With this, this Internet-Draft pursues several goals. First, we aim 136 at presenting a comprehensive view of the interactions and 137 relationships between an IoT application and security. Second, we 138 aim at describing challenges for a secure IoT in the specific context 139 of the lifecycle of a resource-constrained device. The final goal of 140 this draft is to discuss the security considerations that need to be 141 taken into consideration towards a secure IoT. 143 The rest of the Internet-Draft is organized as follows. Section 3 144 depicts the lifecycle of a thing and gives general definitions for 145 the main security aspects within the IoT domain. In Section 4, we 146 review existing protocols and work done in the area of security for 147 wireless sensor networks. Section 5 identifies general challenges 148 and needs for an IoT security protocol design and discusses existing 149 protocols and protocol proposals against the identified requirements. 150 Section 6 proposes a number of illustrative security suites 151 describing how different applications involve distinct security 152 needs. Section 7 includes final remarks and conclusions. 154 3. The Thing Lifecycle and Architectural Considerations 156 We consider the installation of a Building Automation and Control 157 (BAC) system to illustrate the lifecycle of a thing but can be 158 similarly extended to other scenarios. A BAC system consists of a 159 network of interconnected nodes that perform various functions in the 160 domains of HVAC (Heating, Ventilating, and Air Conditioning), 161 lighting, safety etc. The nodes vary in functionality and a majority 162 of them represent resource constrained devices such as sensors and 163 luminaries. Some devices may also be battery operated or battery- 164 less nodes, demanding for a focus on low energy consumption and on 165 sleeping devices. 167 In our example, the life of a thing starts when it is manufactured. 168 Due to the different application areas (i.e., HVAC, lighting, safety) 169 nodes are tailored to a specific task. It is therefore unlikely that 170 one single manufacturer will create all nodes in a building. Hence, 171 interoperability as well as trust bootstrapping between nodes of 172 different vendors is important. The thing is later installed and 173 commissioned within a network by an installer during the 174 bootstrapping phase. Specifically, the device identity and the 175 secret keys used during normal operation are provided to the device 176 during this phase. Different subcontractors may install different 177 IoT devices for different purposes. Furthermore, the installation 178 and bootstrapping procedures may not be a defined event but may 179 stretch over an extended period of time. After being bootstrapped, 180 the device and the system of things are in operational mode and run 181 the functions of the BAC system. During this operational phase, the 182 device is under the control of the system owner. For devices with 183 lifetimes spanning several years, occasional maintenance cycles may 184 be required. During each maintenance phase, the software on the 185 device can be upgraded or applications running on the device can be 186 reconfigured. The maintenance tasks can thereby be performed either 187 locally or from a backend system. Depending on the operational 188 changes of the device, it may be required to re-bootstrap at the end 189 of a maintenance cycle. The device continues to loop through the 190 operational phase and the eventual maintenance phase until the device 191 is decommissioned at the end of its lifecycle. However, the end-of- 192 life of a device does not necessarily mean that it is defective but 193 rather denotes a need to replace and upgrade the network to next- 194 generation devices in order to provide additional functionality. 195 Therefore the device can be removed and re-commissioned to be used in 196 a different network under a different owner by starting the lifecycle 197 over again. Figure 1 shows the generic lifecycle of a thing. This 198 generic lifecycle is also applicable for various IoT scenarios other 199 than BAC systems. 201 More recently building control networks employ IP-based standards 202 allowing seamless control over the various nodes with a single 203 management system. While allowing for easier integration, this shift 204 towards IP-based standards results in new requirements regarding the 205 implementation of IP security protocols on constrained devices and 206 the bootstrapping of security keys for devices across multiple 207 manufacturers. 209 _Manufactured _SW update _Decommissioned 210 / / / 211 | _Installed | _ Application | _Removed & 212 | / | / reconfigured | / replaced 213 | | _Commissioned | | | | 214 | | / | | | | _Reownership & 215 | | | _Application | | _Application | | / recommissioned 216 | | | / running | | / running | | | 217 | | | | | | | | | | \\ 218 +##+##+###+#############+##+##+#############+##+##+##############>>> 219 \/ \______________/ \/ \_____________/ \___/ time // 220 / / \ \ \ 221 Bootstrapping / Maintenance & \ Maintenance & 222 / re-bootstrapping \ re-bootstrapping 223 Operational Operational 225 Figure 1: The lifecycle of a thing in the Internet of Things. 227 3.1. Threat Analysis 229 This section explores the security threats and vulnerabilities of a 230 network of things in the IoTs. Security threats have been analyzed 231 in related IP protocols including HTTPS [RFC2818], COAP[RFC7252] 232 6LoWPAN [RFC4919], ANCP [RFC5713], DNS security threats [RFC3833], 233 SIP [RFC3261], IPv6 ND [RFC3756], and PANA [RFC4016]. Nonetheless, 234 the challenge is about their impacts on scenarios of the IoTs. In 235 this section, we specifically discuss the threats that could 236 compromise an individual thing, or network as a whole, with regard to 237 different phases in the thing's lifecycle. Note that these set of 238 threats might go beyond the scope of Internet protocols but we gather 239 them here for the sake of completeness. 241 1. Cloning of things: During the manufacturing process of a thing, 242 an untrusted manufacturer can easily clone the physical 243 characteristics, firmware/software, or security configuration of 244 the thing. Subsequently, such a cloned thing may be sold at a 245 cheaper price in the market, and yet be still able to function 246 normally, as a genuine thing. For example, two cloned devices 247 can still be associated and work with each other. In the worst 248 case scenario, a cloned device can be used to control a genuine 249 device. One should note here, that an untrusted manufacturer may 250 also change functionality of the cloned thing, resulting in 251 degraded functionality with respect to the genuine thing 252 (thereby, inflicting potential reputational risk to the original 253 thing manufacturer). Moreover, it can implement additional 254 functionality with the cloned thing, such as a backdoor. 256 2. Malicious substitution of things: During the installation of a 257 thing, a genuine thing may be substituted with a similar variant 258 of lower quality without being detected. The main motivation may 259 be cost savings, where the installation of lower-quality things 260 (e.g., non-certified products) may significantly reduce the 261 installation and operational costs. The installers can 262 subsequently resell the genuine things in order to gain further 263 financial benefits. Another motivation may be to inflict 264 reputational damage on a competitor's offerings. 266 3. Eavesdropping attack: During the commissioning of a thing into a 267 network, it may be susceptible to eavesdropping, especially if 268 operational keying materials, security parameters, or 269 configuration settings, are exchanged in clear using a wireless 270 medium. After obtaining the keying material, the attacker might 271 be able to recover the secret keys established between the 272 communicating entities (e.g., H2T, T2Ts, or Thing to the backend 273 management system), thereby compromising the authenticity and 274 confidentiality of the communication channel, as well as the 275 authenticity of commands and other traffic exchanged over this 276 communication channel. When the network is in operation, T2T 277 communication may be eavesdropped upon if the communication 278 channel is not sufficiently protected or in the event of session 279 key compromise due to a long period of usage without key renewal 280 or updates. 282 4. Man-in-the-middle attack: Both the commissioning phase and 283 operational phases may also be vulnerable to man-in-the-middle 284 attacks, e.g., when keying material between communicating 285 entities is exchanged in the clear and the security of the key 286 establishment protocol depends on the tacit assumption that no 287 third party is able to eavesdrop on or sit in between the two 288 communicating entities during the execution of this protocol. 289 Additionally, device authentication or device authorization may 290 be nontrivial, or may need support of a human decision process, 291 since things usually do not have a priori knowledge about each 292 other and can, therefore, not always be able to differentiate 293 friends and foes via completely automated mechanisms. Thus, even 294 if the key establishment protocol provides cryptographic device 295 authentication, this knowledge on device identities may still 296 need complementing with a human-assisted authorization step 297 (thereby, presenting a weak link and offering the potential of 298 man-in-the-middle attacks this way). 300 5. Firmware Replacement attack: When a thing is in operation or 301 maintenance phase, its firmware or software may be updated to 302 allow for new functionality or new features. An attacker may be 303 able to exploit such a firmware upgrade by replacing the thing's 304 with malicious software, thereby influencing the operational 305 behavior of the thing. For example, an attacker could add a 306 piece of malicious code to the firmware that will cause it to 307 periodically report the energy usage of the lamp to a data 308 repository for analysis. 310 6. Extraction of security parameters: A thing deployed in the 311 ambient environment (such as sensors, actuators, etc.) is usually 312 physically unprotected and could easily be captured by an 313 attacker. Such an attacker may then attempt to extract security 314 information such as keys (e.g., device's key, private-key, group 315 key) from this thing or try and re-program it to serve his needs. 316 If a group key is used and compromised this way, the whole 317 network may be compromised as well. Compromise of a thing's 318 unique key has less security impact, since only the communication 319 channels of this particular thing in question are compromised. 320 Here, one should caution that compromise of the communication 321 channel may also compromise all data communicated over this 322 channel. In particular, one has to be weary of, e.g., compromise 323 of group keys communicated over this channel (thus, leading to 324 transitive exposure ripple effects). 326 7. Routing attack: As highlighted in [ID-Daniel], routing 327 information in IoT can be spoofed, altered, or replayed, in order 328 to create routing loops, attract/repel network traffic, extend/ 329 shorten source routes, etc. Other relevant routing attacks 330 include 1) Sinkhole attack (or blackhole attack), where an 331 attacker declares himself to have a high-quality route/path to 332 the base station, thus allowing him to do anything to all packets 333 passing through it. 2) Selective forwarding, where an attacker 334 may selectively forward packets or simply drop a packet. 3) 335 Wormhole attack, where an attacker may record packets at one 336 location in the network and tunnel them to another location, 337 thereby influencing perceived network behavior and potentially 338 distorting statistics, thus greatly impacting the functionality 339 of routing. 4) Sybil attack, whereby an attacker presents 340 multiple identities to other things in the network. 342 8. Privacy threat: The tracking of a thing's location and usage may 343 pose a privacy risk to its users. An attacker can infer 344 information based on the information gathered about individual 345 things, thus deducing behavioral patterns of the user of interest 346 to him. Such information can subsequently be sold to interested 347 parties for marketing purposes and targeted advertising. 349 9. Denial-of-Service attack: Typically, things have tight memory and 350 limited computation, they are thus vulnerable to resource 351 exhaustion attack. Attackers can continuously send requests to 352 be processed by specific things so as to deplete their resources. 353 This is especially dangerous in the IoTs since an attacker might 354 be located in the backend and target resource-constrained devices 355 in an LLN. Additionally, DoS attack can be launched by 356 physically jamming the communication channel, thus breaking down 357 the T2T communication channel. Network availability can also be 358 disrupted by flooding the network with a large number of packets. 360 The following table summarizes the security threats we identified 361 above and the potential point of vulnerabilities at different layers 362 of the communication stack. We also include related RFCs that 363 include a threat model that might apply to the IoTs. 365 +------------------+------------------+------------------+ 366 | Manufacturing | Installation/ | Operation | 367 | | Commissioning | | 368 +------------+------------------+------------------+------------------+ 369 |Thing's | Device Cloning |Substitution |Privacy threat | 370 |Model | |ACE-OAuth(draft) |Extraction of | 371 | | | |security params | 372 +------------+------------------+------------------+------------------+ 373 |Application | |RFC2818, RFC7252 |RFC2818, Firmware | 374 |Layer | |OSCOAP(draft) |replacement | 375 +------------+------------------+------------------+------------------+ 376 |Transport | | Eavesdropping & |Eavesdropping | 377 |Layer | | Man-in-the-middle|Man-in-the-middle | 378 +------------+------------------| attack, RFC7925 |------------------+ 379 |Network | | RFC4919, RFC5713 |RFC4919,DoS attack| 380 |Layer | | RFC3833, RFC3756 |Routing attack | 381 | | | |RFC3833 | 382 +------------+------------------+------------------+------------------+ 383 |Physical | | |DoS attack | 384 |Layer | | | | 385 +-------------------------------+------------------+------------------+ 387 Figure 2: The security threat analysis 389 3.2. Security Aspects 391 The term security subsumes a wide range of different concepts. In 392 the first place, it refers to the basic provision of security 393 services including confidentiality, authentication, integrity, 394 authorization, non-repudiation, and availability, and some augmented 395 services, such as duplicate detection and detection of stale packets 396 (timeliness). These security services can be implemented by a 397 combination of cryptographic mechanisms, such as block ciphers, hash 398 functions, or signature algorithms, and non-cryptographic mechanisms, 399 which implement authorization and other security policy enforcement 400 aspects. For each of the cryptographic mechanisms, a solid key 401 management infrastructure is fundamental to handling the required 402 cryptographic keys, whereas for security policy enforcement, one 403 needs to properly codify authorizations as a function of device roles 404 and a security policy engine that implements these authorization 405 checks and that can implement changes hereto throughout the system's 406 lifecycle. 408 In the context of the IoT, however, the security must not only focus 409 on the required security services, but also how these are realized in 410 the overall system and how the security functionalities are executed. 411 To this end, we use the following terminology to analyze and classify 412 security aspects in the IoT: 414 1. The security architecture refers to the system elements involved 415 in the management of the security relationships between things 416 and the way these security interactions are handled (e.g., 417 centralized or distributed) during the lifecycle of a thing. 419 2. The security model of a node describes how the security 420 parameters, processes, and applications are managed in a thing. 421 This includes aspects such as process separation, secure storage 422 of keying materials, etc. 424 3. Security bootstrapping denotes the process by which a thing 425 securely joins the IoT at a given location and point in time. 426 Bootstrapping includes the authentication and authorization of a 427 device as well as the transfer of security parameters allowing 428 for its trusted operation in a given network. 430 4. Network security describes the mechanisms applied within a 431 network to ensure trusted operation of the IoT. Specifically, it 432 prevents attackers from endangering or modifying the expected 433 operation of networked things. Network security can include a 434 number of mechanisms ranging from secure routing to data link 435 layer and network layer security. 437 5. Object security describes mechanisms to allow transfer of secured 438 blocks of data with end-to-end assurances independent of 439 communication pattern, for e.g through proxies or other store- 440 and-forward mechanisms. 442 6. Application security guarantees that only trusted instances of an 443 application running in the IoT can communicate with each other, 444 while illegitimate instances cannot interfere. 446 .......................... 447 : +-----------+: 448 : *+*>|Application|***** 449 : *| +-----------+: * 450 : *| +-----------+: * 451 : *|->| Transport |: * 452 : * _*| +-----------+: * 453 : *| | +-----------+: * 454 : *| |->| Network |: * 455 : *| | +-----------+: * 456 : *| | +-----------+: * *** Bootstrapping 457 : *| +->| L2 |: * ~~~ Transport Security 458 : *| +-----------+: * ''' Object Security 459 :+--------+ : * 460 :|Security| Configuration: * 461 :|Service | Entity : * 462 :+--------+ : * 463 :........................: * 464 * 465 ......................... * ......................... 466 :+--------+ : * : +--------+: 467 :|Security| Node B : * : Node A |Security|: 468 :|Service | : * : |Service |: 469 :+--------+ : * : +--------+: 470 : | +-----------+: * :+-----------+ |* : 471 : | +->|Application|: ****|Application|<*+* |* : 472 : | | +-----------+:''''''''''''''''''''+-----------+ |* |* : 473 : | | +-----------+: :+-----------+ |* |* : 474 : | |->| Transport |~~~~~~~~~~~~~~~~~~~~~| Transport |<-|* |* : 475 : |__| +-----------+: ................. :+-----------+ |*_|* : 476 : | +-----------+: : +-----------+ : :+-----------+ | * : 477 : |->| Network |: : | Network | : :| Network |<-| : 478 : | +-----------+: : +-----------+ : :+-----------+ | : 479 : | +-----------+: : +-----------+ : :+-----------+ | : 480 : +->| L2 |: : | L2 | : :| L2 |<-+ : 481 : +-----------+: : +-----------+ : :+-----------+ : 482 :.......................: :...............: :.......................: 483 Overview of Security Mechanisms. 485 Figure 3 487 We now discuss an exemplary security architecture relying on a 488 configuration entity for the management of the system with regard to 489 the introduced security aspects (see Figure 2). Inspired by the 490 security framework for routing over low power and lossy network 491 [ID-Tsao], we show an example of security model and illustrates how 492 different security concepts and the lifecycle phases map to the 493 Internet communication stack. Assume a centralized architecture in 494 which a configuration entity stores and manages the identities of the 495 things associated with the system along with their cryptographic 496 keys. During the bootstrapping phase, each thing executes the 497 bootstrapping protocol with the configuration entity, thus obtaining 498 the required device identities and the keying material. The security 499 service on a thing in turn stores the received keying material for 500 the network layer and application security mechanisms for secure 501 communication. Things can then securely communicate with each other 502 during their operational phase by means of the employed network and 503 application security mechanisms. 505 4. State of the Art 507 Nowadays, there exists a multitude of control protocols for the IoT. 508 For BAC systems, the ZigBee standard [ZB], BACNet [BACNET], or DALI 509 [DALI] play key roles. Recent trends, however, focus on an all-IP 510 approach for system control. 512 In this setting, a number of IETF working groups are designing new 513 protocols for resource constrained networks of smart things. The 514 6LoWPAN working group [WG-6LoWPAN] concentrates on the definition of 515 methods and protocols for the efficient transmission and adaptation 516 of IPv6 packets over IEEE 802.15.4 networks [RFC4944]. The CoRE 517 working group [WG-CoRE] provides a framework for resource-oriented 518 applications intended to run on constrained IP network (6LoWPAN). 519 One of its main tasks is the definition of a lightweight version of 520 the HTTP protocol, the Constrained Application Protocol (CoAP) 521 [RFC7252], that runs over UDP and enables efficient application-level 522 communication for things. Also IRTF groups are actively contributing 523 to improve IoT security. 525 Additionally industry alliances like Thread [Thread] are creating 526 constrained IP protocol stacks based on the IETF work. 528 4.1. IP-based Security Solutions 530 In the context of the IP-based IoT solutions, consideration of TCP/IP 531 security protocols is important as these protocols are designed to 532 fit the IP network ideology and technology. There are a wide range 533 of specialized as well as general-purpose key exchange and security 534 solutions exist for the Internet domain such as IKEv2/IPsec 535 [RFC7296], TLS/SSL [RFC5246], DTLS [RFC5238], HIP [RFC7401], PANA 536 [RFC5191], and EAP [RFC3748]. Some of these solutions are also been 537 investigated now, such as, e.g., OSCOAP. Figure 3 depicts the 538 relationships between the discussed protocols in the context of the 539 security terminology introduced in Section 3.1. 541 .......................... 542 : +-----------+: 543 : *+*>|Application|***** *** Bootstrapping 544 : *| +-----------+: * ### Transport Security 545 : *| +-----------+: * === Network security 546 : *|->| Transport |: * ... Object security 547 : * _*| +-----------+: * 548 : *| | +-----------+: * 549 : *| |->| Network |: *--> -PANA/EAP 550 : *| | +-----------+: * -HIP 551 : *| | +-----------+: * 552 : *| +->| L2 |: * ## DTLS 553 : *| +-----------+: * .. OSCOAP 554 :+--------+ : * 555 :|Security| Configuration: * [] HIP,IKEv2 556 :|Service | Entity : * [] ESP/AH 557 :+--------+ : * 558 :........................: * 559 * 560 ......................... * ......................... 561 :+--------+ : * : +--------+: 562 :|Security| Node B : Secure * : Node A |Security|: 563 :|Service | : routing * : |Service |: 564 :+--------+ : framework * : +--------+: 565 : | +-----------+: | **** :+-----------+ |* : 566 : | +->|Application|:........|............:|Application|<*+* |* : 567 : | | +----##-----+: | :+----##-----+ |* |* : 568 : | | +----##-----+: | :+----##-----+ |* |* : 569 : | |->| Transport |#########|#############| Transport |<-|* |* : 570 : |__| +----[]-----+: ......|.......... :+----[]-----+ |*_|* : 571 : | +====[]=====+=====+===========+=====+====[]=====+ | * : 572 : |->|| Network |: : | Network | : :| Network ||<-| : 573 : | +|----------+: : +-----------+ : :+----------|+ | : 574 : | +|----------+: : +-----------+ : :+----------|+ | : 575 : +->|| L2 |: : | L2 | : :| L2 ||<-+ : 576 : +===========+=====+===========+=====+===========+ : 577 :.......................: :...............: :.......................: 578 Relationships between IP-based security protocols. 580 Figure 4 582 The Internet Key Exchange (IKEv2)/IPsec and the Host Identity 583 protocol (HIP) reside at or above the network layer in the OSI model. 584 Both protocols are able to perform an authenticated key exchange and 585 set up the IPsec transforms for secure payload delivery. Currently, 586 there are also ongoing efforts to create a HIP variant coined Diet 587 HIP [ID-HIP] that takes lossy low-power networks into account at the 588 authentication and key exchange level. 590 Transport Layer Security (TLS) and its datagram-oriented variant DTLS 591 secure transport-layer connections. TLS provides security for TCP 592 and requires a reliable transport, while DTLS secures and uses 593 datagram-oriented protocols such as UDP. Both protocols are 594 intentionally kept similar and share the same ideology and cipher 595 suites. 597 The Extensible Authentication Protocol (EAP) is an authentication 598 framework supporting multiple authentication methods. EAP runs 599 directly over the data link layer and, thus, does not require the 600 deployment of IP. It supports duplicate detection and 601 retransmission, but does not allow for packet fragmentation. The 602 Protocol for Carrying Authentication for Network Access (PANA) is a 603 network-layer transport for EAP that enables network access 604 authentication between clients and the network infrastructure. In 605 EAP terms, PANA is a UDP-based EAP lower layer that runs between the 606 EAP peer and the EAP authenticator. 608 In addition, there is also new activities in IETF and W3C to define 609 security protocols better tailored to IoT or for specific deployment 610 situations. The ACE WG is designing an authorization mechanism based 611 on OAuth for constrained devices. There is work on Object Security 612 based CoAP protection mechanism being defined in OSCOAP. <> 615 5. Security Levels for the IP-based Internet of Things 617 Different applications have different security requirements and needs 618 and, depending on various factors, such as device capability, 619 availability of network infrastructure, security services needed, 620 usage, etc., the required security protection may vary from "simple 621 security" to "full-blown security". For example, applications may 622 have different needs regarding authentication and confidentiality. 623 While some application might not require any authentication at all, 624 others might require strong end-to-end authentication. In terms of 625 secure bootstrapping of keys, some applications might assume the 626 existence and online availability of a central key-distribution- 627 center (KDC) within the 6LoWPAN network to distribute and manage 628 keys; while other applications cannot rely on such a central party or 629 their availability. 631 Thus, it is essential to define security profiles to better tailor 632 security solutions for different applications with the same 633 characteristics and requirements. This provides a means of grouping 634 applications into profiles and then defines the minimal required 635 security primitives to enable and support the security needs of the 636 profile. The security elements in a security profile can be 637 classified according to Section 3.1, namely: 639 1 Security architecture, 641 2 Security model, 643 3 Security bootstrapping, 645 4 Network security, and 647 5 Application security. 649 In order to (i) guide the design process by identifying open gaps; 650 (ii) allow for later interoperability; and (iii) prevent possible 651 security misconfigurations, this section defines a number of generic 652 security profiles with different security needs. Each security 653 profile is identified by: 655 1. a short description, 657 2. an exemplary application that might use/require such a security 658 policy, 660 3. the security requirements for each of the above security aspects 661 according to our classification in Section 3.1. 663 These security profiles can serve to guide the standardization 664 process, since these explicitly describe the basic functionalities 665 and protocols required to get different use cases up and running. It 666 can allow for later interoperability since different manufacturers 667 can describe the implemented security profile in their products. 668 Finally, the security profiles can avoid possible security 669 misconfigurations, since each security profile can be bound to a 670 different application area so that it can be clearly defined which 671 security protocols and approaches can be applied where and under 672 which circumstances. 674 Note that each of these security profiles aim at summarizing the 675 required security requirements for different applications and at 676 providing a set of initial security features. In other words, these 677 profiles reflect the need for different security configurations, 678 depending on the threat and trust models of the underlying 679 applications. In this sense, this section does not provide an 680 overview of existing protocols as done in previous sections of the 681 Internet Draft, but it rather explicitly describes what should be in 682 place to ensure secure system operation. Observe also that this list 683 of security profiles is not exhaustive and that it should be 684 considered just as an example not related to existing legal 685 regulations for any existing application. These security profiles 686 are summarized in the table below: 688 +---------------------------------------------------------+ 689 | Exemnplary | | 690 | Application | Description | 691 +----------+---------------------------------------------------------+ 692 |SecProf_1 |Home usage |Enables operation between home things | 693 | | |without interaction with central device| 694 +----------+-----------------+---------------------------------------+ 695 |SecProf_2 |Managed Home |Enables operation between home things. | 696 | | usage |Interaction with a central and local | 697 | | |device is possible | 698 +----------+-----------------+---------------------------------------+ 699 |SecProf_3 |Industrial usage |Enables operation between things. | 700 | | |Relies on central (local or backend) | 701 | | |device for security | 702 +----------+-----------------+---------------------------------------+ 703 |SecProf_4 |Advanced |Enables ad-hoc operation between things| 704 | |Industrial usage |and relies on central device or | 705 | | |on a collection of control devices | 706 +----------+-----------------+---------------------------------------+ 708 Figure 5: Security profiles and application areas. 710 The classification in the table considers different potential 711 applications and situations in which their security needs change due 712 to different operational features (network size, existence of a 713 central device, connectivity to the Internet, importance of the 714 exchanged information, etc) or threat model (what are the assets that 715 an attacker looks for). As already pointed out, this set of 716 scenarios is exemplary and they should be further discussed based on 717 a broader consensus. 719 The security suite (SecProf_1) is catered for environments in which 720 IP protocols (e.g., 6LoWPAN/CoAP) can be used to enable communication 721 between things in an ad-hoc manner and the security requirements are 722 minimal. An example, is a home application in which two devices 723 should exchange information and no further connection with other 724 devices (local or with a backend) is required. In this scenario, 725 value of the exchanged information is low and that it usually happen 726 in a confined room, thus, it is possible to have a short period of 727 time during which initial secrets can be exchanged in the clear. Due 728 to this fact, there is no requirement to enable devices from 729 different manufacturers to interoperate in a secure way (keys are 730 just exchanged). The expected network size of applications using 731 this profile is expected to be small such that the provision of 732 network security, e.g., secure routing, is of low importance. 734 The next security suite (SecProf_2) represents an evolution of 735 SecProf_1 in which, e.g., home devices, can be managed locally. A 736 first possibility for the securing domain management refers to the 737 creation of a centrally managed security domain without any 738 connectivity to the Internet. The central device used for management 739 can serve as, e.g., a key distribution center including policies for 740 key update, storage, etc. The presence of a central device can help 741 in the management of larger networks. Network security becomes more 742 relevant in this scenario since the IP network (e.g., 6LoWPAN/CoAP 743 network) can be prone to Denial of Service attacks (e.g., flooding if 744 L2 is not protected) or routing attacks. 746 SecProf_3 considers that a central device is always required for 747 network management. Example applications of this profile include 748 building control and automation, sensor networks for industrial use, 749 environmental monitoring, etc. As before, the network manager can be 750 located in the IP network (e.g., 6LoWPAN/CoAP network) and handle key 751 management. In this case, the first association of devices to the 752 network is required to be done in a secure way. In other words, the 753 threat model requires measurements to protect against any vulnerable 754 period of time. This step can involve the secure transmission of 755 keying materials used for network security at different layers. The 756 information exchanged in the network is considered to be valuable and 757 it should be protected in the sense of pairwise links. Commands 758 should be secured and broadcast should be secured with entity 759 authentication [RFC7390]. Network should be protected from attacks. 760 A further extension to this use case is to allow for remote 761 management. A "backend manager" is in charge of managing SW or 762 information exchanged or collected within the IP network, e.g., a 763 6LoWPAN/CoAP network. This requires connection of devices to the 764 Internet over a 6LBR involving a number of new threats that were not 765 present before. A list of potential attacks include: resource- 766 exhaustion attacks from the Internet; amplification attacks; trust 767 issues related a HTTP-CoAP proxy [ID-proHTTPCoAP], etc. This use 768 case requires protecting the communication from a device in the 769 backend to a device in the IP network, e.g., a 6LoWPAN/CoAP network, 770 end-to-end. This use case also requires measures to provide the 6LBR 771 with the capability of dropping fake requests coming from the 772 Internet. This becomes especially challenging when the 6LBR is not 773 trusted and access to the exchanged information is limited; and even 774 more in the case of a HTTP-CoAP proxy since protocol translation is 775 required. This use case should take care of protecting information 776 accessed from the backend due to privacy issues (e.g., information 777 such as type of devices, location, usage, type and amount of 778 exchanged information, or mobility patterns can be gathered at the 779 backend threatening the privacy sphere of users) so that only 780 required information is disclosed. 782 The last security suite (SecProf_4) essentially represents 783 interoperability of all the security profiles defined previously. It 784 considers applications with some additional requirements regarding 785 operation such as: (i) ad-hoc establishment of security relationships 786 between things (potentially from different manufacturers) in non- 787 secure environments or (ii) dynamic roaming of things between 788 different IP network security domains. Such operational requirements 789 pose additional security requirements, e.g., in addition to secure 790 bootstrapping of a device within an IP, e.g., 6LowPan/CoAP, security 791 domain and the secure transfer of network operational key, there is a 792 need to enable inter-domains secure communication to facilitate data 793 sharing. 795 The above description illustrates how different applications of IP 796 networks, e.g., 6LoWPAN/CoAP networks, involve different security 797 needs. In the following sections, we summarize the expected security 798 features or capabilities for each the security profile with regards 799 to "Security Architecture", "Security Model", "Security 800 Bootstrapping", "Network Security", and "Application Security". 802 5.1. Security Architecture 804 Most things might be required to support both centralized and 805 distributed operation patterns. Distributed thing-to-thing 806 communication might happen on demand, for instance, when two things 807 form an ad-hoc security domain to cooperatively fulfill a certain 808 task. Likewise, nodes may communicate with a backend service located 809 in the Internet without a central security manager. The same nodes 810 may also be part of a centralized architecture with a dedicated node 811 being responsible for the security management for group communication 812 between things in the IoT domain. In today's IoT, most common 813 architectures are fully centralized in the sense that all the 814 security relationships within a segment are handled by a central 815 party. In the ZigBee standard, this entity is the trust center. 816 Current proposals for 6LoWPAN/CoRE identify the 6LoWPAN Border Router 817 (6LBR) as such a device. 819 A centralized architecture allows for central management of devices 820 and keying materials as well as for the backup of cryptographic keys. 821 However, it also imposes some limitations. First, it represents a 822 single point of failure. This is a major drawback, e.g., when key 823 agreement between two devices requires online connectivity to the 824 central node. Second, it limits the possibility to create ad-hoc 825 security domains without dedicated security infrastructure. Third, 826 it codifies a more static world view, where device roles are cast in 827 stone, rather than a more dynamic world view that recognizes that 828 networks and devices, and their roles and ownership, may change over 829 time (e.g., due to device replacement and hand-over of control). 831 Decentralized architectures, on the other hand, allow creating ad-hoc 832 security domains that might not require a single online management 833 entity and are operative in a much more stand-alone manner. The ad- 834 hoc security domains can be added to a centralized architecture at a 835 later point in time, allowing for central or remote management. 837 The choice of security architecture has many implications regarding 838 key management, access control, or security scope. A distributed (or 839 ad-hoc) architecture means that security relationships between things 840 are setup on the fly between a number of objects and kept in a 841 decentralized fashion. A locally centralized security architecture 842 means that a central device, e.g., the 6LBR, handles the keys for all 843 the devices in the security domain. Alternatively, a central 844 security architecture could also refer to the fact that smart objects 845 are managed from the backend. The security architecture for the 846 different security profiles is classified as follows. 848 +---------------------------------------------------------+ 849 | Description | 850 +----------+---------------------------------------------------------+ 851 |SecProf_1 | Distributed | 852 +----------+---------------------------------------------------------+ 853 |SecProf_2 | Distributed able to move centralized (local) | 854 +----------+---------------------------------------------------------+ 855 |SecProf_3 | Centralized (local &/or backend) | 856 +----------+---------------------------------------------------------+ 857 |SecProf_4 | Distributed & centralized (local &/or backend) | 858 +----------+---------------------------------------------------------+ 860 Figure 6: Security architectures in different security profiles. 862 In "SecProf_1", management mechanisms for the distributed assignment 863 and management of keying materials is required. Since this is a very 864 simple use case, access control to the security domain can be enabled 865 by means of a common secret known to all devices. In the next 866 security suite (SecProf_2), a central device can assume key 867 management responsibilities and handle the access to the network. 868 The last two security suites (SecProf_3 and SecProf_4) further allow 869 for the management of devices or some keying materials from the 870 backend. 872 5.2. Security Model 874 While some applications might involve very resource-constrained 875 things such as, e.g., a humidity, pollution sensor, other 876 applications might target more powerful devices aimed at more exposed 877 applications. Security parameters such as keying materials, 878 certificates, etc must be protected in the thing, for example by 879 means of tamper-resistant hardware. Keys may be shared across a 880 thing's networking stack to provide authenticity and confidentiality 881 in each networking layer. This would minimize the number of key 882 establishment/agreement handshake and incurs less overhead for 883 constrained thing. While more advance applications may require key 884 separation at different networking layers, and possibly process 885 separation and sandboxing to isolate one application from another. 886 In this sense, this section reflects the fact that different 887 applications require different sets of security mechanisms. 889 +---------------------------------------------------------+ 890 |Description | 891 +----------+---------------------------------------------------------+ 892 |SecProf_1 |No tamper resistant | 893 | |Sharing keys between layers | 894 +----------+---------------------------------------------------------+ 895 |SecProf_2 |No tamper resistant | 896 | |Sharing keys between layers | 897 +----------+---------------------------------------------------------+ 898 |SecProf_3 |Tamper resistant | 899 | |Key and process separation | 900 +----------+---------------------------------------------------------+ 901 |SecProf_4 |(no) Tamper resistant | 902 | |Sharing keys between layers/Key and process separation | 903 | |Sandbox | 904 +----------+---------------------------------------------------------+ 906 Figure 7: Thing security models in different security profiles. 908 5.3. Security Bootstrapping and Management 910 Bootstrapping refers to the process by which a thing initiates its 911 life within a security domain and includes the initialization of 912 secure and/or authentic parameters bound to the thing and at least 913 one other device in the network. Here, different mechanisms may be 914 used to achieve confidentiality and/or authenticity of these 915 parameters, depending on deployment scenario assumptions and the 916 communication channel(s) used for passing these parameters. The 917 simplest mechanism for initial set-up of secure and authentic 918 parameters is via communication in the clear using a physical 919 interface (USB, wire, chip contact, etc.). Here, one commonly 920 assumes this communication channel is secure, since eavesdropping 921 and/or manipulation of this interface would generally require access 922 to the physical medium and, thereby, to one or both of the devices 923 themselves. This mechanism was used with the so-called original 924 "resurrecting duckling" model, as introduced in [PROC-Stajano-99]. 925 This technique may also be used securely in wireless, rather than 926 wired, set-ups, if the prospect of eavesdropping and/or manipulating 927 this channel are dim (a so-called "location-limited" channel 928 [PROC-Smetters-04][PROC-Smetters-02]). Examples hereof include the 929 communication of secret keys in the clear using near field 930 communication (NFC) - where the physical channel is purported to have 931 very limited range (roughly 10cm), thereby thwarting eavesdropping by 932 far-away adversarial devices, and in-the-clear communication during a 933 small time window (triggered by, e.g., a button-push) - where 934 eavesdropping is presumed absent during this small time window. With 935 the use of public-key based techniques, assumptions on the 936 communication channel can be relaxed even further, since then the 937 cryptographic technique itself provides for confidentiality of the 938 channel set-up and the location-limited channel - or use of 939 certificates - rules out man-in-the-middle attacks, thereby providing 940 authenticity [PROC-Smetters-02]. The same result can be obtained 941 using password-based public-key protocols [SPEKE], where authenticity 942 depends on the (weak) password not being guessed during execution of 943 the protocol. 945 It should be noted that while most of these techniques realize a 946 secure and authentic channel for passing parameters, these generally 947 do not provide for explicit authorization. As an example, with use 948 of certificate-based public-key based techniques, one may obtain hard 949 evidence on whom one shares secret and/or authentic parameters with, 950 but this does not answer the question as to whether one wishes to 951 share this information at all with this specifically identified 952 device (the latter usually involves a human-decision element). Thus, 953 the bootstrapping mechanisms above should generally be complemented 954 by mechanisms that regulate (security policies for) authorization. 955 Furthermore, the type of bootstrapping is very related to the 956 required type of security architecture. Distributed bootstrapping 957 means that a pair of devices can setup a security relationship on the 958 fly, without interaction with a central device elsewhere within the 959 system. In many cases, it is handy to have a distributed 960 bootstrapping protocol based on existing security protocols (e.g., 961 DTLS in CoAP) required for other purposes: this reduces the amount of 962 required software. A centralized bootstrapping protocol is one in 963 which a central device manages the security relationships within a 964 network. This can happen locally, e.g., handled by the 6LBR, or 965 remotely, e.g., from a server connected via the Internet. The 966 security bootstrapping for the different security profiles is as 967 follows. 969 +---------------------------------------------------------+ 970 |Description | 971 +----------+---------------------------------------------------------+ 972 |SecProf_1 |* Distributed, (e.g., Resurrecting duckling) | 973 | |* First key distribution happens in the clear | 974 +----------+---------------------------------------------------------+ 975 |SecProf_2 |* Distributed, (e.g., Resurrecting duckling ) | 976 | |* Centralized (local), 6LBR acts as KDC | 977 | |* First key distribution occurs in the clear, if the KDC | 978 | | is available, the KDC can manage network access | 979 +----------+---------------------------------------------------------+ 980 |SecProf_3 |* 6LBR acts as KDC. It handles node joining, provides | 981 | | them with keying material from L2 to application layers| 982 | |* Bootstrapping occurs in a secure way - either in secure| 983 | | environment or the security mechanisms ensure that | 984 | | eavesdropping is not possible. | 985 | |* KDC and backend can implement secure methods for | 986 | | network access | 987 +----------+---------------------------------------------------------+ 988 |SecProf_4 |* As in SecProf_3. | 989 +----------+---------------------------------------------------------+ 991 Figure 8: Security bootstrapping methods in different security 992 profiles 994 5.4. Network Security 996 Network security refers to the mechanisms used to ensure the secure 997 transport of 6LoWPAN frames. This involves a multitude of issues 998 ranging from secure discovery, frame authentication, routing 999 security, detection of replay, secure group communication, etc. 1000 Network security is important to thwart potential attacks such as 1001 denial-of-service (e.g., through message flooding) or routing 1002 attacks. 1004 The Internet Draft [ID-Tsao] presents a very good overview of attacks 1005 and security needs classified according to the confidentiality, 1006 integrity, and availability needs. A potential limitation is that 1007 there exist no differentiation in security between different use 1008 cases and the framework is limited to L3. The security suites 1009 gathered in the present ID aim at solving this by allowing for a more 1010 flexible selection of security needs at L2 and L3. 1012 +---------------------------------------------------------+ 1013 |Description | 1014 +----------+---------------------------------------------------------+ 1015 |SecProf_1 |* Network key creating a home security domain at L2 | 1016 | | ensuring authentication and freshness of exchanged data| 1017 | |* Secure multicast does not ensure origin authentication | 1018 | |* No need for secure routing at L3 | 1019 +----------+---------------------------------------------------------+ 1020 |SecProf_2 |* Network key creating a home security domain at L2 | 1021 | | ensuring authentication and freshness of exchanged data| 1022 | |* Secure multicast does not ensure origin authentication | 1023 | |* No need for secure routing at L3 | 1024 +----------+---------------------------------------------------------+ 1025 |SecProf_3 |* Network key creating an industry security domain at L2 | 1026 | | ensuring authentication and freshness of exchanged data| 1027 | |* Secure routing needed (integrity & availability) at L3 | 1028 | | within 6LoWPAN/CoAP | 1029 | |* Secure multicast requires origin authentication | 1030 +----------+---------------------------------------------------------+ 1031 |SecProf_4 |* Network key creating an industry security domain at L2 | 1032 | | ensuring authentication and freshness of exchanged data| 1033 | |* Inter-domain authentication/secure handoff | 1034 | |* Secure routing needed at L3 | 1035 | |* Secure multicast requires origin authentication | 1036 | |* 6LBR (HTTP-CoAP proxy) requires verification of | 1037 | | forwarded messages and messages leaving or entering the| 1038 | | 6LoWPAN/CoAP network. | 1039 +----------+---------------------------------------------------------+ 1041 Figure 9: Network security needs in different security profiles 1043 5.5. Application Security 1045 In the context of 6LoWPAN/CoAP networks, application security refers 1046 firstly to the configuration of DTLS used to protect the exchanged 1047 information. It further refers to the measures required in potential 1048 translation points (e.g., a (HTTP-CoAP) proxy) where information can 1049 be collected and the privacy sphere of users in a given security 1050 domain is endangered. Application security for the different 1051 security profiles is as follows. 1053 +---------------------------------------------------------+ 1054 |Description | 1055 +----------+---------------------------------------------------------+ 1056 |SecProf_1 | - | 1057 +----------+---------------------------------------------------------+ 1058 |SecProf_2 |* DTLS is used for end-to-end application security | 1059 | | between management device and things and between things| 1060 | |* DTLS ciphersuites configurable to provide | 1061 | | confidentiality and/or authentication and/or freshness | 1062 | |* Key transport and policies for generation of session | 1063 | | keys are required | 1064 +----------+---------------------------------------------------------+ 1065 |SecProf_3 |* Requirements as in SecProf_2 and | 1066 | |* DTLS is used for end-to-end application security | 1067 | | between management device and things and between things| 1068 | |* Communication between KDC and each thing secured by | 1069 | | pairwise keys | 1070 | |* Group keys for communication in a group distributed | 1071 | | by KDC | 1072 | |* Privacy protection should be provided in translation | 1073 | | points | 1074 +----------+---------------------------------------------------------+ 1075 |SecProf_4 |* Requirements as in SecProf_3 and | 1076 | |* TLS or DTLS can be used to send commands from the | 1077 | | backend to the 6LBR or things in a 6LoWPAN/CoAP network| 1078 | |* End-to-end secure connectivity from backend required | 1079 | |* Secure broadcast in a network from backend required | 1080 +----------+---------------------------------------------------------+ 1082 Figure 10: Application security methods in different security 1083 profiles 1085 The first two security profiles do not include any security at the 1086 application layer. The reason is that, in the first case, security 1087 is not provided and, in the second case, it seems reasonable to 1088 provide basic security at L2. In the third security profile 1089 (SecProf_2), DTLS becomes the way of protecting messages at 1090 application layer between things and with the KDC running on a 6LBR. 1091 A key option refers to the capability of easily configuring DTLS to 1092 provide a subset of security services (e.g., some applications do not 1093 require confidentiality) to reduce the impact of security in the 1094 system operation of resource-constrained things. In addition to 1095 basic key management mechanisms running within the KDC, communication 1096 protocols for key transport or key update are required. These 1097 protocols could be based on DTLS. The next security suite 1098 (SecProf_3) requires pairwise keys for communication between things 1099 within the security domain. Furthermore, it can involve the usage of 1100 group keys for group communication. If secure multicast is 1101 implemented, it should provide origin authentication. Finally, 1102 privacy protection should be taken into account to limit access to 1103 valuable information -- such as identifiers, type of collected data, 1104 traffic patterns -- in potential translation points (proxies) or in 1105 the backend. The last security suite (SecProf_4) further extends the 1106 previous set of requirements considering security mechanisms to deal 1107 with translations between TLS and DTLS or for the provision of secure 1108 multicast within a 6LoWPAN/CoAP network from the backend. 1110 6. Challenges and Security Considerations for a Secure Internet of 1111 Things 1113 <> 1115 In this section, we take a closer look at the various security 1116 challenges in the operational and technical features of the IoT and 1117 then discuss how existing Internet security protocols cope with these 1118 technical and conceptual challenges through the lifecycle of a thing. 1119 Figure 2 summarizes which requirements need to be met in the 1120 lifecycle phases as well as some of the considered protocols. This 1121 discussion should neither be understood as a comprehensive evaluation 1122 of all protocols, nor can it cover all possible aspects of IoT 1123 security. Yet, it aims at showing concrete limitations of existing 1124 Internet security protocols in some areas rather than giving an 1125 abstract discussion about general properties of the protocols. In 1126 this regard, the discussion handles issues that are most important 1127 from the authors' perspectives. 1129 6.1. Constraints and Heterogeneous Communication 1131 Coupling resource constrained networks and the powerful Internet is a 1132 challenge because the resulting heterogeneity of both networks 1133 complicates protocol design and system operation. In the following 1134 we briefly discuss the resource constraints of IoT devices and the 1135 consequences for the use of Internet Protocols in the IoT domain. 1137 6.1.1. Tight Resource Constraints 1139 The IoT is a resource-constrained network that relies on lossy and 1140 low-bandwidth channels for communication between small nodes, 1141 regarding CPU, memory, and energy budget. These characteristics 1142 directly impact the threats to and the design of security protocols 1143 for the IoT domain. First, the use of small packets, e.g., IEEE 1144 802.15.4 supports 127-byte sized packets at the physical layer, may 1145 result in fragmentation of larger packets of security protocols. 1146 This may open new attack vectors for state exhaustion DoS attacks, 1147 which is especially tragic, e.g., if the fragmentation is caused by 1148 large key exchange messages of security protocols. Moreover, packet 1149 fragmentation commonly downgrades the overall system performance due 1150 to fragment losses and the need for retransmissions. For instance, 1151 fate-sharing packet flight as implemented by DTLS might aggravate the 1152 resulting performance loss. 1154 The size and number of messages should be minimized to reduce memory 1155 requirements and optimize bandwidth usage. In this context, layered 1156 approaches involving a number of protocols might lead to worse 1157 performance in resource-constrained devices since they combine the 1158 headers of the different protocols. In some settings, protocol 1159 negotiation can increase the number of exchanged messages. To 1160 improve performance during basic procedures such as, e.g., 1161 bootstrapping, it might be a good strategy to perform those 1162 procedures at a lower layer. 1164 Small CPUs and scarce memory limit the usage of resource-expensive 1165 cryptoprimitives such as public-key cryptography as used in most 1166 Internet security standards. This is especially true, if the basic 1167 cryptoblocks need to be frequently used or the underlying application 1168 demands a low delay. 1170 Independently from the development in the IoT domain, all discussed 1171 security protocols show efforts to reduce the cryptographic cost of 1172 the required public-key-based key exchanges and signatures with 1173 ECC[RFC5246][RFC5903][RFC7401][ID-HIP]. Moreover, all protocols have 1174 been revised in the last years to enable crypto agility, making 1175 cryptographic primitives interchangeable. However, these 1176 improvements are only a first step in reducing the computation and 1177 communication overhead of Internet protocols. The question remains 1178 if other approaches can be applied to leverage key agreement in these 1179 heavily resource-constrained environments. 1181 A further fundamental need refers to the limited energy budget 1182 available to IoT nodes. Careful protocol (re)design and usage is 1183 required to reduce not only the energy consumption during normal 1184 operation, but also under DoS attacks. Since the energy consumption 1185 of IoT devices differs from other device classes, judgments on the 1186 energy consumption of a particular protocol cannot be made without 1187 tailor-made IoT implementations. 1189 6.1.2. Denial-of-Service Resistance 1191 The tight memory and processing constraints of things naturally 1192 alleviate resource exhaustion attacks. Especially in unattended T2T 1193 communication, such attacks are difficult to notice before the 1194 service becomes unavailable (e.g., because of battery or memory 1195 exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and Diet HIP 1196 implement return routability checks based on a cookie mechanism to 1197 delay the establishment of state at the responding host until the 1198 address of the initiating host is verified. The effectiveness of 1199 these defenses strongly depends on the routing topology of the 1200 network. Return routability checks are particularly effective if 1201 hosts cannot receive packets addressed to other hosts and if IP 1202 addresses present meaningful information as is the case in today's 1203 Internet. However, they are less effective in broadcast media or 1204 when attackers can influence the routing and addressing of hosts 1205 (e.g., if hosts contribute to the routing infrastructure in ad-hoc 1206 networks and meshes). 1208 In addition, HIP implements a puzzle mechanism that can force the 1209 initiator of a connection (and potential attacker) to solve 1210 cryptographic puzzles with variable difficulties. Puzzle-based 1211 defense mechanisms are less dependent on the network topology but 1212 perform poorly if CPU resources in the network are heterogeneous 1213 (e.g., if a powerful Internet host attacks a thing). Increasing the 1214 puzzle difficulty under attack conditions can easily lead to 1215 situations, where a powerful attacker can still solve the puzzle 1216 while weak IoT clients cannot and are excluded from communicating 1217 with the victim. Still, puzzle-based approaches are a viable option 1218 for sheltering IoT devices against unintended overload caused by 1219 misconfigured or malfunctioning things. 1221 6.1.3. Protocol Translation and End-to-End Security 1223 Even though 6LoWPAN and CoAP progress towards reducing the gap 1224 between Internet protocols and the IoT, they do not target protocol 1225 specifications that are identical to their Internet counterparts due 1226 to performance reasons. Hence, more or less subtle differences 1227 between IoT protocols and Internet protocols will remain. While 1228 these differences can easily be bridged with protocol translators at 1229 gateways, they become major obstacles if end-to-end security measures 1230 between IoT devices and Internet hosts are used. 1232 Cryptographic payload processing applies message authentication codes 1233 or encryption to packets. These protection methods render the 1234 protected parts of the packets immutable as rewriting is either not 1235 possible because a) the relevant information is encrypted and 1236 inaccessible to the gateway or b) rewriting integrity-protected parts 1237 of the packet would invalidate the end-to-end integrity protection. 1239 There are essentially four solutions for this problem: 1241 1. Sharing credentials with gateways enables gateways to transform 1242 (e.g., de-compress, convert, etc.) packets and re-apply the 1243 security measures after transformation. This method abandons 1244 end-to-end security and is only applicable to simple scenarios 1245 with a rudimentary security model. 1247 2. Reusing the Internet wire format in the IoT makes conversion 1248 between IoT and Internet protocols unnecessary. However, it 1249 leads to poor performance because IoT specific optimizations 1250 (e.g., stateful or stateless compression) are not possible. 1252 3. Selectively protecting vital and immutable packet parts with a 1253 MAC or with encryption requires a careful balance between 1254 performance and security. Otherwise, this approach will either 1255 result in poor performance (protect as much as possible) or poor 1256 security (compress and transform as much as possible). 1258 4. Message authentication codes that sustain transformation can be 1259 realized by considering the order of transformation and 1260 protection (e.g., by creating a signature before compression so 1261 that the gateway can decompress the packet without recalculating 1262 the signature). This enables IoT specific optimizations but is 1263 more complex and may require application-specific transformations 1264 before security is applied. Moreover, it cannot be used with 1265 encrypted data because the lack of cleartext prevents gateways 1266 from transforming packets. 1268 5. Object security based mechanisms can bridge the protocol worlds, 1269 but still requires that the two worlds use the same object 1270 security formats. Currently the IoT based object security format 1271 based on COSE is different from the Internet based JOSE or CMS. 1272 Legacy devices on the Internet side will need to update to the 1273 newer IoT protocols to enable real end-to-end security. 1275 To the best of our knowledge, none of the mentioned security 1276 protocols provides a fully customizable solution in this problem 1277 space. 1279 6.2. Bootstrapping of a Security Domain 1281 Creating a security domain from a set of previously unassociated IoT 1282 devices is a key operation in the lifecycle of a thing and in the IoT 1283 network. This aspect is further elaborated and discussed in the 1284 T2TRG draft on bootstrapping [ID-bootstrap]. 1286 6.3. Operation 1288 After the bootstrapping phase, the system enters the operational 1289 phase. During the operational phase, things can relate to the state 1290 information created during the bootstrapping phase in order to 1291 exchange information securely and in an authenticated fashion. In 1292 this section, we discuss aspects of communication patterns and 1293 network dynamics during this phase. 1295 6.3.1. End-to-End Security 1297 Providing end-to-end security is of great importance to address and 1298 secure individual T2T or H2T communication within one IoT domain. 1299 Moreover, end-to-end security associations are an important measure 1300 to bridge the gap between the IoT and the Internet. IKEv2 and HIP, 1301 TLS and DTLS provide end-to-end security services including peer 1302 entity authentication, end-to-end encryption and integrity protection 1303 above the network layer and the transport layer respectively. Once 1304 bootstrapped, these functions can be carried out without online 1305 connections to third parties, making the protocols applicable for 1306 decentralized use in the IoT. However, protocol translation by 1307 intermediary nodes may invalidate end-to-end protection measures (see 1308 Section 5.1). Also these protocols require end-to-end connectivity 1309 between the devices and do not support store-and-forward scenarios. 1310 Object security is an option for such scenarios and the work on 1311 OSCOAP [ID-OSCOAP] is a potential solution in this space, in 1312 particular, in the context of forwarding proxies. 1314 6.3.2. Group Membership and Security 1316 In addition to end-to-end security, group key negotiation is an 1317 important security service for the T2Ts and Ts2T communication 1318 patterns in the IoT as efficient local broadcast and multicast relies 1319 on symmetric group keys. 1321 All discussed protocols only cover unicast communication and 1322 therefore do not focus on group-key establishment. However, the 1323 Diffie-Hellman keys that are used in IKEv2 and HIP could be used for 1324 group Diffie-Hellman key-negotiations. Conceptually, solutions that 1325 provide secure group communication at the network layer (IPsec/IKEv2, 1326 HIP/Diet HIP) may have an advantage regarding the cryptographic 1327 overhead compared to application-focused security solutions (TLS/ 1328 DTLS or OSCOAP). This is due to the fact that application-focused 1329 solutions require cryptographic operations per group application, 1330 whereas network layer approaches may allow to share secure group 1331 associations between multiple applications (e.g., for neighbor 1332 discovery and routing or service discovery). Hence, implementing 1333 shared features lower in the communication stack can avoid redundant 1334 security measures. 1336 A number of group key solutions have been developed in the context of 1337 the IETF working group MSEC in the context of the MIKEY architecture 1338 [WG-MSEC][RFC4738]. These are specifically tailored for multicast 1339 and group broadcast applications in the Internet and should also be 1340 considered as candidate solutions for group key agreement in the IoT. 1341 The MIKEY architecture describes a coordinator entity that 1342 disseminates symmetric keys over pair-wise end-to-end secured 1343 channels. However, such a centralized approach may not be applicable 1344 in a distributed environment, where the choice of one or several 1345 coordinators and the management of the group key is not trivial. 1347 6.3.3. Mobility and IP Network Dynamics 1349 It is expected that many things (e.g., wearable sensors, and user 1350 devices) will be mobile in the sense that they are attached to 1351 different networks during the lifetime of a security association. 1352 Built-in mobility signaling can greatly reduce the overhead of the 1353 cryptographic protocols because unnecessary and costly re- 1354 establishments of the session (possibly including handshake and key 1355 agreement) can be avoided. IKEv2 supports host mobility with the 1356 MOBIKE [RFC4555][RFC4621] extension. MOBIKE refrains from applying 1357 heavyweight cryptographic extensions for mobility. However, MOBIKE 1358 mandates the use of IPsec tunnel mode which requires to transmit an 1359 additional IP header in each packet. This additional overhead could 1360 be alleviated by using header compression methods or the Bound End- 1361 to-End Tunnel (BEET) mode [ID-Nikander], a hybrid of tunnel and 1362 transport mode with smaller packet headers. 1364 HIP offers a simple yet effective mobility management by allowing 1365 hosts to signal changes to their associations [RFC5206]. However, 1366 slight adjustments might be necessary to reduce the cryptographic 1367 costs, for example, by making the public-key signatures in the 1368 mobility messages optional. Diet HIP does not define mobility yet 1369 but it is sufficiently similar to HIP to employ the same mechanisms. 1370 TLS and DTLS do not have standards for mobility support, however, 1371 work on DTLS mobility exists in the form of an Internet draft 1372 [ID-Williams]. The specific need for IP-layer mobility mainly 1373 depends on the scenario in which nodes operate. In many cases, 1374 mobility support by means of a mobile gateway may suffice to enable 1375 mobile IoT networks, such as body sensor networks. However, if 1376 individual things change their point of network attachment while 1377 communicating, mobility support may gain importance. 1379 6.4. Software update 1381 IoT devices have a reputation for being insecure at the time of 1382 manufacture. Yet they are often expected to stay functional in live 1383 deployments for years and even decades. Additionally, these devices 1384 typically operate unattended with direct Internet connectivity. 1385 Therefore, a remote software update mechanism to fix vulnerabilities, 1386 to update configuration settings, and for adding new functionality is 1387 needed. 1389 Schneier [SchneierSecurity] in his essay expresses concerns about the 1390 status of software and firmware update mechanisms for Internet of 1391 Things (IoT) devices. He highlights several challenges that hinder 1392 mechanisms for secure software update of IoT devices. First, there 1393 is a lack of incentives for manufactures, vendors and others on the 1394 supply chain to issue updates for their devices. Second, parts of 1395 the software running on the IoT devices is simply a binary blob 1396 without any source code available. Since the complete source code 1397 isn't available, no patches can be written for that piece of code. 1398 Third, even when updates are available, users generally have to 1399 manually download and install those updates. However, users are 1400 never alerted about security updates and many times don't have the 1401 necessary expertise to manually administer the required updates. 1403 The FTC staff report on Internet of Things - Privacy & Security in a 1404 Connected World [FTCreport] and the Article 29 Working Party Opinion 1405 8/2014 on the on Recent Developments on the Internet of Things 1406 [Article29] also document the challenges for secure remote software 1407 update of IoT devices. They note that even providing such a software 1408 update capability may add new vulnerabilities for constrained 1409 devices. For example, a buffer overflow vulnerability in the 1410 implementation of a software update protocol (TR69) [TR69] and an 1411 expired certificate in a hub device [wink] demonstrate how the 1412 software update process itself can introduce vulnerabilities. 1414 While powerful IoT devices that run general purpose operating systems 1415 can make use of sophisticated software update mechanisms known from 1416 the desktop world, a more considerate effort is needed for resource- 1417 constrained devices that don't have any operating system and are 1418 typically not equipped with a memory management unit or similar 1419 tools. The IAB also organized a workshop to understand the 1420 challenges for secure software update of IoT devices. A summary of 1421 the workshop and the proposed next steps have been documented 1422 [iotsu]. 1424 6.5. Verifying device behavior 1426 Users often have a false sense of privacy when using new Internet of 1427 Things (IoT) appliances such as Internet-connected smart televisions, 1428 speakers and cameras. Recent revelations have shown that this user 1429 belief is often unfounded. Many IoT device vendors have been caught 1430 collecting sensitive private data through these connected appliances 1431 with or without appropriate user warnings [cctv]. 1433 An IoT device user/owner would like to monitor and know if the device 1434 is calling home (i.e. verify its operational behavior). The calling 1435 home feature may be necessary in some scenarios, such as during the 1436 initial configuration of the device. However, the user should be 1437 kept aware of the data that the device is sending back to the vendor. 1438 For example, the user should be ensured that his/her TV is not 1439 sending data when he/she inserts a new USB stick. 1441 Providing such information to the users in an understandable fashion 1442 is challenging. This is because the IoT device are not only 1443 resource-constrained in terms of their computational capability, but 1444 also in terms of the user interface available. Also, the network 1445 infrastructure where these devices are deployed will vary 1446 significantly from one user environment to another. Therefore, where 1447 and how this monitoring feature is implemented still remains an open 1448 question. 1450 6.6. End-of-life 1452 Like all commercial devices, most IoT devices will be end-of-lifed by 1453 vendors. This may be planned or unplanned (for example when the 1454 vendor or manufacturer goes bankrupt). A user should still be able 1455 to use and perhaps even update the device. This requires for some 1456 form of authorization handover. 1458 Although this may seem far fetched given the commercial interests and 1459 market dynamics, we have examples from the mobile world where the 1460 devices have been functional and up-to-date long after the original 1461 vendor stopped supporting the device. CyanogenMod for Android 1462 devices and OpenWrt for home routers are two such instances where 1463 users have been able to use and update their devices even after they 1464 were end-of-lifed. Admittedly these are not easy for an average 1465 users to install and configure on their devices. With the deployment 1466 of millions of IoT devices, simpler mechanisms are needed to allow 1467 users to add new root-of-trusts and install software and firmware 1468 from other sources once the device has been end-of-lifed. 1470 6.7. Penetration testing 1472 Given that the IoT devices often have inadvertent vulnerabilities, 1473 both users and developers would want to perform penetration testing 1474 on their IoT devices. Nonetheless, since the devices are resource- 1475 constrained they often barf of crash even when minimal tests are 1476 performed. It remains to be seen how the software testing and 1477 quality assurance mechanisms used from the desktop and mobile world 1478 will be applied to IoT devices. 1480 6.8. Quantum-resistance 1482 Many IoT systems that are being deployed today will remain 1483 operational for many years. With the advancements made in the field 1484 of quantum computers, it is possible that large-scale quantum 1485 computers are available in the future for performing cryptanalysis on 1486 existing cryptographic algorithms and cipher suites. If this 1487 happened, it would have two consequences. First, functionalities 1488 enabled by means of RSA/ECC - namely key exchange, public-key 1489 encryption and signature - would not be secure anymore due to Shor's 1490 algorithm. Second, the security level of symmetric algorithms will 1491 decrease, e.g., the security of a block cipher with a key size of b 1492 bits will only offer b/2 bits of security due to Grover's algorithm. 1494 This would require to update to quantum-resistant alternatives, in 1495 particular, for those functionalities involving key exchange, public- 1496 key encryption and signatures. While such future planning is hard, 1497 it may be a necessity in certain critical IoT deployments which are 1498 expected to last decades or more. Although increasing the key-size 1499 of the different algorithms is definitely an option, it would also 1500 incur additional computation overhead and network traffic. This 1501 would be undesirable in most scenarios. There have been recent 1502 advancements in quantum-resistant cryptography. 1504 We refer to [ETSI_GR_QSC_001] for an extensive overview of existing 1505 quantum-resistant cryptography. RFC7696 provides guidelines for 1506 cryptographic algorithm agility. 1508 7. Next Steps towards a Flexible and Secure Internet of Things 1510 This Internet Draft included an overview of both operational and 1511 security requirements of things in the Internet of Things, discussed 1512 a general threat model and security issues, and introduced a number 1513 of potential security suites fitting different types of IoT 1514 deployments. 1516 We conclude this document by giving our assessment of the current 1517 status of IoT security with respect to addressing the IP security 1518 challenges. <> 1520 8. Security Considerations 1522 This document reflects upon the requirements and challenges of the 1523 security architectural framework for Internet of Things. 1525 9. IANA Considerations 1527 This document contains no request to IANA. 1529 10. Acknowledgements 1531 We gratefully acknowledge feedback and fruitful discussion with 1532 Tobias Heer and Robert Moskowitz. Acknowledge the additional authors 1533 of the previous version of this document Sye Loong Keoh, Rene Hummen 1534 and Rene Struik. 1536 11. Informative References 1538 [Article29] 1539 "Opinion 8/2014 on the on Recent Developments on the 1540 Internet of Things", Web http://ec.europa.eu/justice/data- 1541 protection/article-29/documentation/opinion- 1542 recommendation/files/2014/wp223_en.pdf, n.d.. 1544 [AUTO-ID] "AUTO-ID LABS", Web http://www.autoidlabs.org/, September 1545 2010. 1547 [BACNET] "BACnet", Web http://www.bacnet.org/, February 2011. 1549 [cctv] "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an 1550 Email Address In China", Web 1551 https://hardware.slashdot.org/story/16/02/17/0422259/ 1552 backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an- 1553 email-address-in-china, n.d.. 1555 [DALI] "DALI", Web http://www.dalibydesign.us/dali.html, February 1556 2011. 1558 [ETSI_GR_QSC_001] 1559 "Quantum-Safe Cryptography (QSC);Quantum-safe algorithmic 1560 framework", European Telecommunications Standards 1561 Institute (ETSI) , June 2016. 1563 [FTCreport] 1564 "FTC Report on Internet of Things Urges Companies to Adopt 1565 Best Practices to Address Consumer Privacy and Security 1566 Risks", Web https://www.ftc.gov/news-events/press- 1567 releases/2015/01/ftc-report-internet-things-urges- 1568 companies-adopt-best-practices, n.d.. 1570 [ID-bootstrap] 1571 Sarikaya, B. and M. Sethi, "Secure IoT Bootstrapping : A 1572 Survey", draft-sarikaya-t2trg-sbootstrapping-01 , July 1573 2016. 1575 [ID-Daniel] 1576 Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. 1577 Laganier, "IPv6 over Low Power WPAN Security Analysis", 1578 Internet Draft draft-daniel-6lowpan-security-analysis-05, 1579 March 2011. 1581 [ID-Hartke] 1582 Hartke, K. and O. Bergmann, "Datagram Transport Layer 1583 Security in Constrained Environments", draft-hartke-core- 1584 codtls-02 (work in progress), July 2012. 1586 [ID-HIP] Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz- 1587 hip-rg-dex-06 (work in progress), May 2012. 1589 [ID-Nikander] 1590 Nikander, P. and J. Melen, "A Bound End-to-End 1591 Tunnel(BEET) mode for ESP", draft-nikander-esp-beet- 1592 mode-09 , August 2008. 1594 [ID-OFlynn] 1595 O'Flynn, C., Sarikaya, B., Ohba, Y., Cao, Z., and R. 1596 Cragie, "Security Bootstrapping of Resource-Constrained 1597 Devices", draft-oflynn-core-bootstrapping-03 (work in 1598 progress), November 2010. 1600 [ID-OSCOAP] 1601 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1602 "Object Security of CoAP (OSCOAP)", draft-selander-ace- 1603 object-security-05 , July 2016. 1605 [ID-proHTTPCoAP] 1606 Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1607 E. Dijk, "Best practices for HTTP-CoAP mapping 1608 implementation", draft-castellani-core-http-mapping- 1609 07(work in progress), February 2013. 1611 [ID-Tsao] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. 1612 Lozano, "A Security Framework for Routing over Low Power 1613 and Lossy Networks", draft-ietf-roll-security- 1614 framework-07 , January 2012. 1616 [ID-Williams] 1617 Williams, M. and J. Barrett, "Mobile DTLS", draft-barrett- 1618 mobile-dtls-00 , March 2009. 1620 [iotsu] "Patching the Internet of Things: IoT Software Update 1621 Workshop 2016", Web 1622 https://www.ietf.org/blog/2016/07/patching-the-internet- 1623 of-things-iot-software-update-workshop-2016/, n.d.. 1625 [JOURNAL-Perrig] 1626 Perrig, A., Szewczyk, R., Wen, V., Culler, D., and J. 1627 Tygar, "SPINS: Security protocols for Sensor Networks", 1628 Journal Wireless Networks, September 2002. 1630 [NIST] Dworkin, M., "NIST Specification Publication 800-38B", 1631 2005. 1633 [PROC-Chan] 1634 Chan, H., Perrig, A., and D. Song, "Random Key 1635 Predistribution Schemes for Sensor Networks", 1636 Proceedings IEEE Symposium on Security and Privacy, 2003. 1638 [PROC-Gupta] 1639 Gupta, V., Wurm, M., Zhu, Y., Millard, M., Fung, S., Gura, 1640 N., Eberle, H., and S. Shantz, "Sizzle: A Standards-based 1641 End-to-End Security Architecture for the Embedded 1642 Internet", Proceedings Pervasive Computing and 1643 Communications (PerCom), 2005. 1645 [PROC-Smetters-02] 1646 Balfanz, D., Smetters, D., Steward, P., and H. Chi Wong,, 1647 "Talking To Strangers: Authentication in Ad-Hoc Wireless 1648 Networks", Paper NDSS, 2002. 1650 [PROC-Smetters-04] 1651 Balfanz, D., Durfee, G., Grinter, R., Smetters, D., and P. 1652 Steward, "Network-in-a-Box: How to Set Up a Secure 1653 Wireless Network in Under a Minute", Paper USENIX, 2004. 1655 [PROC-Stajano-99] 1656 Stajano, F. and R. Anderson, "Resurrecting Duckling - 1657 Security Issues for Adhoc Wireless Networks", 1658 7th International Workshop Proceedings, November 1999. 1660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1661 Requirement Levels", BCP 14, RFC 2119, 1662 DOI 10.17487/RFC2119, March 1997, 1663 . 1665 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1666 DOI 10.17487/RFC2818, May 2000, 1667 . 1669 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1670 A., Peterson, J., Sparks, R., Handley, M., and E. 1671 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1672 DOI 10.17487/RFC3261, June 2002, 1673 . 1675 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1676 Levkowetz, Ed., "Extensible Authentication Protocol 1677 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1678 . 1680 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1681 Neighbor Discovery (ND) Trust Models and Threats", 1682 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1683 . 1685 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1686 Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 1687 2004, . 1689 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1690 and Network Access (PANA) Threat Analysis and Security 1691 Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005, 1692 . 1694 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1695 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 1696 January 2006, . 1698 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1699 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1700 . 1702 [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 1703 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, 1704 DOI 10.17487/RFC4621, August 2006, 1705 . 1707 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1708 RSA-R: An Additional Mode of Key Distribution in 1709 Multimedia Internet KEYing (MIKEY)", RFC 4738, 1710 DOI 10.17487/RFC4738, November 2006, 1711 . 1713 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1714 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1715 Overview, Assumptions, Problem Statement, and Goals", 1716 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1717 . 1719 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1720 "Transmission of IPv6 Packets over IEEE 802.15.4 1721 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1722 . 1724 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1725 and A. Yegin, "Protocol for Carrying Authentication for 1726 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1727 May 2008, . 1729 [RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, 1730 "End-Host Mobility and Multihoming with the Host Identity 1731 Protocol", RFC 5206, DOI 10.17487/RFC5206, April 2008, 1732 . 1734 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1735 the Datagram Congestion Control Protocol (DCCP)", 1736 RFC 5238, DOI 10.17487/RFC5238, May 2008, 1737 . 1739 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1740 (TLS) Protocol Version 1.2", RFC 5246, 1741 DOI 10.17487/RFC5246, August 2008, 1742 . 1744 [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 1745 Threats and Security Requirements for the Access Node 1746 Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713, 1747 January 2010, . 1749 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 1750 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 1751 DOI 10.17487/RFC5903, June 2010, 1752 . 1754 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and 1755 A. Yegin, "Protocol for Carrying Authentication for 1756 Network Access (PANA) Relay Element", RFC 6345, 1757 DOI 10.17487/RFC6345, August 2011, 1758 . 1760 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and 1761 Application Spaces for IPv6 over Low-Power Wireless 1762 Personal Area Networks (6LoWPANs)", RFC 6568, 1763 DOI 10.17487/RFC6568, April 2012, 1764 . 1766 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1767 Application Protocol (CoAP)", RFC 7252, 1768 DOI 10.17487/RFC7252, June 2014, 1769 . 1771 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1772 Kivinen, "Internet Key Exchange Protocol Version 2 1773 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1774 2014, . 1776 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1777 the Constrained Application Protocol (CoAP)", RFC 7390, 1778 DOI 10.17487/RFC7390, October 2014, 1779 . 1781 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1782 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1783 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1784 . 1786 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1787 Agility and Selecting Mandatory-to-Implement Algorithms", 1788 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1789 . 1791 [SchneierSecurity] 1792 "The Internet of Things Is Wildly Insecure--And Often 1793 Unpatchable", Web 1794 https://www.schneier.com/essays/archives/2014/01/ 1795 the_internet_of_thin.html, n.d.. 1797 [THESIS-Langheinrich] 1798 Langheinrich, M., "Personal Privacy in Ubiquitous 1799 Computing", PhD Thesis ETH Zurich, 2005. 1801 [Thread] "Thread Alliance", Web http://threadgroup.org/, n.d.. 1803 [TinyDTLS] 1804 "TinyDTLS", Web http://tinydtls.sourceforge.net/, February 1805 2012. 1807 [TR69] "Too Many Cooks - Exploiting the Internet-of-TR- 1808 069-Things", Web https://media.ccc.de/v/31c3_-_6166_-_en_- 1809 _saal_6_-_201412282145_-_too_many_cooks_- 1810 _exploiting_the_internet-of-tr-069-things_- 1811 _lior_oppenheim_-_shahar_tal, n.d.. 1813 [WG-6LoWPAN] 1814 "IETF 6LoWPAN Working Group", 1815 Web http://tools.ietf.org/wg/6lowpan/, February 2011. 1817 [WG-CoRE] "IETF Constrained RESTful Environment (CoRE) Working 1818 Group", Web https://datatracker.ietf.org/wg/core/charter/, 1819 February 2011. 1821 [WG-MSEC] "MSEC Working Group", 1822 Web http://datatracker.ietf.org/wg/msec/, n.d.. 1824 [wink] "Wink's Outage Shows Us How Frustrating Smart Homes Could 1825 Be", 1826 Web http://www.wired.com/2015/04/smart-home-headaches/, 1827 n.d.. 1829 [ZB] "ZigBee Alliance", Web http://www.zigbee.org/, February 1830 2011. 1832 Authors' Addresses 1834 Oscar Garcia-Morchon 1835 Philips Research 1836 Canal Park 2 1837 Cambridge, 02141 1838 United States 1840 Email: oscar.garcia@philips.com 1842 Sandeep S. Kumar 1843 Philips Research 1844 High Tech Campus 1845 Eindhoven, 5656 AE 1846 The Netherlands 1848 Email: sandeep.kumar@philips.com 1849 Mohit Sethi 1850 Ericsson 1851 Hirsalantie 11 1852 Jorvas 1853 Finland 1855 Email: mohit@piuha.net