idnits 2.17.1 draft-garcia-core-security-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 11, 2013) is 3879 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AUTO-ID' is mentioned on line 113, but not defined == Missing Reference: 'RFC6568' is mentioned on line 120, but not defined == Missing Reference: 'BACNET' is mentioned on line 515, but not defined == Missing Reference: 'DALI' is mentioned on line 516, but not defined == Missing Reference: 'RFC2818' is mentioned on line 239, but not defined ** Obsolete undefined reference: RFC 2818 (Obsoleted by RFC 9110) == Missing Reference: 'RFC4919' is mentioned on line 239, but not defined == Missing Reference: 'RFC5713' is mentioned on line 240, but not defined == Missing Reference: 'RFC3833' is mentioned on line 240, but not defined == Missing Reference: 'RFC3261' is mentioned on line 240, but not defined == Missing Reference: 'RFC3756' is mentioned on line 241, but not defined == Missing Reference: 'RFC4016' is mentioned on line 241, but not defined == Missing Reference: 'ID-Daniel' is mentioned on line 334, but not defined == Missing Reference: 'ID-Tsao' is mentioned on line 1450, but not defined == Missing Reference: 'ZB' is mentioned on line 621, but not defined == Missing Reference: 'WG-6LoWPAN' is mentioned on line 521, but not defined == Missing Reference: 'RFC4944' is mentioned on line 523, but not defined == Missing Reference: 'WG-CoRE' is mentioned on line 524, but not defined == Missing Reference: 'ID-CoAP' is mentioned on line 527, but not defined == Missing Reference: 'RFC4306' is mentioned on line 540, but not defined ** Obsolete undefined reference: RFC 4306 (Obsoleted by RFC 5996) == Missing Reference: 'RFC5246' is mentioned on line 721, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC5238' is mentioned on line 540, but not defined == Missing Reference: 'RFC5201' is mentioned on line 541, but not defined ** Obsolete undefined reference: RFC 5201 (Obsoleted by RFC 7401) == Missing Reference: 'ID-Moskowitz' is mentioned on line 721, but not defined == Missing Reference: 'RFC5191' is mentioned on line 541, but not defined == Missing Reference: 'RFC3748' is mentioned on line 541, but not defined == Missing Reference: 'RFC4251' is mentioned on line 542, but not defined == Missing Reference: 'ID-HIP' is mentioned on line 721, but not defined == Missing Reference: 'PROC-Chan' is mentioned on line 618, but not defined == Missing Reference: 'JOURNAL-Perrig' is mentioned on line 619, but not defined == Missing Reference: 'THESIS-Langheinrich' is mentioned on line 625, but not defined == Missing Reference: 'PROC-Gupta' is mentioned on line 632, but not defined == Missing Reference: 'RFC5903' is mentioned on line 721, but not defined == Missing Reference: 'NIST' is mentioned on line 727, but not defined == Missing Reference: 'ID-OFlynn' is mentioned on line 946, but not defined == Missing Reference: 'RFC6345' is mentioned on line 944, but not defined == Missing Reference: 'WG-MSEC' is mentioned on line 1039, but not defined == Missing Reference: 'RFC4738' is mentioned on line 1039, but not defined == Missing Reference: 'RFC4555' is mentioned on line 1057, but not defined == Missing Reference: 'RFC4621' is mentioned on line 1057, but not defined == Missing Reference: 'ID-Nikander' is mentioned on line 1062, but not defined == Missing Reference: 'RFC5206' is mentioned on line 1066, but not defined ** Obsolete undefined reference: RFC 5206 (Obsoleted by RFC 8046) == Missing Reference: 'ID-Williams' is mentioned on line 1073, but not defined == Missing Reference: 'ID-CoAPMulticast' is mentioned on line 1231, but not defined == Missing Reference: 'ID-proHTTPCoAP' is mentioned on line 1239, but not defined == Missing Reference: 'PROC-Stajano' is mentioned on line 1369, but not defined == Missing Reference: 'PROC-Smetters-02' is mentioned on line 1385, but not defined == Missing Reference: 'SPEKE' is mentioned on line 1386, but not defined == Missing Reference: 'TinyDTLS' is mentioned on line 1586, but not defined == Missing Reference: 'ID-Hartke' is mentioned on line 1605, but not defined Summary: 5 errors (**), 0 flaws (~~), 51 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE O. Garcia-Morchon 3 Internet-Draft S. Kumar 4 Intended status: Informational Philips Research 5 Expires: March 15, 2014 S. Keoh 6 University of Glasgow 7 R. Hummen 8 RWTH Aachen 9 R. Struik 10 Struik Consultancy 11 September 11, 2013 13 Security Considerations in the IP-based Internet of Things 14 draft-garcia-core-security-06 16 Abstract 18 A direct interpretation of the Internet of Things concept refers to 19 the usage of standard Internet protocols to allow for human-to-thing 20 or thing-to-thing communication. Although the security needs are 21 well-recognized, it is still not fully clear how existing IP-based 22 security protocols can be applied to this new setting. This 23 Internet-Draft first provides an overview of security architecture, 24 its deployment model and general security needs in the context of the 25 lifecycle of a thing. Then, it presents challenges and requirements 26 for the successful roll-out of new applications and usage of standard 27 IP-based security protocols when applied to get a functional Internet 28 of Things. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 12, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Conventions and Terminology Used in this Document . . . . . . 4 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. The Thing Lifecycle and Architectural Considerations . . . . . 5 66 3.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Security Aspects . . . . . . . . . . . . . . . . . . . . . 10 68 4. State of the Art . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.1. IP-based Security Solutions . . . . . . . . . . . . . . . 13 70 4.2. Wireless Sensor Network Security and Beyond . . . . . . . 15 71 5. Challenges for a Secure Internet of Things . . . . . . . . . . 16 72 5.1. Constraints and Heterogeneous Communication . . . . . . . 16 73 5.1.1. Tight Resource Constraints . . . . . . . . . . . . . . 16 74 5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . . 18 75 5.1.3. Protocol Translation and End-to-End Security . . . . . 18 76 5.2. Bootstrapping of a Security Domain . . . . . . . . . . . . 20 77 5.2.1. Distributed vs. Centralized Architecture and 78 Operation . . . . . . . . . . . . . . . . . . . . . . 20 79 5.2.2. Bootstrapping a thing's identity and keying 80 materials . . . . . . . . . . . . . . . . . . . . . . 21 81 5.2.3. Privacy-aware Identification . . . . . . . . . . . . . 22 82 5.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 23 83 5.3.1. End-to-End Security . . . . . . . . . . . . . . . . . 23 84 5.3.2. Group Membership and Security . . . . . . . . . . . . 23 85 5.3.3. Mobility and IP Network Dynamics . . . . . . . . . . . 24 86 6. Security Suites for the IP-based Internet of Things . . . . . 25 87 6.1. Security Architecture . . . . . . . . . . . . . . . . . . 29 88 6.2. Security Model . . . . . . . . . . . . . . . . . . . . . . 30 89 6.3. Security Bootstrapping and Management . . . . . . . . . . 31 90 6.4. Network Security . . . . . . . . . . . . . . . . . . . . . 33 91 6.5. Application Security . . . . . . . . . . . . . . . . . . . 34 92 7. Next Steps towards a Flexible and Secure Internet of Things . 36 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 97 11.1. Informative References . . . . . . . . . . . . . . . . . 40 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 100 1. Conventions and Terminology Used in this Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in "Key words for use in 105 RFCs to Indicate Requirement Levels" [RFC2119]. 107 2. Introduction 109 The Internet of Things (IoT) denotes the interconnection of highly 110 heterogeneous networked entities and networks following a number of 111 communication patterns such as: human-to-human (H2H), human-to-thing 112 (H2T), thing-to-thing (T2T), or thing-to-things (T2Ts). The term IoT 113 was first coined by the Auto-ID center [AUTO-ID] in 1999. Since 114 then, the development of the underlying concepts has ever increased 115 its pace. Nowadays, the IoT presents a strong focus of research with 116 various initiatives working on the (re)design, application, and usage 117 of standard Internet technology in the IoT. 119 The introduction of IPv6 and web services as fundamental building 120 blocks for IoT applications [RFC6568] promises to bring a number of 121 basic advantages including: (i) a homogeneous protocol ecosystem that 122 allows simple integration with Internet hosts; (ii) simplified 123 development of very different appliances; (iii) an unified interface 124 for applications, removing the need for application-level proxies. 125 Such features greatly simplify the deployment of the envisioned 126 scenarios ranging from building automation to production environments 127 to personal area networks, in which very different things such as a 128 temperature sensor, a luminaire, or an RFID tag might interact with 129 each other, with a human carrying a smart phone, or with backend 130 services. 132 This Internet Draft presents an overview of the security aspects of 133 the envisioned all-IP architecture as well as of the lifecycle of an 134 IoT device, a thing, within this architecture. In particular, we 135 review the most pressing aspects and functionalities that are 136 required for a secure all-IP solution. 138 With this, this Internet-Draft pursues several goals. First, we aim 139 at presenting a comprehensive view of the interactions and 140 relationships between an IoT application and security. Second, we 141 aim at describing challenges for a secure IoT in the specific context 142 of the lifecycle of a resource-constrained device. The final goal of 143 this draft is to discuss the next steps towards a secure IoT. 145 The rest of the Internet-Draft is organized as follows. Section 3 146 depicts the lifecycle of a thing and gives general definitions for 147 the main security aspects within the IoT domain. In Section 4, we 148 review existing protocols and work done in the area of security for 149 wireless sensor networks. Section 5 identifies general challenges 150 and needs for an IoT security protocol design and discusses existing 151 protocols and protocol proposals against the identified requirements. 152 Section 6 proposes a number of illustrative security suites 153 describing how different applications involve distinct security 154 needs. Section 7 includes final remarks and conclusions. 156 3. The Thing Lifecycle and Architectural Considerations 158 We consider the installation of a Building Automation and Control 159 (BAC) system to illustrate the lifecycle of a thing in a BAC 160 scenario. A BAC system consists of a network of interconnected nodes 161 that perform various functions in the domains of HVAC (Heating, 162 Ventilating, and Air Conditioning), lighting, safety etc. The nodes 163 vary in functionality and a majority of them represent resource 164 constrained devices such as sensors and luminaries. Some devices may 165 also be battery operated or battery-less nodes, demanding for a focus 166 on low energy consumption and on sleeping devices. 168 In our example, the life of a thing starts when it is manufactured. 169 Due to the different application areas (i.e., HVAC, lighting, safety) 170 nodes are tailored to a specific task. It is therefore unlikely that 171 one single manufacturer will create all nodes in a building. Hence, 172 interoperability as well as trust bootstrapping between nodes of 173 different vendors is important. The thing is later installed and 174 commissioned within a network by an installer during the 175 bootstrapping phase. Specifically, the device identity and the 176 secret keys used during normal operation are provided to the device 177 during this phase. Different subcontractors may install different 178 IoT devices for different purposes. Furthermore, the installation 179 and bootstrapping procedures may not be a defined event but may 180 stretch over an extended period of time. After being bootstrapped, 181 the device and the system of things are in operational mode and run 182 the functions of the BAC system. During this operational phase, the 183 device is under the control of the system owner. For devices with 184 lifetimes spanning several years, occasional maintenance cycles may 185 be required. During each maintenance phase, the software on the 186 device can be upgraded or applications running on the device can be 187 reconfigured. The maintenance tasks can thereby be performed either 188 locally or from a backend system. Depending on the operational 189 changes of the device, it may be required to re-bootstrap at the end 190 of a maintenance cycle. The device continues to loop through the 191 operational phase and the eventual maintenance phase until the device 192 is decommissioned at the end of its lifecycle. However, the end-of- 193 life of a device does not necessarily mean that it is defective but 194 rather denotes a need to replace and upgrade the network to next- 195 generation devices in order to provide additional functionality. 196 Therefore the device can be removed and re-commissioned to be used in 197 a different network under a different owner by starting the lifecycle 198 over again. Figure 1 shows the generic lifecycle of a thing. This 199 generic lifecycle is also applicable for IoT scenarios other than BAC 200 systems. 202 At present, BAC systems use legacy building control standards such as 203 BACNet [BACNET] or DALI [DALI] with independent networks for each 204 subsystem (HVAC, lighting, etc.). However, this separation of 205 functionality adds further complexity and costs to the configuration 206 and maintenance of the different networks within the same building. 207 As a result, more recent building control networks employ IP-based 208 standards allowing seamless control over the various nodes with a 209 single management system. While allowing for easier integration, 210 this shift towards IP-based standards results in new requirements 211 regarding the implementation of IP security protocols on constrained 212 devices and the bootstrapping of security keys for devices across 213 multiple manufacturers. 215 _Manufactured _SW update _Decommissioned 216 / / / 217 | _Installed | _ Application | _Removed & 218 | / | / reconfigured | / replaced 219 | | _Commissioned | | | | 220 | | / | | | | _Reownership & 221 | | | _Application | | _Application | | / recommissioned 222 | | | / running | | / running | | | 223 | | | | | | | | | | \\ 224 +##+##+###+#############+##+##+#############+##+##+##############>>> 225 \/ \______________/ \/ \_____________/ \___/ time // 226 / / \ \ \ 227 Bootstrapping / Maintenance & \ Maintenance & 228 / re-bootstrapping \ re-bootstrapping 229 Operational Operational 231 The lifecycle of a thing in the Internet of Things. 233 Figure 1 235 3.1. Threat Analysis 237 This section explores the security threats and vulnerabilities of a 238 network of things in the IoTs. Security threats have been analyzed 239 in related IP protocols including HTTPS [RFC2818], 6LoWPAN [RFC4919], 240 ANCP [RFC5713], DNS security threats [RFC3833], SIP [RFC3261], IPv6 241 ND [RFC3756], and PANA [RFC4016]. Nonetheless, the challenge is 242 about their impacts on scenarios of the IoTs. In this section, we 243 specifically discuss the threats that could compromise an individual 244 thing, or network as a whole, with regard to different phases in the 245 thing's lifecycle. Note that these set of threats might go beyond 246 the scope of Internet protocols but we gather them here for the sake 247 of completeness. 249 1 Cloning of things: During the manufacturing process of a thing, 250 an untrusted manufacturer can easily clone the physical 251 characteristics, firmware/software, or security configuration of 252 the thing. Subsequently, such a cloned thing may be sold at a 253 cheaper price in the market, and yet be still able to function 254 normally, as a genuine thing. For example, two cloned devices 255 can still be associated and work with each other. In the worst 256 case scenario, a cloned device can be used to control a genuine 257 device. One should note here, that an untrusted manufacturer may 258 also change functionality of the cloned thing, resulting in 259 degraded functionality with respect to the genuine thing 260 (thereby, inflicting potential reputational risk to the original 261 thing manufacturer). Moreover, it can implement additional 262 functionality with the cloned thing, such as a backdoor. 264 2 Malicious substitution of things: During the installation of a 265 thing, a genuine thing may be substituted with a similar variant 266 of lower quality without being detected. The main motivation may 267 be cost savings, where the installation of lower-quality things 268 (e.g., non-certified products) may significantly reduce the 269 installation and operational costs. The installers can 270 subsequently resell the genuine things in order to gain further 271 financial benefits. Another motivation may be to inflict 272 reputational damage on a competitor's offerings. 274 3 Eavesdropping attack: During the commissioning of a thing into a 275 network, it may be susceptible to eavesdropping, especially if 276 operational keying materials, security parameters, or 277 configuration settings, are exchanged in clear using a wireless 278 medium. After obtaining the keying material, the attacker might 279 be able to recover the secret keys established between the 280 communicating entities (e.g., H2T, T2Ts, or Thing to the backend 281 management system), thereby compromising the authenticity and 282 confidentiality of the communication channel, as well as the 283 authenticity of commands and other traffic exchanged over this 284 communication channel. When the network is in operation, T2T 285 communication may be eavesdropped upon if the communication 286 channel is not sufficiently protected or in the event of session 287 key compromise due to a long period of usage without key renewal 288 or updates. 290 4 Man-in-the-middle attack: The commissioning phase may also be 291 vulnerable to man-in-the-middle attacks, e.g., when keying 292 material between communicating entities is exchanged in the clear 293 and the security of the key establishment protocol depends on the 294 tacit assumption that no third party is able to eavesdrop on or 295 sit in between the two communicating entities during the 296 execution of this protocol. Additionally, device authentication 297 or device authorization may be nontrivial, or may need support of 298 a human decision process, since things usually do not have a 299 priori knowledge about each other and can, therefore, not always 300 be able to differentiate friends and foes via completely 301 automated mechanisms. Thus, even if the key establishment 302 protocol provides cryptographic device authentication, this 303 knowledge on device identities may still need complementing with 304 a human-assisted authorization step (thereby, presenting a weak 305 link and offering the potential of man-in-the-middle attacks this 306 way). 308 5 Firmware Replacement attack: When a thing is in operation or 309 maintenance phase, its firmware or software may be updated to 310 allow for new functionality or new features. An attacker may be 311 able to exploit such a firmware upgrade by replacing the thing's 312 with malicious software, thereby influencing the operational 313 behaviour of the thing. For example, an attacker could add a 314 piece of malicious code to the firmware that will cause it to 315 periodically report the energy usage of the lamp to a data 316 repository for analysis. 318 6 Extraction of security parameters: A thing deployed in the 319 ambient environment (such as sensors, actuators, etc.) is usually 320 physically unprotected and could easily be captured by an 321 attacker. Such an attacker may then attempt to extract security 322 information such as keys (e.g., device's key, private-key, group 323 key) from this thing or try and re-program it to serve his needs. 324 If a group key is used and compromised this way, the whole 325 network may be compromised as well. Compromise of a thing's 326 unique key has less security impact, since only the communication 327 channels of this particular thing in question are compromised. 328 Here, one should caution that compromise of the communication 329 channel may also compromise all data communicated over this 330 channel. In particular, one has to be weary of, e.g., compromise 331 of group keys communicated over this channel (thus, leading to 332 transitive exposure ripple effects). 334 7 Routing attack: As highlighted in [ID-Daniel], routing 335 information in IoT can be spoofed, altered, or replayed, in order 336 to create routing loops, attract/repel network traffic, extend/ 337 shorten source routes, etc. Other relevant routing attacks 338 include 1) Sinkhole attack (or blackhole attack), where an 339 attacker declares himself to have a high-quality route/path to 340 the base station, thus allowing him to do anything to all packets 341 passing through it. 2) Selective forwarding, where an attacker 342 may selectively forward packets or simply drop a packet. 3) 343 Wormhole attack, where an attacker may record packets at one 344 location in the network and tunnel them to another location, 345 thereby influencing perceived network behaviour and potentially 346 distorting statistics, thus greatly impacting the functionality 347 of routing. 4) Sybil attack, whereby an attacker presents 348 multiple identities to other things in the network. 350 8 Privacy threat: The tracking of a thing's location and usage may 351 pose a privacy risk to its users. An attacker can infer 352 information based on the information gathered about individual 353 things, thus deducing behavioural patterns of the user of 354 interest to him. Such information can subsequently be sold to 355 interested parties for marketing purposes and targeted 356 advertizing. 358 9 Denial-of-Service attack: Typically, things have tight memory and 359 limited computation, they are thus vulnerable to resource 360 exhaustion attack. Attackers can continuously send requests to 361 be processed by specific things so as to deplete their resources. 362 This is especially dangerous in the IoTs since an attacker might 363 be located in the backend and target resource-constrained devices 364 in an LLN. Additionally, DoS attack can be launched by 365 physically jamming the communication channel, thus breaking down 366 the T2T communication channel. Network availability can also be 367 disrupted by flooding the network with a large number of packets. 369 The following table summarizes the security threats we identified 370 above and the potential point of vulnerabilities at different layers 371 of the communication stack. We also include related RFCs that 372 include a threat model that might apply to the IoTs. 374 +------------------+------------------+------------------+ 375 | Manufacturing | Installation/ | Operation | 376 | | Commissioning | | 377 +------------+------------------+------------------+------------------+ 378 |Thing's | Device Cloning |Substitution |Privacy threat | 379 |Model | | |Extraction of | 380 | | | |security params | 381 +------------+------------------+------------------+------------------+ 382 |Application | |RFC2818 |RFC2818, Firmware | 383 |Layer | |RFC4016 |replacement | 384 +------------+------------------+------------------+------------------+ 385 |Transport | | |Eavesdropping | 386 |Layer | |Eavesdropping & |Man-in-the-middle | 387 +------------+------------------|Man-in-the-middle |------------------+ 388 |Network | |attack |RFC4919,DoS attack| 389 |Layer | |RFC4919, RFC5713 |Routing attack | 390 | | |RFC3833, RFC3756 |RFC3833 | 391 +------------+------------------+------------------+------------------+ 392 |Physical | | |DoS attack | 393 |Layer | | | | 394 +-------------------------------+------------------+------------------+ 396 The security threat analysis 398 Figure 2 400 3.2. Security Aspects 402 The term security subsumes a wide range of different concepts. In 403 the first place, it refers to the basic provision of security 404 services including confidentiality, authentication, integrity, 405 authorization, non-repudiation, and availability, and some augmented 406 services, such as duplicate detection and detection of stale packets 407 (timeliness). These security services can be implemented by a 408 combination of cryptographic mechanisms, such as block ciphers, hash 409 functions, or signature algorithms, and non-cryptographic mechanisms, 410 which implement authorization and other security policy enforcement 411 aspects. For each of the cryptographic mechanisms, a solid key 412 management infrastructure is fundamental to handling the required 413 cryptographic keys, whereas for security policy enforcement, one 414 needs to properly codify authorizations as a function of device roles 415 and a security policy engine that implements these authorization 416 checks and that can implement changes hereto throughout the system's 417 lifecycle. 419 In the context of the IoT, however, the security must not only focus 420 on the required security services, but also how these are realized in 421 the overall system and how the security functionalities are executed. 423 To this end, we use the following terminology to analyze and classify 424 security aspects in the IoT: 426 1 The security architecture refers to the system elements involved 427 in the management of the security relationships between things 428 and the way these security interactions are handled (e.g., 429 centralized or distributed) during the lifecycle of a thing. 431 2 The security model of a node describes how the security 432 parameters, processes, and applications are managed in a thing. 433 This includes aspects such as process separation, secure storage 434 of keying materials, etc. 436 3 Security bootstrapping denotes the process by which a thing 437 securely joins the IoT at a given location and point in time. 438 Bootstrapping includes the authentication and authorization of a 439 device as well as the transfer of security parameters allowing 440 for its trusted operation in a given network. 442 4 Network security describes the mechanisms applied within a 443 network to ensure trusted operation of the IoT. Specifically, it 444 prevents attackers from endangering or modifying the expected 445 operation of networked things. Network security can include a 446 number of mechanisms ranging from secure routing to data link 447 layer and network layer security. 449 5 Application security guarantees that only trusted instances of an 450 application running in the IoT can communicate with each other, 451 while illegitimate instances cannot interfere. 453 .......................... 454 : +-----------+: 455 : *+*>|Application|***** 456 : *| +-----------+: * 457 : *| +-----------+: * 458 : *|->| Transport |: * 459 : * _*| +-----------+: * 460 : *| | +-----------+: * 461 : *| |->| Network |: * 462 : *| | +-----------+: * 463 : *| | +-----------+: * *** Bootstrapping 464 : *| +->| L2 |: * ~~~ Application Security 465 : *| +-----------+: * 466 :+--------+ : * 467 :|Security| Configuration: * 468 :|Service | Entity : * 469 :+--------+ : * 470 :........................: * 471 * 472 ......................... * ......................... 473 :+--------+ : * : +--------+: 474 :|Security| Node B : * : Node A |Security|: 475 :|Service | : * : |Service |: 476 :+--------+ : * : +--------+: 477 : | +-----------+: * :+-----------+ |* : 478 : | +->|Application|: ****|Application|<*+* |* : 479 : | | +-----------+: :+-----------+ |* |* : 480 : | | +-----------+: :+-----------+ |* |* : 481 : | |->| Transport |~~~~~~~~~~~~~~~~~~~~~| Transport |<-|* |* : 482 : |__| +-----------+: ................. :+-----------+ |*_|* : 483 : | +-----------+: : +-----------+ : :+-----------+ | * : 484 : |->| Network |: : | Network | : :| Network |<-| : 485 : | +-----------+: : +-----------+ : :+-----------+ | : 486 : | +-----------+: : +-----------+ : :+-----------+ | : 487 : +->| L2 |: : | L2 | : :| L2 |<-+ : 488 : +-----------+: : +-----------+ : :+-----------+ : 489 :.......................: :...............: :.......................: 490 Overview of Security Mechanisms. 492 Figure 3 494 We now discuss an exemplary security architecture relying on a 495 configuration entity for the management of the system with regard to 496 the introduced security aspects (see Figure 2). Inspired by the 497 security framework for routing over low power and lossy network 498 [ID-Tsao], we show an example of security model and illustrates how 499 different security concepts and the lifecycle phases map to the 500 Internet communication stack. Assume a centralized architecture in 501 which a configuration entity stores and manages the identities of the 502 things associated with the system along with their cryptographic 503 keys. During the bootstrapping phase, each thing executes the 504 bootstrapping protocol with the configuration entity, thus obtaining 505 the required device identities and the keying material. The security 506 service on a thing in turn stores the received keying material for 507 the network layer and application security mechanisms for secure 508 communication. Things can then securely communicate with each other 509 during their operational phase by means of the employed network and 510 application security mechanisms. 512 4. State of the Art 514 Nowadays, there exists a multitude of control protocols for the IoT. 515 For BAC systems, the ZigBee standard [ZB], BACNet [BACNET], or DALI 516 [DALI] play key roles. Recent trends, however, focus on an all-IP 517 approach for system control. 519 In this setting, a number of IETF working groups are designing new 520 protocols for resource constrained networks of smart things. The 521 6LoWPAN working group [WG-6LoWPAN] concentrates on the definition of 522 methods and protocols for the efficient transmission and adaptation 523 of IPv6 packets over IEEE 802.15.4 networks [RFC4944]. The CoRE 524 working group [WG-CoRE] provides a framework for resource-oriented 525 applications intended to run on constrained IP network (6LoWPAN). One 526 of its main tasks is the definition of a lightweight version of the 527 HTTP protocol, the Constrained Application Protocol (CoAP) [ID-CoAP], 528 that runs over UDP and enables efficient application-level 529 communication for things. 531 4.1. IP-based Security Solutions 533 In the context of the IP-based IoT solutions, consideration of TCP/IP 534 security protocols is important as these protocols are designed to 535 fit the IP network ideology and technology. While a wide range of 536 specialized as well as general-purpose key exchange and security 537 solutions exist for the Internet domain, we discuss a number of 538 protocols and procedures that have been recently discussed in the 539 context of the above working groups. The considered protocols are 540 IKEv2/IPsec [RFC4306], TLS/SSL [RFC5246], DTLS [RFC5238], HIP 541 [RFC5201][ID-Moskowitz], PANA [RFC5191], and EAP [RFC3748] in this 542 Internet-Draft. Application layer solutions such as SSH [RFC4251] 543 also exist, however, these are currently not considered. Figure 3 544 depicts the relationships between the discussed protocols in the 545 context of the security terminology introduced in Section 3.1. 547 .......................... 548 : +-----------+: 549 : *+*>|Application|***** *** Bootstrapping 550 : *| +-----------+: * ### Application Security 551 : *| +-----------+: * === Network security 552 : *|->| Transport |: * 553 : * _*| +-----------+: * 554 : *| | +-----------+: * 555 : *| |->| Network |: *--> -PANA/EAP 556 : *| | +-----------+: * -HIP 557 : *| | +-----------+: * 558 : *| +->| L2 |: * ## DTLS 559 : *| +-----------+: * ## 560 :+--------+ : * 561 :|Security| Configuration: * [] HIP,IKEv2 562 :|Service | Entity : * [] ESP/AH 563 :+--------+ : * 564 :........................: * 565 * 566 ......................... * ......................... 567 :+--------+ : * : +--------+: 568 :|Security| Node B : * : Node A |Security|: 569 :|Service | : * : |Service |: 570 :+--------+ : Secure * : +--------+: 571 : | +-----------+: routing * :+-----------+ |* : 572 : | +->|Application|: framework ******|Application|<*+* |* : 573 : | | +----##-----+: | :+----##-----+ |* |* : 574 : | | +----##-----+: | :+----##-----+ |* |* : 575 : | |->| Transport |#########|#############| Transport |<-|* |* : 576 : |__| +----[]-----+: ......|.......... :+----[]-----+ |*_|* : 577 : | +====[]=====+=====+===========+=====+====[]=====+ | * : 578 : |->|| Network |: : | Network | : :| Network ||<-| : 579 : | +|----------+: : +-----------+ : :+----------|+ | : 580 : | +|----------+: : +-----------+ : :+----------|+ | : 581 : +->|| L2 |: : | L2 | : :| L2 ||<-+ : 582 : +===========+=====+===========+=====+===========+ : 583 :.......................: :...............: :.......................: 584 Relationships between IP-based security protocols. 586 Figure 4 588 The Internet Key Exchange (IKEv2)/IPsec and the Host Identity 589 protocol (HIP) reside at or above the network layer in the OSI model. 590 Both protocols are able to perform an authenticated key exchange and 591 set up the IPsec transforms for secure payload delivery. Currently, 592 there are also ongoing efforts to create a HIP variant coined Diet 593 HIP [ID-HIP] that takes lossy low-power networks into account at the 594 authentication and key exchange level. 596 Transport Layer Security (TLS) and its datagram-oriented variant DTLS 597 secure transport-layer connections. TLS provides security for TCP 598 and requires a reliable transport, while DTLS secures and uses 599 datagram-oriented protocols such as UDP. Both protocols are 600 intentionally kept similar and share the same ideology and cipher 601 suites. 603 The Extensible Authentication Protocol (EAP) is an authentication 604 framework supporting multiple authentication methods. EAP runs 605 directly over the data link layer and, thus, does not require the 606 deployment of IP. It supports duplicate detection and 607 retransmission, but does not allow for packet fragmentation. The 608 Protocol for Carrying Authentication for Network Access (PANA) is a 609 network-layer transport for EAP that enables network access 610 authentication between clients and the network infrastructure. In 611 EAP terms, PANA is a UDP-based EAP lower layer that runs between the 612 EAP peer and the EAP authenticator. 614 4.2. Wireless Sensor Network Security and Beyond 616 A variety of key agreement and privacy protection protocols that are 617 tailored to IoT scenarios have been introduced in the literature. For 618 instance, random key pre-distribution schemes [PROC-Chan] or more 619 centralized solutions, such as SPINS [JOURNAL-Perrig], have been 620 proposed for key establishment in wireless sensor networks. The 621 ZigBee standard [ZB] for sensor networks defines a security 622 architecture based on an online trust center that is in charge of 623 handling the security relationships within a ZigBee network. Personal 624 privacy in ubiquitous computing has been studied extensively, e.g., 625 in [THESIS-Langheinrich]. Due to resource constraints and the 626 specialization to meet specific requirements, these solutions often 627 implement a collapsed cross layer optimized communication stack 628 (e.g., without task-specific network layers and layered packet 629 headers). Consequently, they cannot directly be adapted to the 630 requirements of the Internet due to the nature of their design. 632 Despite important steps done by, e.g., Gupta et al. [PROC-Gupta], to 633 show the feasibility of an end-to-end standard security architecture 634 for the embedded Internet, the Internet and the IoT domain still do 635 not fit together easily. This is mainly due to the fact that IoT 636 security solutions are often tailored to the specific scenario 637 requirements without considering interoperability with Internet 638 protocols. On the other hand, the direct use of existing Internet 639 security protocols in the IoT might lead to inefficient or insecure 640 operation as we show in our discussion below. 642 5. Challenges for a Secure Internet of Things 644 In this section, we take a closer look at the various security 645 challenges in the operational and technical features of the IoT and 646 then discuss how existing Internet security protocols cope with these 647 technical and conceptual challenges through the lifecycle of a thing. 648 Table 1 summarizes which requirements need to be met in the lifecycle 649 phases as well as the considered protocols. The structure of this 650 section follows the structure of the table. This discussion should 651 neither be understood as a comprehensive evaluation of all protocols, 652 nor can it cover all possible aspects of IoT security. Yet, it aims 653 at showing concrete limitations of existing Internet security 654 protocols in some areas rather than giving an abstract discussion 655 about general properties of the protocols. In this regard, the 656 discussion handles issues that are most important from the authors' 657 perspectives. 659 5.1. Constraints and Heterogeneous Communication 661 Coupling resource constrained networks and the powerful Internet is a 662 challenge because the resulting heterogeneity of both networks 663 complicates protocol design and system operation. In the following 664 we briefly discuss the resource constraints of IoT devices and the 665 consequences for the use of Internet Protocols in the IoT domain. 667 5.1.1. Tight Resource Constraints 669 The IoT is a resource-constrained network that relies on lossy and 670 low-bandwidth channels for communication between small nodes, 671 regarding CPU, memory, and energy budget. These characteristics 672 directly impact the threats to and the design of security protocols 673 for the IoT domain. First, the use of small packets, e.g., IEEE 674 802.15.4 supports 127-byte sized packets at the physical layer, may 675 result in fragmentation of larger packets of security protocols. This 676 may open new attack vectors for state exhaustion DoS attacks, which 677 is especially tragic, e.g., if the fragmentation is caused by large 678 key exchange messages of security protocols. Moreover, packet 679 fragmentation commonly downgrades the overall system performance due 680 to fragment losses and the need for retransmissions. For instance, 681 fate-sharing packet flight as implemented by DTLS might aggravate the 682 resulting performance loss. 684 +--------------------------------------------------------+ 685 | Bootstrapping phase | Operational Phase | 686 +------------+--------------------------------------------------------+ 687 | |Incremental deployment |End-to-End security | 688 |Requirements|Identity and key management |Mobility support | 689 | |Privacy-aware identification|Group membership management| 690 | |Group creation | | 691 +------------+--------------------------------------------------------+ 692 | |IKEv2 |IKEv2/MOBIKE | 693 |Protocols |TLS/DTLS |TLS/DTLS | 694 | |HIP/Diet-HIP |HIP/Diet-HIP | 695 | |PANA/EAP | | 696 +---------------------------------------------------------------------+ 698 Relationships between IP-based security protocols. 700 Figure 5 702 The size and number of messages should be minimized to reduce memory 703 requirements and optimize bandwidth usage. In this context, layered 704 approaches involving a number of protocols might lead to worse 705 performance in resource-constrained devices since they combine the 706 headers of the different protocols. In some settings, protocol 707 negotiation can increase the number of exchanged messages. To 708 improve performance during basic procedures such as, e.g., 709 bootstrapping, it might be a good strategy to perform those 710 procedures at a lower layer. 712 Small CPUs and scarce memory limit the usage of resource-expensive 713 cryptoprimitives such as public-key cryptography as used in most 714 Internet security standards. This is especially true, if the basic 715 cryptoblocks need to be frequently used or the underlying application 716 demands a low delay. 718 Independently from the development in the IoT domain, all discussed 719 security protocols show efforts to reduce the cryptographic cost of 720 the required public-key-based key exchanges and signatures with 721 ECC[RFC5246][RFC5903][ID-Moskowitz][ID-HIP]. Moreover, all protocols 722 have been revised in the last years to enable crypto agility, making 723 cryptographic primitives interchangeable. Diet HIP takes the 724 reduction of the cryptographic load one step further by focusing on 725 cryptographic primitives that are to be expected to be enabled in 726 hardware on IEEE 802.15.4 compliant devices. For example, Diet HIP 727 does not require cryptographic hash functions but uses a CMAC [NIST] 728 based mechanism, which can directly use the AES hardware available in 729 standard sensor platforms. However, these improvements are only a 730 first step in reducing the computation and communication overhead of 731 Internet protocols. The question remains if other approaches can be 732 applied to leverage key agreement in these heavily resource- 733 constrained environments. 735 A further fundamental need refers to the limited energy budget 736 available to IoT nodes. Careful protocol (re)design and usage is 737 required to reduce not only the energy consumption during normal 738 operation, but also under DoS attacks. Since the energy consumption 739 of IoT devices differs from other device classes, judgments on the 740 energy consumption of a particular protocol cannot be made without 741 tailor-made IoT implementations. 743 5.1.2. Denial-of-Service Resistance 745 The tight memory and processing constraints of things naturally 746 alleviate resource exhaustion attacks. Especially in unattended T2T 747 communication, such attacks are difficult to notice before the 748 service becomes unavailable (e.g., because of battery or memory 749 exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and Diet HIP 750 implement return routability checks based on a cookie mechanism to 751 delay the establishment of state at the responding host until the 752 address of the initiating host is verified. The effectiveness of 753 these defenses strongly depends on the routing topology of the 754 network. Return routability checks are particularly effective if 755 hosts cannot receive packets addressed to other hosts and if IP 756 addresses present meaningful information as is the case in today's 757 Internet. However, they are less effective in broadcast media or 758 when attackers can influence the routing and addressing of hosts 759 (e.g., if hosts contribute to the routing infrastructure in ad-hoc 760 networks and meshes). 762 In addition, HIP implements a puzzle mechanism that can force the 763 initiator of a connection (and potential attacker) to solve 764 cryptographic puzzles with variable difficulties. Puzzle-based 765 defense mechanisms are less dependent on the network topology but 766 perform poorly if CPU resources in the network are heterogeneous 767 (e.g., if a powerful Internet host attacks a thing). Increasing the 768 puzzle difficulty under attack conditions can easily lead to 769 situations, where a powerful attacker can still solve the puzzle 770 while weak IoT clients cannot and are excluded from communicating 771 with the victim. Still, puzzle-based approaches are a viable option 772 for sheltering IoT devices against unintended overload caused by 773 misconfigured or malfunctioning things. 775 5.1.3. Protocol Translation and End-to-End Security 777 Even though 6LoWPAN and CoAP progress towards reducing the gap 778 between Internet protocols and the IoT, they do not target protocol 779 specifications that are identical to their Internet pendants due to 780 performance reasons. Hence, more or less subtle differences between 781 IoT protocols and Internet protocols will remain. While these 782 differences can easily be bridged with protocol translators at 783 gateways, they become major obstacles if end-to-end security measures 784 between IoT devices and Internet hosts are used. 786 Cryptographic payload processing applies message authentication codes 787 or encryption to packets. These protection methods render the 788 protected parts of the packets immutable as rewriting is either not 789 possible because a) the relevant information is encrypted and 790 inaccessible to the gateway or b) rewriting integrity-protected parts 791 of the packet would invalidate the end-to-end integrity protection. 793 There are essentially four solutions for this problem: 795 1 Sharing symmetric keys with gateways enables gateways to 796 transform (e.g., de-compress, convert, etc.) packets and re-apply 797 the security measures after transformation. This method abandons 798 end-to-end security and is only applicable to simple scenarios 799 with a rudimentary security model. 801 2 Reusing the Internet wire format in the IoT makes conversion 802 between IoT and Internet protocols unnecessary. However, it 803 leads to poor performance because IoT specific optimizations 804 (e.g., stateful or stateless compression) are not possible. 806 3 Selectively protecting vital and immutable packet parts with a 807 MAC or with encryption requires a careful balance between 808 performance and security. Otherwise, this approach will either 809 result in poor performance (protect as much as possible) or poor 810 security (compress and transform as much as possible). 812 4 Message authentication codes that sustain transformation can be 813 realized by considering the order of transformation and 814 protection (e.g., by creating a signature before compression so 815 that the gateway can decompress the packet without recalculating 816 the signature). This enables IoT specific optimizations but is 817 more complex and may require application-specific transformations 818 before security is applied. Moreover, it cannot be used with 819 encrypted data because the lack of cleartext prevents gateways 820 from transforming packets. 822 To the best of our knowledge, none of the mentioned security 823 protocols provides a fully customizable solution in this problem 824 space. In fact, they usually offer an end-to-end secured connection. 825 An exception is the usage layered approach as might be PANA and EAP. 826 In such a case, this configuration (i) allows for a number of 827 configurations regarding the location of, e.g., the EAP authenticator 828 and authentication server and (ii) the layered architecture might 829 allow for authentication at different places. The drawback of this 830 approach, however, lies in its high signaling traffic volume compared 831 to other approaches. Hence, future work is required to ensure 832 security, performance and interoperability between IoT and the 833 Internet. 835 5.2. Bootstrapping of a Security Domain 837 Creating a security domain from a set of previously unassociated IoT 838 devices is a key operation in the lifecycle of a thing and in the IoT 839 network. In this section, we discuss general forms of network 840 operation, how to communicate a thing's identity and the privacy 841 implications arising from the communication of this identity. 843 5.2.1. Distributed vs. Centralized Architecture and Operation 845 Most things might be required to support both centralized and 846 distributed operation patterns. Distributed thing-to-thing 847 communication might happen on demand, for instance, when two things 848 form an ad-hoc security domain to cooperatively fulfill a certain 849 task. Likewise, nodes may communicate with a backend service located 850 in the Internet without a central security manager. The same nodes 851 may also be part of a centralized architecture with a dedicated node 852 being responsible for the security management for group communication 853 between things in the IoT domain. In today's IoT, most common 854 architectures are fully centralized in the sense that all the 855 security relationships within a segment are handled by a central 856 party. In the ZigBee standard, this entity is the trust center. 857 Current proposals for 6LoWPAN/CoRE identify the 6LoWPAN Border Router 858 (6LBR) as such a device. 860 A centralized architecture allows for central management of devices 861 and keying materials as well as for the backup of cryptographic keys. 862 However, it also imposes some limitations. First, it represents a 863 single point of failure. This is a major drawback, e.g., when key 864 agreement between two devices requires online connectivity to the 865 central node. Second, it limits the possibility to create ad-hoc 866 security domains without dedicated security infrastructure. Third, 867 it codifies a more static world view, where device roles are cast in 868 stone, rather than a more dynamic world view that recognizes that 869 networks and devices, and their roles and ownership, may change over 870 time (e.g., due to device replacement and hand-over of control). 872 Decentralized architectures, on the other hand, allow creating ad-hoc 873 security domains that might not require a single online management 874 entity and are operative in a much more stand-alone manner. The ad- 875 hoc security domains can be added to a centralized architecture at a 876 later point in time, allowing for central or remote management. 878 5.2.2. Bootstrapping a thing's identity and keying materials 880 Bootstrapping refers to the process by which a device is associated 881 to another one, to a network, or to a system. The way it is 882 performed depends upon the architecture: centralized or distributed. 883 It is important to realize that bootstrapping may involve different 884 types of information, ranging from network parameters and information 885 on device capabilities and their presumed functionality, to 886 management information related to, e.g., resource scheduling and 887 trust initialization/management. Furthermore, bootstrapping may 888 occur in stages during the lifecycle of a device and may include 889 provisioning steps already conducted during device manufacturing 890 (e.g., imprinting a unique identifier or a root certificate into a 891 device during chip testing), further steps during module 892 manufacturing (e.g., setting of application-based configurations, 893 such as temperature read-out frequencies and push-thresholds), during 894 personalization (e.g., fine-tuned settings depending on installation 895 context), during hand-over (e.g., transfer of ownership from supplier 896 to user), and, e.g., in preparation of operation in a specific 897 network. In what follows, we focus on bootstrapping of security- 898 related information, since bootstrapping of all other information can 899 be conducted as ordinary secured communications, once a secure and 900 authentic channel between devices has been put in place. 902 In a distributed approach, a Diffie-Hellman type of handshake can 903 allow two peers to agree on a common secret. In general, IKEv2, HIP, 904 TLS, DTLS, can perform key exchanges and the setup of security 905 associations without online connections to a trust center. If we do 906 not consider the resource limitations of things, certificates and 907 certificate chains can be employed to securely communicate 908 capabilities in such a decentralized scenario. HIP and Diet HIP do 909 not directly use certificates for identifying a host, however 910 certificate handling capabilities exist for HIP and the same protocol 911 logic could be used for Diet HIP. It is noteworthy, that Diet HIP 912 does not require a host to implement cryptographic hashes. Hence, 913 some lightweight implementations of Diet HIP might not be able to 914 verify certificates unless a hash function is implemented by the 915 host. 917 In a centralized architecture, preconfigured keys or certificates 918 held by a thing can be used for the distribution of operational keys 919 in a given security domain. A current proposal [ID-OFlynn] refers to 920 the use of PANA for the transport of EAP messages between the PANA 921 client (the joining thing) and the PANA Authentication Agent (PAA), 922 the 6LBR. EAP is thereby used to authenticate the identity of the 923 joining thing. After the successful authentication, the PANA PAA 924 provides the joining thing with fresh network and security 925 parameters. 927 IKEv2, HIP, TLS, and DTLS could be applied as well for the transfer 928 of configuration parameters in a centralized scenario. While HIP's 929 cryptographic secret identifies the thing, the other protocols do not 930 represent primary identifiers but are used instead to bind other 931 identifiers such as the operation keys to the public-key identities. 933 In addition to the protocols, operational aspects during 934 bootstrapping are of key importance as well. Many other standard 935 Internet protocols assume that the identity of a host is either 936 available by using secondary services like certificate authorities or 937 secure name resolution (e.g., DNSsec) or can be provided over a side 938 channel (entering passwords via screen and keyboard). While these 939 assumptions may hold in traditional networks, intermittent 940 connectivity, localized communication, and lack of input methods 941 complicate the situation for the IoT. 943 The order in which the things within a security domain are 944 bootstrapped plays an important role as well. In [RFC6345], the PANA 945 relay element is introduced, relaying PANA messages between a PaC 946 (joining thing) and PAA of a segment [ID-OFlynn]. This approach 947 forces commissioning based on distance to PAA, i.e., things can only 948 be bootstrapped hop-by-hop starting from those closer to the PAA, all 949 things that are 1-hop away are bootstrapped first, followed by those 950 that are 2-hop away, and so on. Such an approach might impose 951 important limitations on actual use cases in which, e.g., an 952 installer without technical background has to roll-out the system. 954 5.2.3. Privacy-aware Identification 956 During the last years, the introduction of RFID tags has raised 957 privacy concerns because anyone might access and track tags. As the 958 IoT involves not only passive devices, but also includes active and 959 sensing devices, the IoT might irrupt even deeper in people's privacy 960 spheres. Thus, IoT protocols should be designed to avoid these 961 privacy threats during bootstrapping and operation where deemed 962 necessary. In H2T and T2T interactions, privacy-aware identifiers 963 might be used to prevent unauthorized user tracking. Similarly, 964 authentication can be used to prove membership of a group without 965 revealing unnecessary individual information. 967 TLS and DTLS provide the option of only authenticating the responding 968 host. This way, the initiating host can stay anonymous. If 969 authentication for the initiating host is required as well, either 970 public-key certificates or authentication via the established 971 encrypted payload channel can be employed. Such a setup allows to 972 only reveal the responder's identity to possible eavesdroppers. 974 HIP and IKEv2 use public-key identities to authenticate the initiator 975 of a connection. These identities could easily be traced if no 976 additional protection were in place. IKEv2 transmits this 977 information in an encrypted packet. Likewise, HIP provides the 978 option to keep the identity of the initiator secret from 979 eavesdroppers by encrypting it with the symmetric key generated 980 during the handshake. However, Diet HIP cannot provide a similar 981 feature because the identity of the initiator simultaneously serves 982 as static Diffie-Hellman key. Note that all discussed solutions 983 could use anonymous public-key identities that change for each 984 communication. However, such identity cycling may require a 985 considerable computational effort for generating new asymmetric key 986 pairs. In addition to the built-in privacy features of the here 987 discussed protocols, a large body of anonymity research for key 988 exchange protocols exists. However, the comparison of these 989 protocols and protocol extensions is out of scope for this work. 991 5.3. Operation 993 After the bootstrapping phase, the system enters the operational 994 phase. During the operational phase, things can relate to the state 995 information created during the bootstrapping phase in order to 996 exchange information securely and in an authenticated fashion. In 997 this section, we discuss aspects of communication patterns and 998 network dynamics during this phase. 1000 5.3.1. End-to-End Security 1002 Providing end-to-end security is of great importance to address and 1003 secure individual T2T or H2T communication within one IoT domain. 1004 Moreover, end-to-end security associations are an important measure 1005 to bridge the gap between the IoT and the Internet. IKEv2 and HIP, 1006 TLS and DTLS provide end-to-end security services including peer 1007 entity authentication, end-to-end encryption and integrity protection 1008 above the network layer and the transport layer respectively. Once 1009 bootstrapped, these functions can be carried out without online 1010 connections to third parties, making the protocols applicable for 1011 decentralized use in the IoT. However, protocol translation by 1012 intermediary nodes may invalidate end-to-end protection measures (see 1013 Section 5.1). 1015 5.3.2. Group Membership and Security 1017 In addition to end-to-end security, group key negotiation is an 1018 important security service for the T2Ts and Ts2T communication 1019 patterns in the IoT as efficient local broadcast and multicast relies 1020 on symmetric group keys. 1022 All discussed protocols only cover unicast communication and 1023 therefore do not focus on group-key establishment. However, the 1024 Diffie-Hellman keys that are used in IKEv2 and HIP could be used for 1025 group Diffie-Hellman key-negotiations. Conceptually, solutions that 1026 provide secure group communication at the network layer (IPsec/IKEv2, 1027 HIP/Diet HIP) may have an advantage regarding the cryptographic 1028 overhead compared to application-focused security solutions (TLS/ 1029 DTLS). This is due to the fact that application-focused solutions 1030 require cryptographic operations per group application, whereas 1031 network layer approaches may allow to share secure group associations 1032 between multiple applications (e.g., for neighbor discovery and 1033 routing or service discovery). Hence, implementing shared features 1034 lower in the communication stack can avoid redundant security 1035 measures. 1037 A number of group key solutions have been developed in the context of 1038 the IETF working group MSEC in the context of the MIKEY architecture 1039 [WG-MSEC][RFC4738]. These are specifically tailored for multicast 1040 and group broadcast applications in the Internet and should also be 1041 considered as candidate solutions for group key agreement in the IoT. 1042 The MIKEY architecture describes a coordinator entity that 1043 disseminates symmetric keys over pair-wise end-to-end secured 1044 channels. However, such a centralized approach may not be applicable 1045 in a distributed environment, where the choice of one or several 1046 coordinators and the management of the group key is not trivial. 1048 5.3.3. Mobility and IP Network Dynamics 1050 It is expected that many things (e.g., wearable sensors, and user 1051 devices) will be mobile in the sense that they are attached to 1052 different networks during the lifetime of a security association. 1053 Built-in mobility signaling can greatly reduce the overhead of the 1054 cryptographic protocols because unnecessary and costly re- 1055 establishments of the session (possibly including handshake and key 1056 agreement) can be avoided. IKEv2 supports host mobility with the 1057 MOBIKE [RFC4555][RFC4621] extension. MOBIKE refrains from applying 1058 heavyweight cryptographic extensions for mobility. However, MOBIKE 1059 mandates the use of IPsec tunnel mode which requires to transmit an 1060 additional IP header in each packet. This additional overhead could 1061 be alleviated by using header compression methods or the Bound End- 1062 to-End Tunnel (BEET) mode [ID-Nikander], a hybrid of tunnel and 1063 transport mode with smaller packet headers. 1065 HIP offers a simple yet effective mobility management by allowing 1066 hosts to signal changes to their associations [RFC5206]. However, 1067 slight adjustments might be necessary to reduce the cryptographic 1068 costs, for example, by making the public-key signatures in the 1069 mobility messages optional. Diet HIP does not define mobility yet 1070 but it is sufficiently similar to HIP to employ the same mechanisms. 1071 TLS and DTLS do not have standards for mobility support, however, 1072 work on DTLS mobility exists in the form of an Internet draft 1073 [ID-Williams]. The specific need for IP-layer mobility mainly 1074 depends on the scenario in which nodes operate. In many cases, 1075 mobility support by means of a mobile gateway may suffice to enable 1076 mobile IoT networks, such as body sensor networks. However, if 1077 individual things change their point of network attachment while 1078 communicating, mobility support may gain importance. 1080 6. Security Suites for the IP-based Internet of Things 1082 Different applications have different security requirements and needs 1083 and, depending on various factors, such as device capability, 1084 availability of network infrastructure, security services needed, 1085 usage, etc., the required security protection may vary from "no 1086 security" to "full-blown security". For example, applications may 1087 have different needs regarding authentication and confidentiality. 1088 While some application might not require any authentication at all, 1089 others might require strong end-to-end authentication. In terms of 1090 secure bootstrapping of keys, some applications might assume the 1091 existence and online availability of a central key-distribution- 1092 center (KDC) within the 6LoWPAN network to distribute and manage 1093 keys; while other applications cannot rely on such a central party or 1094 their availability. 1096 Thus, it is essential to define security profiles to better tailor 1097 security solutions for different applications with the same 1098 characteristics and requirements. This provides a means of grouping 1099 applications into profiles and then defines the minimal required 1100 security primitives to enable and support the security needs of the 1101 profile. The security elements in a security profile can be 1102 classified according to Section 3.1, namely: 1104 1 Security architecture, 1106 2 Security model, 1108 3 Security bootstrapping, 1110 4 Network security, and 1111 5 Application security. 1113 In order to (i) guide the design process by identifying open gaps; 1114 (ii) allow for later interoperability; and (iii) prevent possible 1115 security misconfigurations, this section defines a number of generic 1116 security profiles with different security needs. Each security 1117 profile is identified by: 1119 1 a short description, 1121 2 an exemplary application that might use/require such a security 1122 policy, 1124 3 the security requirements for each of the above security aspects 1125 according to our classification in Section 3.1. 1127 These security profiles can serve to guide the standardization 1128 process, since these explicitly describe the basic functionalities 1129 and protocols required to get different use cases up and running. It 1130 can allow for later interoperability since different manufacturers 1131 can describe the implemented security profile in their products. 1132 Finally, the security profiles can avoid possible security 1133 misconfigurations, since each security profile can be bound to a 1134 different application area so that it can be clearly defined which 1135 security protocols and approaches can be applied where and under 1136 which circumstances. 1138 Note that each of these security profiles aim at summarizing the 1139 required security requirements for different applications and at 1140 providing a set of initial security features. In other words, these 1141 profiles reflect the need for different security configurations, 1142 depending on the threat and trust models of the underlying 1143 applications. In this sense, this section does not provide an 1144 overview of existing protocols as done in previous sections of the 1145 Internet Draft, but it rather explicitly describes what should be in 1146 place to ensure secure system operation. Observe also that this list 1147 of security profiles is not exhaustive and that it should be 1148 considered just as an example not related to existing legal 1149 regulations for any existing application. These security profiles 1150 are summarized in the table below: 1152 +---------------------------------------------------------+ 1153 | Application | Description | 1154 +----------+---------------------------------------------------------+ 1155 |SecProf_0 |No security needs|6LoWPAN/CoAP is used without security | 1156 +----------+-----------------+---------------------------------------+ 1157 |SecProf_1 |Home usage |Enables operation between home things | 1158 | | |without interaction with central device| 1159 +----------+-----------------+---------------------------------------+ 1160 |SecProf_2 |Managed Home |Enables operation between home things. | 1161 | | usage |Interaction with a central and local | 1162 | | |device is possible | 1163 +----------+-----------------+---------------------------------------+ 1164 |SecProf_3 |Industrial usage |Enables operation between things. | 1165 | | |Relies on central (local or backend) | 1166 | | |device for security | 1167 +----------+-----------------+---------------------------------------+ 1168 |SecProf_4 |Advanced |Enables ad-hoc operation between things| 1169 | |Industrial usage |and relies on central device or | 1170 | | |on a collection of control devices | 1171 +----------+-----------------+---------------------------------------+ 1173 Security profiles and application areas. 1175 Figure 6 1177 The classification in the table considers different potential 1178 applications and situations in which their security needs change due 1179 to different operational features (network size, existence of a 1180 central device, connectivity to the Internet, importance of the 1181 exchanged information, etc) or threat model (what are the assets that 1182 an attacker looks for). As already pointed out, this set of 1183 scenarios is exemplary and they should be further discussed based on 1184 a broader consensus. 1186 SecProf_0 is meant for any application that does not require 1187 security. Examples include applications during system development, 1188 system testing, or some very basic applications in which security is 1189 not required at all. 1191 The second security suite (SecProf_1) is catered for environments in 1192 which 6LoWPAN/CoAP can be used to enable communication between things 1193 in an ad-hoc manner and the security requirements are minimal. An 1194 example, is a home application in which two devices should exchange 1195 information and no further connection with other devices (local or 1196 with a backend) is required. In this scenario, value of the 1197 exchanged information is low and that it usually happen in a confined 1198 room, thus, it is possible to have a short period of time during 1199 which initial secrets can be exchanged in the clear. Due to this 1200 fact, there is no requirement to enable devices from different 1201 manufacturers to interoperate in a secure way (keys are just 1202 exchanged). The expected network size of applications using this 1203 profile is expected to be small such that the provision of network 1204 security, e.g., secure routing, is of low importance. 1206 The next security suite (SecProf_2) represents an evolution of 1207 SecProf_1 in which, e.g., home devices, can be managed locally. A 1208 first possibility for the securing domain management refers to the 1209 creation of a centrally managed security domain without any 1210 connectivity to the Internet. The central device used for management 1211 can serve as, e.g., a key distribution center including policies for 1212 key update, storage, etc. The presence of a central device can help 1213 in the management of larger networks. Network security becomes more 1214 relevant in this scenario since the 6LoWPAN/CoAP network can be prone 1215 to Denial of Service attacks (e.g., flooding if L2 is not protected) 1216 or routing attacks. 1218 SecProf_3 considers that a central device is always required for 1219 network management. Example applications of this profile include 1220 building control and automation, sensor networks for industrial use, 1221 environmental monitoring, etc. As before, the network manager can be 1222 located in the 6LoWPAN/CoAP network and handle key management. In 1223 this case, the first association of devices to the network is 1224 required to be done in a secure way. In other words, the threat 1225 model requires measurements to protect against any vulterable period 1226 of time. This step can involve the secure transmission of keying 1227 materials used for network security at different layers. The 1228 information exchanged in the network is considered to be valuable and 1229 it should be protected in the sense of pairwise links. Commands 1230 should be secured and broadcast should be secured with entity 1231 authentication [ID-CoAPMulticast]. Network should be protected from 1232 attacks. A further extension to this use case is to allow for remote 1233 management. A "backend manager" is in charge of managing SW or 1234 information exchanged or collected within the 6LoWPAN/CoAP network. 1235 This requires connection of devices to the Internet over a 6LBR 1236 involving a number of new threats that were not present before. A 1237 list of potential attacks include: resource-exhaustion attacks from 1238 the Internet; amplification attacks; trust issues related a HTTP-CoAP 1239 proxy [ID-proHTTPCoAP], etc. This use case requires protecting the 1240 communication from a device in the backend to a device in the 1241 6LoWPAN/CoAP network, end-to-end. This use case also requires 1242 measures to provide the 6LBR with the capability of dropping fake 1243 requests coming from the Internet. This becomes especially 1244 challenging when the 6LBR is not trusted and access to the exchanged 1245 information is limited; and even more in the case of a HTTP-CoAP 1246 proxy since protocol translation is required. This use case should 1247 take care of protecting information accessed from the backend due to 1248 privacy issues (e.g., information such as type of devices, location, 1249 usage, type and amount of exchanged information, or mobility patterns 1250 can be gathered at the backend threatening the privacy sphere of 1251 users) so that only required information is disclosed. 1253 The last security suite (SecProf_4) essentially represents 1254 interoperability of all the security profiles defined previously. It 1255 considers applications with some additional requirements regarding 1256 operation such as: (i) ad-hoc establishment of security relationships 1257 between things (potentially from different manufacturers) in non- 1258 secure environments or (ii) dynamic roaming of things between 1259 different 6LoWPAN/CoAP security domains. Such operational 1260 requirements pose additional security requirements, e.g., in addition 1261 to secure bootstrapping of a device within a 6LoWPAN/CoAP security 1262 domain and the secure transfer of network operational key, there is a 1263 need to enable inter-domains secure communication to facilitate data 1264 sharing. 1266 The above description illustrates how different applications of 1267 6LoWPAN/CoAP networks involve different security needs. In the 1268 following sections, we summarize the expected security features or 1269 capabilities for each the security profile with regards to "Security 1270 Architecture", "Security Model", "Security Bootstrapping", "Network 1271 Security", and "Application Security". 1273 6.1. Security Architecture 1275 The choice of security architecture has many implications regarding 1276 key management, access control, or security scope. A distributed (or 1277 ad-hoc) architecture means that security relationships between things 1278 are setup on the fly between a number of objects and kept in a 1279 decentralized fashion. A locally centralized security architecture 1280 means that a central device, e.g., the 6LBR, handles the keys for all 1281 the devices in the security domain. Alternatively, a central 1282 security architecture could also refer to the fact that smart objects 1283 are managed from the backend. The security architecture for the 1284 different security profiles is classified as follows. 1286 +---------------------------------------------------------+ 1287 | Description | 1288 +----------+---------------------------------------------------------+ 1289 |SecProf_0 | - | 1290 +----------+---------------------------------------------------------+ 1291 |SecProf_1 | Distributed | 1292 +----------+---------------------------------------------------------+ 1293 |SecProf_2 | Distributed able to move centralized (local) | 1294 +----------+---------------------------------------------------------+ 1295 |SecProf_3 | Centralized (local &/or backend) | 1296 +----------+---------------------------------------------------------+ 1297 |SecProf_4 | Distributed & centralized (local &/or backend) | 1298 +----------+---------------------------------------------------------+ 1300 Security architectures in different security profiles. 1302 Figure 7 1304 In "SecProf_1", management mechanisms for the distributed assignment 1305 and management of keying materials is required. Since this is a very 1306 simple use case, access control to the security domain can be enabled 1307 by means of a common secret known to all devices. In the next 1308 security suite (SecProf_2), a central device can assume key 1309 management responsibilities and handle the access to the network. The 1310 last two security suites (SecProf_3 and SecProf_4) further allow for 1311 the management of devices or some keying materials from the backend. 1313 6.2. Security Model 1315 While some applications might involve very resource-constrained 1316 things such as, e.g., a humidity, pollution sensor, other 1317 applications might target more powerful devices aimed at more exposed 1318 applications. Security parameters such as keying materials, 1319 certificates, etc must be protected in the thing, for example by 1320 means of tamper-resistant hardware. Keys may be shared across a 1321 thing's networking stack to provide authenticity and confidentiality 1322 in each networking layer. This would minimize the number of key 1323 establishment/agreement handshake and incurs less overhead for 1324 constrained thing. While more advance applications may require key 1325 separation at different networking layers, and possibly process 1326 separation and sandboxing to isolate one application from another. In 1327 this sense, this section reflects the fact that different 1328 applications require different sets of security mechanisms. 1330 +---------------------------------------------------------+ 1331 |Description | 1332 +----------+---------------------------------------------------------+ 1333 |SecProf_0 | - | 1334 +----------+---------------------------------------------------------+ 1335 |SecProf_1 |No tamper resistant | 1336 | |Sharing keys between layers | 1337 +----------+---------------------------------------------------------+ 1338 |SecProf_2 |No tamper resistant | 1339 | |Sharing keys between layers | 1340 +----------+---------------------------------------------------------+ 1341 |SecProf_3 |Tamper resistant | 1342 | |Key and process separation | 1343 +----------+---------------------------------------------------------+ 1344 |SecProf_4 |(no) Tamper resistant | 1345 | |Sharing keys between layers/Key and process separation | 1346 | |Sandbox | 1347 +----------+---------------------------------------------------------+ 1349 Thing security models in different security profiles. 1351 Figure 8 1353 6.3. Security Bootstrapping and Management 1355 Bootstrapping refers to the process by which a thing initiates its 1356 life within a security domain and includes the initialization of 1357 secure and/or authentic parameters bound to the thing and at least 1358 one other device in the network. Here, different mechanisms may be 1359 used to achieve confidentiality and/or authenticity of these 1360 parameters, depending on deployment scenario assumptions and the 1361 communication channel(s) used for passing these parameters. The 1362 simplest mechanism for initial set-up of secure and authentic 1363 parameters is via communication in the clear using a physical 1364 interface (USB, wire, chip contact, etc.). Here, one commonly 1365 assumes this communication channel is secure, since eavesdropping 1366 and/or manipulation of this interface would generally require access 1367 to the physical medium and, thereby, to one or both of the devices 1368 themselves. This mechanism was used with the so-called original 1369 "resurrecting duckling" model, as introduced in [PROC-Stajano]. This 1370 technique may also be used securely in wireless, rather than wired, 1371 set-ups, if the prospect of eavesdropping and/or manipulating this 1372 channel are dim (a so-called "location-limited" channel [PROC- 1373 Smetters-04, PROC-Smetters-02]). Examples hereof include the 1374 communication of secret keys in the clear using near field 1375 communication (NFC) - where the physical channel is purported to have 1376 very limited range (roughly 10cm), thereby thwarting eavesdropping by 1377 far-away adversarial devices, and in-the-clear communication during a 1378 small time window (triggered by, e.g., a button-push) - where 1379 eavesdropping is presumed absent during this small time window. With 1380 the use of public-key based techniques, assumptions on the 1381 communication channel can be relaxed even further, since then the 1382 cryptographic technique itself provides for confidentiality of the 1383 channel set-up and the location-limited channel - or use of 1384 certificates - rules out man-in-the-middle attacks, thereby providing 1385 authenticity [PROC-Smetters-02]. The same result can be obtained 1386 using password-based public-key protocols [SPEKE], where authenticity 1387 depends on the (weak) password not being guessed during execution of 1388 the protocol. It should be noted that while most of these techniques 1389 realize a secure and authentic channel for passing parameters, these 1390 generally do not provide for explicit authorization. As an example, 1391 with use of certificate-based public-key based techniques, one may 1392 obtain hard evidence on whom one shares secret and/or authentic 1393 parameters with, but this does not answer the question as to whether 1394 one wishes to share this information at all with this specifically 1395 identified device (the latter usually involves a human-decision 1396 element). Thus, the bootstrapping mechanisms above should generally 1397 be complemented by mechanisms that regulate (security policies for) 1398 authorization. Furthermore, the type of bootstrapping is very 1399 related to the required type of security architecture. Distributed 1400 bootstrapping means that a pair of devices can setup a security 1401 relationship on the fly, without interaction with a central device 1402 elsewhere within the system. In many cases, it is handy to have a 1403 distributed bootstrapping protocol based on existing security 1404 protocols (e.g., DTLS in CoAP) required for other purposes: this 1405 reduces the amount of required software. A centralized boostrapping 1406 protocol is one in which a central device manages the security 1407 relationships within a network. This can happen locally, e.g., 1408 handled by the 6LBR, or remotely, e.g., from a server connected via 1409 the Internet. The security bootstrapping for the different security 1410 profiles is as follows. 1412 +---------------------------------------------------------+ 1413 |Description | 1414 +----------+---------------------------------------------------------+ 1415 |SecProf_0 | - | 1416 +----------+---------------------------------------------------------+ 1417 |SecProf_1 |* Distributed, (e.g., Resurrecting duckling) | 1418 | |* First key distribution happens in the clear | 1419 +----------+---------------------------------------------------------+ 1420 |SecProf_2 |* Distributed, (e.g., Resurrecting duckling ) | 1421 | |* Centralized (local), 6LBR acts as KDC | 1422 | |* First key distribution occurs in the clear, if the KDC | 1423 | | is available, the KDC can manage network access | 1424 +----------+---------------------------------------------------------+ 1425 |SecProf_3 |* 6LBR acts as KDC. It handles node joining, provides | 1426 | | them with keying material from L2 to application layers| 1427 | |* Bootstrapping occurs in a secure way - either in secure| 1428 | | environment or the security mechanisms ensure that | 1429 | | eavesdropping is not possible. | 1430 | |* KDC and backend can implement secure methods for | 1431 | | network access | 1432 +----------+---------------------------------------------------------+ 1433 |SecProf_4 |* As in SecProf_3. | 1434 +----------+---------------------------------------------------------+ 1436 Security boostrapping methods in different security profiles 1438 Figure 9 1440 6.4. Network Security 1442 Network security refers to the mechanisms used to ensure the secure 1443 transport of 6LoWPAN frames. This involves a multitude of issues 1444 ranging from secure discovery, frame authentication, routing 1445 security, detection of replay, secure group communication, etc. 1446 Network security is important to thwart potential attacks such as 1447 denial-of-service (e.g., through message flooding) or routing 1448 attacks. 1450 The Internet Draft [ID-Tsao] presents a very good overview of attacks 1451 and security needs classified according to the confidentiality, 1452 integrity, and availability needs. A potential limitation is that 1453 there exist no differentiation in security between different use 1454 cases and the framework is limited to L3. The security suites 1455 gathered in the present ID aim at solving this by allowing for a more 1456 flexible selection of security needs at L2 and L3. 1458 +---------------------------------------------------------+ 1459 |Description | 1460 +----------+---------------------------------------------------------+ 1461 |SecProf_0 | - | 1462 +----------+---------------------------------------------------------+ 1463 |SecProf_1 |* Network key creating a home security domain at L2 | 1464 | | ensuring authentication and freshness of exchanged data| 1465 | |* Secure multicast does not ensure origin authentication | 1466 | |* No need for secure routing at L3 | 1467 +----------+---------------------------------------------------------+ 1468 |SecProf_2 |* Network key creating a home security domain at L2 | 1469 | | ensuring authentication and freshness of exchanged data| 1470 | |* Secure multicast does not ensure origin authentication | 1471 | |* No need for secure routing at L3 | 1472 +----------+---------------------------------------------------------+ 1473 |SecProf_3 |* Network key creating an industry security domain at L2 | 1474 | | ensuring authentication and freshness of exchanged data| 1475 | |* Secure routing needed (integrity & availability) at L3 | 1476 | | within 6LoWPAN/CoAP | 1477 | |* Secure multicast requires origin authentication | 1478 +----------+---------------------------------------------------------+ 1479 |SecProf_4 |* Network key creating an industry security domain at L2 | 1480 | | ensuring authentication and freshness of exchanged data| 1481 | |* Inter-domain authentication/secure handoff | 1482 | |* Secure routing needed at L3 | 1483 | |* Secure multicast requires origin authentication | 1484 | |* 6LBR (HTTP-CoAP proxy) requires verification of | 1485 | | forwarded messages and messages leaving or entering the| 1486 | | 6LoWPAN/CoAP network. | 1487 +----------+---------------------------------------------------------+ 1489 Network security needs in different security profiles 1491 Figure 10 1493 6.5. Application Security 1495 In the context of 6LoWPAN/CoAP networks, application security refers 1496 firstly to the configuration of DTLS used to protect the exchanged 1497 information. It further refers to the measures required in potential 1498 translation points (e.g., a (HTTP-CoAP) proxy) where information can 1499 be collected and the privacy sphere of users in a given security 1500 domain is endangered. Application security for the different 1501 security profiles is as follows. 1503 +---------------------------------------------------------+ 1504 |Description | 1505 +----------+---------------------------------------------------------+ 1506 |SecProf_0 | - | 1507 +----------+---------------------------------------------------------+ 1508 |SecProf_1 | - | 1509 +----------+---------------------------------------------------------+ 1510 |SecProf_2 |* DTLS is used for end-to-end application security | 1511 | | between management device and things and between things| 1512 | |* DTLS ciphersuites configurable to provide | 1513 | | confidentiality and/or authentication and/or freshness | 1514 | |* Key transport and policies for generation of session | 1515 | | keys are required | 1516 +----------+---------------------------------------------------------+ 1517 |SecProf_3 |* Requirements as in SecProf_2 and | 1518 | |* DTLS is used for end-to-end application security | 1519 | | between management device and things and between things| 1520 | |* Communication between KDC and each thing secured by | 1521 | | pairwise keys | 1522 | |* Group keys for communication in a group distributed | 1523 | | by KDC | 1524 | |* Privacy protection should be provided in translation | 1525 | | points | 1526 +----------+---------------------------------------------------------+ 1527 |SecProf_4 |* Requirements as in SecProf_3 and | 1528 | |* TLS or DTLS can be used to send commands from the | 1529 | | backend to the 6LBR or things in a 6LoWPAN/CoAP network| 1530 | |* End-to-end secure connectivity from backend required | 1531 | |* Secure broadcast in a network from backend required | 1532 +----------+---------------------------------------------------------+ 1534 Application security methods in different security profiles 1536 Figure 11 1538 The first two security profiles do not include any security at the 1539 application layer. The reason is that, in the first case, security 1540 is not provided and, in the second case, it seems reasonable to 1541 provide basic security at L2. In the third security profile 1542 (SecProf_2), DTLS becomes the way of protecting messages at 1543 application layer between things and with the KDC running on a 6LBR. 1544 A key option refers to the capability of easily configuring DTLS to 1545 provide a subset of security services (e.g., some applications do not 1546 require confidentiality) to reduce the impact of security in the 1547 system operation of resource-constrained things. In addition to 1548 basic key management mechanisms running within the KDC, communication 1549 protocols for key transport or key update are required. These 1550 protocols could be based on DTLS. The next security suite 1551 (SecProf_3) requires pairwise keys for communication between things 1552 within the security domain. Furthermore, it can involve the usage of 1553 group keys for group communication. If secure multicast is 1554 implemented, it should provide origin authentication. Finally, 1555 privacy protection should be taken into account to limit access to 1556 valuable information -- such as identifiers, type of collected data, 1557 traffic patterns -- in potential translation points (proxies) or in 1558 the backend. The last security suite (SecProf_4) further extends the 1559 previous set of requirements considering security mechanisms to deal 1560 with translations between TLS and DTLS or for the provision of secure 1561 multicast within a 6LoWPAN/CoAP network from the backend. 1563 7. Next Steps towards a Flexible and Secure Internet of Things 1565 This Internet Draft included an overview of both operational and 1566 security requirements of things in the Internet of Things, discussed 1567 a general threat model and security issues, and introduced a number 1568 of potential security suites fitting different types of IoT 1569 deployments. 1571 We conclude this document by giving our assessment of the current 1572 status of CoAP security with respect to addressing the IP security 1573 challenges we identified, so as to facilitate discussion of next 1574 steps towards workable security design concepts suitable for IP-based 1575 IoT in the broader community. Hereby, we focus on the employed 1576 security protocols and the type of security architecture. 1578 With current status, we refer to the feasibility of realizing secure 1579 deployments with existing CoAP protocols and the practicality of 1580 creating comprehensive security architectures based on those 1581 protocols: 1583 1 DTLS has been defined as the basic building block for protecting 1584 CoAP. At the time it was first proposed, no DTLS implementation 1585 for small, constrained devices was available. In the mean-time, 1586 TinyDTLS [TinyDTLS] has been developed offering the first open- 1587 source implementation of the protocol for small devices. However, 1588 more experience with the protocol is required. In particular, a 1589 performance evaluation and comparison should be made with a well- 1590 defined set of standard node platforms/networks. The results will 1591 help understand the limitations and the benefits of DTLS as well 1592 as to give recommended usage scenarios for this security 1593 protocol. 1595 2 (D)TLS was designed for traditional computer networks and, thus, 1596 some of its features may not be optimal for resource-constrained 1597 networks. This includes: 1599 a Basic DTLS features that are, in our view, not ideal for 1600 resource-constrained devices. For instance, the loss of a 1601 message in-flight requires the retransmission of all messages 1602 in-flight. On the other hand, if all messages in-flight are 1603 transmitted together in a single UDP packet, more resources 1604 are required for handling of large buffers. As pointed out 1605 in [ID-Hartke] , the number of flights in the DTLS handshake 1606 should be reduced, so that a faster setup of a secure channel 1607 can be realized. This would definitely improve the 1608 performance of DTLS significantly. 1610 b Fragmentation of messages due to smaller MTUs in resource- 1611 constrained networks is problematic. This implies that the 1612 node must have a large buffer to store all the fragments and 1613 subsequently perform re-ordering and reassembly in order to 1614 construct the entire DTLS message. The fragmentation of the 1615 handshake messages can, e.g., allow for a very simple method 1616 to carry out a denial of service attack. 1618 c The completion of the DTLS handshake is based on the 1619 successful verification of the Finished message by both 1620 client and server. As the Finished message is computed based 1621 on the hash of all handshake messages in the correct order, 1622 the node must allocate a large buffer to queue all handshake 1623 messages. 1625 d DTLS is thought to offer end-to-end security; however, end- 1626 to-end security also has to be considered from the point of 1627 view of LLN protection, so that end-to-end exchanges can 1628 still be verified and the LLN protected from, e.g., DoS 1629 attacks. 1631 3 Raw public-key in DTLS has been defined as mandatory. However, 1632 memory-optimized public-key libraries still require several KB of 1633 flash and several hundreds of B of RAM. Although Moore's law 1634 still applies and an increase of platform resources is expected, 1635 many IoT scenarios are cost-driven, and in many use cases, the 1636 same work could be done with symmetric-keys. Thus, a key 1637 question is whether the choice for raw public-key is the best 1638 one. In addition, using raw public keys rather than certified 1639 public keys hard codes identities to public keys, thereby 1640 inhibiting public key updates and potentially complicating 1641 initial configuration. 1643 4 Performance of DTLS from a system perspective should be evaluated 1644 involving not just the cryptographic constructs and protocols, 1645 but should also include implementation benchmarks for security 1646 policies, since these may impact overall system performance and 1647 network traffic (an example of this would be policies on the 1648 frequency of key updates, which would necessitate securely 1649 propagating these to all devices in the network). 1651 5 Protection of lower protocol layers is a must in networks of any 1652 size to guarantee resistance against routing attacks such as 1653 flooding or wormhole attacks. The wireless medium that is used 1654 by things to communicate is broadcast in nature and allows 1655 anybody on the right frequency to overhear and even inject 1656 packets at will. Hence, IP-only security solutions may not 1657 suffice in many IoT scenarios. At the time of writing the 1658 document, comprehensive methods are either not in place or have 1659 not been evaluated yet. This limits the deployment of large- 1660 scale systems and makes the secure deployment of large scale 1661 networks rather infeasible. 1663 6 The term "bootstrapping" has been discussed in many occasions. 1664 Although everyone agrees on its importance, finding a good 1665 solution applicable to most use cases is rather challenging. 1666 While usage of existing methods for network access might 1667 partially address bootstrapping in the short-term and facilitate 1668 integration with legacy back-end systems, we feel that, in the 1669 medium-term, this may lead to too large of an overhead and 1670 imposes unnecessary constraints on flexible deployment models. 1671 The bootstrapping protocol should be reusable and light-weight to 1672 fit with small devices. Such a standard bootstrapping protocol 1673 must allow for commissioning of devices from different 1674 manufacturers in both centralized and ad-hoc scenarios and 1675 facilitate transitions of control amongst devices during the 1676 device's and system's lifecycle. Examples of the latter include 1677 scenarios that involve hand-over of control, e.g., from a 1678 configuration device to an operational management console and 1679 involving replacement of such a control device. A key challenge 1680 for secure bootstrapping of a device in a centralized 1681 architecture is that it is currently not feasible to commission a 1682 device when the adjacent devices have not been commissioned yet. 1683 In view of the authors, a light-weight approach is still required 1684 that allows for the bootstrapping of symmetric-keys and of 1685 identities in a certified public-key setting. 1687 7 Secure resource discovery has not been discussed so far. However, 1688 this issue is currently gaining relevance. The IoT, comprising 1689 sensors and actuators, will provide access to many resources to 1690 sense and modify the environment. The usage of DNS presents 1691 well-known security issues, while the application of secure DNS 1692 may not be feasible on small devices. In general, security 1693 issues and solutions related to resource discovery are still 1694 unclear. 1696 8 A security architecture involves, beyond the basic protocols, 1697 many different aspects such as key management and the management 1698 of evolving security responsibilities of entities during the 1699 lifecycle of a thing. This document discussed a number of 1700 security suites and argued that different types of security 1701 architectures are required. A flexible IoT security architecture 1702 should incorporate the properties of a fully centralized 1703 architecture as well as allow devices to be paired together 1704 initially without the need for a trusted third party to create 1705 ad-hoc security domains comprising a number of nodes. These ad- 1706 hoc security domains could then be added later to the Internet 1707 via a single, central node or via a collection of nodes (thus, 1708 facilitating implementation of a centralized or distributed 1709 architecture, respectively). The architecture should also 1710 facilitate scenarios, where an operational network may be 1711 partitioned or merged, and where hand-over of control 1712 functionality of a single device or even of a complete subnetwork 1713 may occur over time (if only to facilitate smooth device repair/ 1714 replacement without the need for a hard "system reboot" or to 1715 realize ownership transfer). This would allow the IoT to 1716 transparently and effortlessly move from an ad-hoc security 1717 domain to a centrally-managed single security domain or a 1718 heterogeneous collection of security domains, and vice-versa. 1719 However, currently, these features still lack validation in real- 1720 life, large-scale deployments. 1722 9 Currently, security solutions are layered, in the sense that each 1723 layer takes care of its own security needs. This approach fits 1724 well with traditional computer networks, but it has some 1725 limitations when resource-constrained devices are involved and 1726 these devices communicate with more powerful devices in the back- 1727 end. We argue that protocols should be more interconnected 1728 across layers to ensure efficiency as resource limitations make 1729 it challenging to secure (and manage) all layers individually. In 1730 this regard, securing only the application layer leaves the 1731 network open to attacks, while security focused only at the 1732 network or link layer might introduce possible inter-application 1733 security threats. Hence, the limited resources of things may 1734 require sharing of keying material and common security mechanisms 1735 between layers. It is required that the data format of the 1736 keying material is standardized to facilitate cross-layer 1737 interaction. Additionally, cross-layer concepts should be 1738 considered for an IoT-driven re-design of Internet security 1739 protocols. 1741 8. Security Considerations 1743 This document reflects upon the requirements and challenges of the 1744 security architectural framework for Internet of Things. 1746 9. IANA Considerations 1748 This document contains no request to IANA. 1750 10. Acknowledgements 1752 We gratefully acknowledge feedback and fruitful discussion with 1753 Tobias Heer and Robert Moskowitz. 1755 11. References 1757 11.1. Informative References 1759 [RFC6568]Kim, E., Kaspar, D., and JP. Vasseur, "Design and 1760 Application Spaces for IPv6 over Low-Power Wireless Personal Area 1761 Networks (6LoWPANs)", RFC 6568, April 2012. 1763 [RFC2818]Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1765 [RFC6345]Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and 1766 A. Yegin, "Protocol for Carrying Authentication for Network Access 1767 (PANA) Relay Element", RFC 6345, August 2011. 1769 [ID-CoAP]Z. Shelby, K. Hartke, C. Bormann, "Constrained Application 1770 Protocol (CoAP)", draft-ietf-core-coap-18, June 2013. 1772 [ID-CoAPMulticast]Rahman, A. and E. Dijk, "Group Communication for 1773 CoAP",draft-ietf-core-groupcomm-12 (work in progress), July 2013. 1775 [ID-Daniel]Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. 1776 Laganier, "IPv6 over Low Power WPAN Security Analysis",Internet Draft 1777 draft-daniel-6lowpan-security-analysis-05, Mar 2011. 1779 [ID-HIP]Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz- 1780 hip-rg-dex-06 (work in progress), May 2012. 1782 [ID-Hartke]Hartke, K. and O. Bergmann, "Datagram Transport Layer 1783 Security in Constrained Environments", draft-hartke-core-codtls-02 1784 (work in progress), July 2012. 1786 [ID-Moskowitz]Moskowitz, R., Heer, T., Jokela, P., and Henderson, T., 1787 "Host Identity Protocol Version 2", draft-ietf-hip-rfc5201-bis-13 1788 (work in progress), Sep 2013. 1790 [ID-Nikander]Nikander, P. and J. Melen, "A Bound End-to-End 1791 Tunnel(BEET) mode for ESP", draft-nikander-esp-beet-mode-09, Aug 1792 2008. 1794 [ID-OFlynn]O'Flynn, C., Sarikaya, B., Ohba, Y., Cao, Z., and R. 1795 Cragie, "Security Bootstrapping of Resource-Constrained Devices", 1796 draft-oflynn-core-bootstrapping-03 (work in progress), Nov 2010. 1798 [ID-Tsao]Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. 1799 Lozano, "A Security Framework for Routing over Low Power and Lossy 1800 Networks", draft-ietf-roll-security-framework-07, Jan 2012. 1802 [ID-Williams]Williams, M. and J. Barrett, "Mobile DTLS", draft- 1803 barrett-mobile-dtls-00, Mar 2009. 1805 [ID-proHTTPCoAP]Castellani, A., Loreto, S., Rahman, A., Fossati, T., 1806 and E. Dijk, "Best practices for HTTP-CoAP mapping implementation", 1807 draft-castellani-core-http-mapping-07(work in progress), Feb 2013. 1809 [RFC3261]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1810 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session 1811 Initiation Protocol", RFC 3261, June 2002. 1813 [RFC3748]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1814 Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, 1815 June 2004. 1817 [RFC3756]Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1818 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 1819 2004. 1821 [RFC3833]Atkins, D. and R. Austein, "Threat Analysis of the Domain 1822 Name System (DNS)", RFC 3833, August 2004. 1824 [RFC4016]Parthasarathy, M., "Protocol for Carrying Authentication and 1825 Network Access (PANA) Threat Analysis and Security Requirements", 1826 RFC 4016, March 2005. 1828 [RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security 1829 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1831 [RFC4251]Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1832 Protocol Architecture", RFC 4251, January 2006. 1834 [RFC4306]Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", 1835 RFC 4306, December 2005. 1837 [RFC4555]Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1838 (MOBIKE)", RFC 4555, June 2006. 1840 [RFC4621]Kivinen, T. and H. Tschofenig, "Design of the IKEv2 Mobility 1841 and Multihoming (MOBIKE) Protocol", RFC 4621, August 2006. 1843 [RFC4738]Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1844 RSA-R: An Additional Mode of Key Distribution in Multimedia Internet 1845 KEYing (MIKEY)", RFC 4738, November 2006. 1847 [RFC4919]Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1848 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, 1849 Assumptions, Problem Statement, and Goals", RFC 4919, August 2007. 1851 [RFC4944]Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1852 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, 1853 September 2007. 1855 [RFC5191]Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and 1856 A. Yegin, "Protocol for Carrying Authentication for Network Access 1857 (PANA)", RFC 5191, May 2008. 1859 [RFC5201]Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 1860 Henderson, "Host Identity Protocol", RFC 5201, April 2008. 1862 [RFC5206]Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, 1863 "End-Host Mobility and Multihoming with the Host Identity Protocol", 1864 RFC 5206, April 2008. 1866 [RFC5238]Phelan, T., "Datagram Transport Layer Security (DTLS) over 1867 the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008. 1869 [RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security 1870 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1872 [RFC5713]Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 1873 Threats and Security Requirements for the Access Node Control 1874 Protocol (ANCP)", RFC 5713, January 2010. 1876 [RFC5903]Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime 1877 (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010. 1879 [AUTO-ID]"AUTO-ID LABS", Web http://www.autoidlabs.org/, Sept 2010. 1881 [BACNET]"BACnet", Web http://www.bacnet.org/, Feb 2011. 1883 [DALI]"DALI", Web http://www.dalibydesign.us/dali.html, Feb 2011. 1885 [JOURNAL-Perrig]Perrig, A., Szewczyk, R., Wen, V., Culler, D., and J. 1886 Tygar, "SPINS: Security protocols for Sensor Networks",Journal 1887 Wireless Networks, Sept 2002. 1889 [NIST]Dworkin, M., "NIST Specification Publication 800-38B", 2005. 1891 [PROC-Chan]Chan, H., Perrig, A., and D. Song, "Random Key 1892 Predistribution Schemes for Sensor Networks", Proceedings IEEE 1893 Symposium on Security and Privacy, 2003. 1895 [PROC-Gupta]Gupta, V., Wurm, M., Zhu, Y., Millard, M., Fung, S., 1896 Gura, N., Eberle, H., and S. Shantz, "Sizzle: A Standards-based End- 1897 to-End Security Architecture for the Embedded Internet", Proceedings 1898 Pervasive Computing and Communications (PerCom), 2005. 1900 [PROC-Smetters-02]Balfanz, D., Smetters, D., Steward, P., and H. Chi 1901 Wong,"Talking To Strangers: Authentication in Ad-Hoc Wireless 1902 Networks", Paper NDSS, 2002. 1904 [PROC-Smetters-04]Balfanz, D., Durfee, G., Grinter, R., Smetters, D., 1905 and P. Steward, "Network-in-a-Box: How to Set Up a Secure Wireless 1906 Network in Under a Minute", Paper USENIX, 2004. 1908 [PROC-Stajano-99]Stajano, F. and R. Anderson, "Resurrecting Duckling 1909 - Security Issues for Adhoc Wireless Networks", 7th International 1910 Workshop Proceedings, Nov 1999. 1912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1913 Requirement Levels", BCP 14, RFC 2119, March 1997. 1915 [THESIS-Langheinrich]Langheinrich, M., "Personal Privacy in 1916 Ubiquitous Computing", PhD Thesis ETH Zurich, 2005. 1918 [TinyDTLS "TinyDTLS", Web http://tinydtls.sourceforge.net/, Feb 2012. 1920 [WG-6LoWPAN]"IETF 6LoWPAN Working Group", Web 1921 http://tools.ietf.org/wg/6lowpan/, Feb 2011. 1923 [WG-CoRE]"IETF Constrained RESTful Environment (CoRE) Working Group", 1924 Web https://datatracker.ietf.org/wg/core/charter/, Feb 2011. 1926 [WG-MSEC]"MSEC Working Group", Web 1927 http://datatracker.ietf.org/wg/msec/. 1929 [ZB]"ZigBee Alliance", Web http://www.zigbee.org/, Feb 2011. 1931 Authors' Addresses 1933 Oscar Garcia-Morchon 1934 Philips Research 1935 High Tech Campus 1936 Eindhoven, 5656 AA 1937 The Netherlands 1939 Email: oscar.garcia@philips.com 1941 Sandeep S. Kumar 1942 Philips Research 1943 High Tech Campus 1944 Eindhoven, 5656 AA 1945 The Netherlands 1947 Email: sandeep.kumar@philips.com 1949 Sye Loong Keoh 1950 University of Glasgow Singapore 1951 Republic PolyTechnic, 9 Woodlands Ave 9 1952 Singapore 838964 1953 SG 1955 Email: SyeLoong.Keoh@glasgow.ac.uk 1957 Rene Hummen 1958 RWTH Aachen University 1959 Templergraben 55 1960 Aachen, 52056 1961 Germany 1963 Email: rene.hummen@cs.rwth-aachen.de 1965 Rene Struik 1966 Struik Security Consultancy 1967 Toronto, 1968 Canada 1970 Email: rstruik.ext@gmail.com