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