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