idnits 2.17.1 draft-garcia-core-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (March 7, 2011) is 4798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-04 == 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 ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5206 (Obsoleted by RFC 8046) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE O. Garcia-Morchon 3 Internet-Draft S. Keoh 4 Intended status: Informational S. Kumar 5 Expires: September 8, 2011 Philips Research 6 R. Hummen 7 RWTH Aachen 8 R. Struik 9 Struik Consultancy 10 March 7, 2011 12 Security Considerations in the IP-based Internet of Things 13 draft-garcia-core-security-00 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 September 8, 2011. 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 . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. The Thing Lifecycle and Architectural Considerations . . . . . 4 66 3.1. Security Aspects . . . . . . . . . . . . . . . . . . . . . 5 67 4. State of the Art . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. IP-based Security Solutions . . . . . . . . . . . . . . . 8 69 4.2. Wireless Sensor Network Security and Beyond . . . . . . . 10 70 5. Challenges for a Secure Internet of Things . . . . . . . . . . 11 71 5.1. Constraints and Heterogeneous Communication . . . . . . . 11 72 5.1.1. Tight Resource Constraints . . . . . . . . . . . . . . 11 73 5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . . 13 74 5.1.3. Protocol Translation and End-to-End Security . . . . . 13 75 5.2. Bootstrapping of a Security Domain . . . . . . . . . . . . 15 76 5.2.1. Distributed vs. Centralized Architecture and 77 Operation . . . . . . . . . . . . . . . . . . . . . . 15 78 5.2.2. Bootstrapping a thing's identity and keying 79 materials . . . . . . . . . . . . . . . . . . . . . . 16 80 5.2.3. Privacy-aware Identification . . . . . . . . . . . . . 17 81 5.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 18 82 5.3.1. End-to-End Security . . . . . . . . . . . . . . . . . 18 83 5.3.2. Group Membership and Security . . . . . . . . . . . . 18 84 5.3.3. Mobility and IP Network Dynamics . . . . . . . . . . . 19 85 6. Next Steps towards a Flexible and Secure Internet of Things . 19 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 89 10. Normative References . . . . . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Conventions and Terminology Used in this Document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in "Key words for use in 97 RFCs to Indicate Requirement Levels" [RFC2119]. 99 2. Introduction 101 The Internet of Things (IoT) denotes the interconnection of highly 102 heterogeneous networked entities and networks following a number of 103 communication patterns such as: human-to-human (H2H), human-to-thing 104 (H2T), thing-to-thing (T2T), or thing-to-things (T2Ts). The term IoT 105 was first coined by the Auto-ID center [AUTO-ID] in 1999. Since 106 then, the development of the underlying concepts has ever increased 107 its pace. Nowadays, the IoT presents a strong focus of research with 108 various initiatives working on the (re)design, application, and usage 109 of standard Internet technology in the IoT. 111 The introduction of IPv6 and web services as fundamental building 112 blocks for IoT applications [ID-KIM] promises to bring a number of 113 basic advantages including: (i) a homogeneous protocol ecosystem that 114 allows simple integration with Internet hosts; (ii) simplified 115 development of very different appliances; (iii) an unified interface 116 for applications, removing the need for application-level proxies. 117 Such features greatly simplify the deployment of the envisioned 118 scenarios ranging from building automation to production environments 119 to personal area networks, in which very different things such as a 120 temperature sensor, a luminaire, or an RFID tag might interact with 121 each other, with a human carrying a smart phone, or with backend 122 services. 124 This Internet Draft presents an overview of the security aspects of 125 the envisioned all-IP architecture as well as of the lifecycle of an 126 IoT device, a thing, within this architecture. In particular, we 127 review the most pressing aspects and functionalities that are 128 required for a secure all-IP solution. 130 With this, this Internet-Draft pursues several goals. First, we aim 131 at presenting a comprehensive view of the interactions and 132 relationships between an IoT application and security. Second, we 133 aim at describing challenges for a secure IoTs in the specific 134 context of the lifecycle of a resource-constrained device. The final 135 goal of this draft is to discuss the next steps towards a secure 136 IoTs. 138 The rest of the Internet-Draft is organized as follows. Section 3 139 depicts the lifecycle of a thing and gives general definitions for 140 the main security aspects within the IoT domain. In Section 4, we 141 review existing protocols and work done in the area of security for 142 wireless sensor networks. Section 5 identifies general challenges 143 and needs for an IoT security protocol design and discusses existing 144 protocols and protocol proposals against the identified requirements. 145 Section 6 summarizes concrete steps towards a secure Internet of 146 Things. Section 7 includes final remarks and conclusions. 148 3. The Thing Lifecycle and Architectural Considerations 150 We consider the installation of a Building Automation and Control 151 (BAC) system to illustrate the lifecycle of a thing in a BAC 152 scenario. A BAC system consists of a network of interconnected nodes 153 that perform various functions in the domains of HVAC (Heating, 154 Ventilating, and Air Conditioning), lighting, safety etc. The nodes 155 vary in functionality and a majority of them represent resource 156 constrained devices such as sensors and luminaries. Some devices may 157 also be battery operated or battery-less nodes, demanding for a focus 158 on low energy consumption and on sleeping devices. 160 In our example, the life of a thing starts when it is manufactured. 161 Due to the different application areas (i.e., HVAC, lighting, safety) 162 nodes are tailored to a specific task. It is therefore unlikely that 163 one single manufacturer will create all nodes in a building. Hence, 164 interoperability as well as trust bootstrapping between nodes of 165 different vendors is important. The thing is later installed and 166 commissioned within a network by an installer during the 167 bootstrapping phase. Specifically, the device identity and the 168 secret keys used during normal operation are provided to the device 169 during this phase. Different subcontractors may install different 170 IoT devices for different purposes. Furthermore, the installation 171 and bootstrapping procedures may not be a defined event but may 172 stretch over an extended period of time. After being bootstrapped, 173 the device and the system of things are in operational mode and run 174 the functions of the BAC system. During this operational phase, the 175 device is under the control of the system owner. For devices with 176 lifetimes spanning several years, occasional maintenance cycles may 177 be required. During each maintenance phase, the software on the 178 device can be upgraded or applications running on the device can be 179 reconfigured. The maintenance tasks can thereby be performed either 180 locally or from a backend system. Depending on the operational 181 changes of the device, it may be required to re-bootstrap at the end 182 of a maintenance cycle. The device continues to loop through the 183 operational phase and the eventual maintenance phase until the device 184 is decommissioned at the end of its lifecycle. However, the end-of- 185 life of a device does not necessarily mean that it is defective but 186 rather denotes a need to replace and upgrade the network to next- 187 generation devices in order to provide additional functionality. 188 Therefore the device can be removed and re-commissioned to be used in 189 a different network under a different owner by starting the lifecycle 190 over again. Figure 1 shows the generic lifecycle of a thing. This 191 generic lifecycle is also applicable for IoT scenarios other than BAC 192 systems. 194 At present, BAC systems use legacy building control standards such as 195 BACNet [BACNET] or DALI [DALI] with independent networks for each 196 subsystem (HVAC, lighting, etc.). However, this separation of 197 functionality adds further complexity and costs to the configuration 198 and maintenance of the different networks within the same building. 199 As a result, more recent building control networks employ IP-based 200 standards allowing seamless control over the various nodes with a 201 single management system. While allowing for easier integration, 202 this shift towards IP-based standards results in new requirements 203 regarding the implementation of IP security protocols on constrained 204 devices and the bootstrapping of security keys for devices across 205 multiple manufacturers. 207 _Manufactured _SW update _Decommissioned 208 / / / 209 | _Installed | _ Application | _Removed & 210 | / | / reconfigured | / replaced 211 | | _Commissioned | | | | 212 | | / | | | | _Reownership & 213 | | | _Application | | _Application | | / recommissioned 214 | | | / running | | / running | | | 215 | | | | | | | | | | \\ 216 +##+##+###+#############+##+##+#############+##+##+##############>>> 217 \/ \______________/ \/ \_____________/ \___/ time // 218 / / \ \ \ 219 Bootstrapping / Maintenance & \ Maintenance & 220 / re-bootstrapping \ re-bootstrapping 221 Operational Operational 223 The lifecycle of a thing in the Internet of Things. 225 Figure 1 227 3.1. Security Aspects 229 The term security subsumes a wide range of different concepts. In 230 the first place, it refers to the basic provision of security 231 services including confidentiality, authentication, integrity, 232 authorization, non-repudiation, and availability. These security 233 services can be implemented by means of different cryptographic 234 mechanisms, such as block ciphers, hash functions, or signature 235 algorithms. For each of these mechanisms, a solid key management 236 infrastructure is fundamental to handling the required cryptographic 237 keys. 239 In the context of the IoT, however, the security must not only focus 240 on the required security services, but also how these are realized in 241 the overall system and how the security functionalities are executed. 242 To this end, we use the following terminology to analyze and classify 243 security aspects in the IoT: 245 1 The security architecture refers to the system elements involved 246 in the management of the security relationships between things 247 and the way these security interactions are handled (e.g., 248 centralized or distributed) during the lifecycle of a thing. 250 2 The security model of a node describes how the security 251 parameters, processes, and applications are managed in a thing. 252 This includes aspects such as process separation, secure storage 253 of keying materials, etc. 255 3 Security bootstrapping denotes the process by which a thing 256 securely joins the IoT at a given location and point in time. 257 Bootstrapping includes the authentication and authorization of a 258 device as well as the transfer of security parameters allowing 259 for its trusted operation in a given network. 261 4 Network security describes the mechanisms applied within a 262 network to ensure trusted operation of the IoT. Specifically, it 263 prevents attackers from endangering or modifying the expected 264 operation of networked things. Network security can include a 265 number of mechanisms ranging from secure routing to data link 266 layer and network layer security. 268 5 Application security guarantees that only trusted instances of an 269 application running in the IoT can communicate with each other, 270 while illegitimate instances cannot interfere. 272 .......................... 273 : +-----------+: 274 : *+*>|Application|***** 275 : *| +-----------+: * 276 : *| +-----------+: * 277 : *|->| Transport |: * 278 : * _*| +-----------+: * 279 : *| | +-----------+: * 280 : *| |->| Network |: * 281 : *| | +-----------+: * 282 : *| | +-----------+: * *** Bootstrapping 283 : *| +->| L2 |: * ~~~ Application Security 284 : *| +-----------+: * 285 :+--------+ : * 286 :|Security| Configuration: * 287 :|Service | Entity : * 288 :+--------+ : * 289 :........................: * 290 * 291 ......................... * ......................... 292 :+--------+ : * : +--------+: 293 :|Security| Node B : * : Node A |Security|: 294 :|Service | : * : |Service |: 295 :+--------+ : * : +--------+: 296 : | +-----------+: * :+-----------+ |* : 297 : | +->|Application|: ****|Application|<*+* |* : 298 : | | +-----------+: :+-----------+ |* |* : 299 : | | +-----------+: :+-----------+ |* |* : 300 : | |->| Transport |~~~~~~~~~~~~~~~~~~~~~| Transport |<-|* |* : 301 : |__| +-----------+: ................. :+-----------+ |*_|* : 302 : | +-----------+: : +-----------+ : :+-----------+ | * : 303 : |->| Network |: : | Network | : :| Network |<-| : 304 : | +-----------+: : +-----------+ : :+-----------+ | : 305 : | +-----------+: : +-----------+ : :+-----------+ | : 306 : +->| L2 |: : | L2 | : :| L2 |<-+ : 307 : +-----------+: : +-----------+ : :+-----------+ : 308 :.......................: :...............: :.......................: 309 Overview of Security Mechanisms. 311 Figure 2 313 We now discuss an exemplary security architecture relying on a 314 configuration entity for the management of the system with regard to 315 the introduced security aspects (see Figure 2). Inspired by the 316 security framework for routing over low power and lossy network 317 [ID-Tsao], we show an example of security model and illustrates how 318 different security concepts and the lifecycle phases map to the 319 Internet communication stack. Assume a centralized architecture in 320 which a configuration entity stores and manages the identities of the 321 things associated with the system along with their cryptographic 322 keys. During the bootstrapping phase, each thing executes the 323 bootstrapping protocol with the configuration entity, thus obtaining 324 the required device identities and the keying material. The security 325 service on a thing in turn stores the received keying material for 326 the network layer and application security mechanisms for secure 327 communication. Things can then securely communicate with each other 328 during their operational phase by means of the employed network and 329 application security mechanisms. 331 4. State of the Art 333 Nowadays, there exists a multitude of control protocols for the IoT. 334 For BAC systems, the ZigBee standard [ZB], BACNet [BACNET], or DALI 335 [DALI] play key roles. Recent trends, however, focus on an all-IP 336 approach for system control. 338 In this setting, a number of IETF working groups are designing new 339 protocols for resource constrained networks of smart things. The 340 6LoWPAN working group [WG-6LoWPAN] concentrates on the definition of 341 methods and protocols for the efficient transmission and adaptation 342 of IPv6 packets over IEEE 802.15.4 networks [RFC4944]. The CoRE 343 working group [WG-CoRE] provides a framework for resource-oriented 344 applications intended to run on constrained IP network (6LoWPAN). 345 One of its main tasks is the definition of a lightweight version of 346 the HTTP protocol, the Constrained Application Protocol (CoAP) 347 [ID-CoAP], that runs over UDP and enables efficient application-level 348 communication for things. 350 4.1. IP-based Security Solutions 352 In the context of the IP-based IoT solutions, consideration of TCP/IP 353 security protocols is important as these protocols are designed to 354 fit the IP network ideology and technology. While a wide range of 355 specialized as well as general-purpose key exchange and security 356 solutions exist for the Internet domain, we discuss a number of 357 protocols and procedures that have been recently discussed in the 358 context of the above working groups. The considered protocols are 359 IKEv2/IPsec [RFC5282], TLS/SSL [RFC5878], DTLS [RFC5238], HIP 360 [RFC5201][ID-Moskowitz], PANA [RFC5191], and EAP [RFC3748] in this 361 Internet-Draft. Application layer solutions such as SSH [RFC4251] 362 also exist, however, these are currently not considered. Figure 3 363 depicts the relationships between the discussed protocols in the 364 context of the security terminology introduced in Section 3.1. 366 .......................... 367 : +-----------+: 368 : *+*>|Application|***** *** Bootstrapping 369 : *| +-----------+: * ### Application Security 370 : *| +-----------+: * === Network security 371 : *|->| Transport |: * 372 : * _*| +-----------+: * 373 : *| | +-----------+: * 374 : *| |->| Network |: *--> -PANA/EAP 375 : *| | +-----------+: * -HIP 376 : *| | +-----------+: * 377 : *| +->| L2 |: * ## DTLS 378 : *| +-----------+: * ## 379 :+--------+ : * 380 :|Security| Configuration: * [] HIP,IKEv2 381 :|Service | Entity : * [] ESP/AH 382 :+--------+ : * 383 :........................: * 384 * 385 ......................... * ......................... 386 :+--------+ : * : +--------+: 387 :|Security| Node B : * : Node A |Security|: 388 :|Service | : * : |Service |: 389 :+--------+ : Secure * : +--------+: 390 : | +-----------+: routing * :+-----------+ |* : 391 : | +->|Application|: framework ******|Application|<*+* |* : 392 : | | +----##-----+: | :+----##-----+ |* |* : 393 : | | +----##-----+: | :+----##-----+ |* |* : 394 : | |->| Transport |#########|#############| Transport |<-|* |* : 395 : |__| +----[]-----+: ......|.......... :+----[]-----+ |*_|* : 396 : | +====[]=====+=====+===========+=====+====[]=====+ | * : 397 : |->|| Network |: : | Network | : :| Network ||<-| : 398 : | +|----------+: : +-----------+ : :+----------|+ | : 399 : | +|----------+: : +-----------+ : :+----------|+ | : 400 : +->|| L2 |: : | L2 | : :| L2 ||<-+ : 401 : +===========+=====+===========+=====+===========+ : 402 :.......................: :...............: :.......................: 403 Relationships between IP-based security protocols. 405 Figure 3 407 The Internet Key Exchange (IKEv2)/IPsec and the Host Identity 408 protocol (HIP) reside at or above the network layer in the OSI model. 409 Both protocols are able to perform an authenticated key exchange and 410 set up the IPsec transforms for secure payload delivery. Currently, 411 there are also ongoing efforts to create a HIP variant coined Diet 412 HIP [ID-HIP] that takes lossy low-power networks into account at the 413 authentication and key exchange level. 415 Transport Layer Security (TLS) and its datagram-oriented variant DTLS 416 secure transport-layer connections. TLS provides security for TCP 417 and requires a reliable transport, while DTLS secures and uses 418 datagram-oriented protocols such as UDP. Both protocols are 419 intentionally kept similar and share the same ideology and cipher 420 suites. 422 The Extensible Authentication Protocol (EAP) is an authentication 423 framework supporting multiple authentication methods. EAP runs 424 directly over the data link layer and, thus, does not require the 425 deployment of IP. It supports duplicate detection and 426 retransmission, but does not allow for packet fragmentation. The 427 Protocol for Carrying Authentication for Network Access (PANA) is a 428 network-layer transport for EAP that enables network access 429 authentication between clients and the network infrastructure. In 430 EAP terms, PANA is a UDP-based EAP lower layer that runs between the 431 EAP peer and the EAP authenticator. 433 4.2. Wireless Sensor Network Security and Beyond 435 A variety of key agreement and privacy protection protocols that are 436 tailored to IoT scenarios have been introduced in the literature. 437 For instance, random key pre-distribution schemes [PROC-Chan] or more 438 centralized solutions, such as SPINS [JOURNAL-Perrig], have been 439 proposed for key establishment in wireless sensor networks. The 440 ZigBee standard [ZB] for sensor networks defines a security 441 architecture based on an online trust center that is in charge of 442 handling the security relationships within a ZigBee network. 443 Personal privacy in ubiquitous computing has been studied 444 extensively, e.g., in [THESIS-Langheinrich]. Due to resource 445 constraints and the specialization to meet specific requirements, 446 these solutions often implement a collapsed cross layer optimized 447 communication stack (e.g., without task-specific network layers and 448 layered packet headers). Consequently, they cannot directly be 449 adapted to the requirements of the Internet due to the nature of 450 their design. 452 Despite important steps done by, e.g., Gupta et al. [PROC-Gupta], to 453 show the feasibility of an end-to-end standard security architecture 454 for the embedded Internet, the Internet and the IoT domain still do 455 not fit together easily. This is mainly due to the fact that IoT 456 security solutions are often tailored to the specific scenario 457 requirements without considering interoperability with Internet 458 protocols. On the other hand, the direct use of existing Internet 459 security protocols in the IoT might lead to inefficient or insecure 460 operation as we show in our discussion below. 462 5. Challenges for a Secure Internet of Things 464 In this section, we take a closer look at the various security 465 challenges in the operational and technical features of the IoT and 466 then discuss how existing Internet security protocols cope with these 467 technical and conceptual challenges through the lifecycle of a thing. 468 Table 1 summarizes which requirements need to be met in the lifecycle 469 phases as well as the considered protocols. The structure of this 470 section follows the structure of the table. This discussion should 471 neither be understood as a comprehensive evaluation of all protocols, 472 nor can it cover all possible aspects of IoT security. Yet, it aims 473 at showing concrete limitations of existing Internet security 474 protocols in some areas rather than giving an abstract discussion 475 about general properties of the protocols. In this regard, the 476 discussion handles issues that are most important from the authors' 477 perspectives. 479 5.1. Constraints and Heterogeneous Communication 481 Coupling resource constrained networks and the powerful Internet is a 482 challenge because the resulting heterogeneity of both networks 483 complicates protocol design and system operation. In the following 484 we briefly discuss the resource constraints of IoT devices and the 485 consequences for the use of Internet Protocols in the IoT domain. 487 5.1.1. Tight Resource Constraints 489 The IoT is a resource-constrained network that relies on lossy and 490 low-bandwidth channels for communication between small nodes, 491 regarding CPU, memory, and energy budget. These characteristics 492 directly impact the threats to and the design of security protocols 493 for the IoT domain. First, the use of small packets, e.g., IEEE 494 802.15.4 supports 127-byte sized packets at the physical layer, may 495 result in fragmentation of larger packets of security protocols. 496 This may open new attack vectors for state exhaustion DoS attacks, 497 which is especially tragic, e.g., if the fragmentation is caused by 498 large key exchange messages of security protocols. Moreover, packet 499 fragmentation commonly downgrades the overall system performance due 500 to fragment losses and the need for retransmissions. For instance, 501 fate-sharing packet flight as implemented by DTLS might aggravate the 502 resulting performance loss. 504 +--------------------------------------------------------+ 505 | Bootstrapping phase | Operational Phase | 506 +------------+--------------------------------------------------------+ 507 | |Incremental deployment |End-to-End security | 508 |Requirements|Identity and key management |Mobility support | 509 | |Privacy-aware identification|Group membership management| 510 | |Group creation | | 511 +------------+--------------------------------------------------------+ 512 | |IKEv2 |IKEv2/MOBIKE | 513 |Protocols |TLS/DTLS |TLS/DTLS | 514 | |HIP/Diet-HIP |HIP/Diet-HIP | 515 | |PANA/EAP | | 516 +---------------------------------------------------------------------+ 518 Relationships between IP-based security protocols. 520 Figure 4 522 The size and number of messages should be minimized to reduce memory 523 requirements and optimize bandwidth usage. In this context, layered 524 approaches involving a number of protocols might lead to worse 525 performance in resource-constrained devices since they combine the 526 headers of the different protocols. In some settings, protocol 527 negotiation can increase the number of exchanged messages. To 528 improve performance during basic procedures such as, e.g., 529 bootstrapping, it might be a good strategy to perform those 530 procedures at a lower layer. This involves le 532 Small CPUs and scarce memory limit the usage of resource-expensive 533 cryptoprimitives such as public-key cryptography as used in most 534 Internet security standards. This is especially true, if the basic 535 cryptoblocks need to be frequently used or the underlying application 536 demands a low delay. 538 Independently from the development in the IoT domain, all discussed 539 security protocols show efforts to reduce the cryptographic cost of 540 the required public-key-based key exchanges and signatures with 541 ECC[RFC5246][RFC5903][ID-Moskowitz][ID-HIP]. Moreover, all protocols 542 have been revised in the last years to enable crypto agility, making 543 cryptographic primitives interchangeable. Diet HIP takes the 544 reduction of the cryptographic load one step further by focusing on 545 cryptographic primitives that are to be expected to be enabled in 546 hardware on IEEE 802.15.4 compliant devices. For example, Diet HIP 547 does not require cryptographic hash functions but uses a CMAC [NIST] 548 based mechanism, which can directly use the AES hardware available in 549 standard sensor platforms. However, these improvements are only a 550 first step in reducing the computation and communication overhead of 551 Internet protocols. The question remains if other approaches can be 552 applied to leverage key agreement in these heavily resource- 553 constrained environments. 555 A further fundamental need refers to the limited energy budget 556 available to IoT nodes. Careful protocol (re)design and usage is 557 required to reduce not only the energy consumption during normal 558 operation, but also under DoS attacks. Since the energy consumption 559 of IoT devices differs from other device classes, judgments on the 560 energy consumption of a particular protocol cannot be made without 561 tailor-made IoT implementations. 563 5.1.2. Denial-of-Service Resistance 565 The tight memory and processing constraints of things naturally 566 alleviate resource exhaustion attacks. Especially in unattended T2T 567 communication, such attacks are difficult to notice before the 568 service becomes unavailable (e.g., because of battery or memory 569 exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and Diet HIP 570 implement return routability checks based on a cookie mechanism to 571 delay the establishment of state at the responding host until the 572 address of the initiating host is verified. The effectiveness of 573 these defenses strongly depends on the routing topology of the 574 network. Return routability checks are particularly effective if 575 hosts cannot receive packets addressed to other hosts and if IP 576 addresses present meaningful information as is the case in today's 577 Internet. However, they are less effective in broadcast media or 578 when attackers can influence the routing and addressing of hosts 579 (e.g., if hosts contribute to the routing infrastructure in ad-hoc 580 networks and meshes). 582 In addition, HIP implements a puzzle mechanism that can force the 583 initiator of a connection (and potential attacker) to solve 584 cryptographic puzzles with variable difficulties. Puzzle-based 585 defense mechanisms are less dependent on the network topology but 586 perform poorly if CPU resources in the network are heterogeneous 587 (e.g., if a powerful Internet host attacks a thing). Increasing the 588 puzzle difficulty under attack conditions can easily lead to 589 situations, where a powerful attacker can still solve the puzzle 590 while weak IoT clients cannot and are excluded from communicating 591 with the victim. Still, puzzle-based approaches are a viable option 592 for sheltering IoT devices against unintended overload caused by 593 misconfigured or malfunctioning things. 595 5.1.3. Protocol Translation and End-to-End Security 597 Even though 6LoWPAN and CoAP progress towards reducing the gap 598 between Internet protocols and the IoT, they do not target protocol 599 specifications that are identical to their Internet pendants due to 600 performance reasons. Hence, more or less subtle differences between 601 IoT protocols and Internet protocols will remain. While these 602 differences can easily be bridged with protocol translators at 603 gateways, they become major obstacles if end-to-end security measures 604 between IoT devices and Internet hosts are used. 606 Cryptographic payload processing applies message authentication codes 607 or encryption to packets. These protection methods render the 608 protected parts of the packets immutable as rewriting is either not 609 possible because a) the relevant information is encrypted and 610 inaccessible to the gateway or b) rewriting integrity-protected parts 611 of the packet would invalidate the end-to-end integrity protection. 613 There are essentially four solutions for this problem: 615 1 Sharing symmetric keys with gateways enables gateways to 616 transform (e.g., de-compress, convert, etc.) packets and re-apply 617 the security measures after transformation. This method abandons 618 end-to-end security and is only applicable to simple scenarios 619 with a rudimentary security model. 621 2 Reusing the Internet wire format in the IoT makes conversion 622 between IoT and Internet protocols unnecessary. However, it 623 leads to poor performance because IoT specific optimizations 624 (e.g., stateful or stateless compression) are not possible. 626 3 Selectively protecting vital and immutable packet parts with a 627 MAC or with encryption requires a careful balance between 628 performance and security. Otherwise, this approach will either 629 result in poor performance (protect as much as possible) or poor 630 security (compress and transform as much as possible). 632 4 Message authentication codes that sustain transformation can be 633 realized by considering the order of transformation and 634 protection (e.g., by creating a signature before compression so 635 that the gateway can decompress the packet without recalculating 636 the signature). This enables IoT specific optimizations but is 637 more complex and may require application-specific transformations 638 before security is applied. Moreover, it cannot be used with 639 encrypted data because the lack of cleartext prevents gateways 640 from transforming packets. 642 To the best of our knowledge, none of the mentioned security 643 protocols provides a fully customizable solution in this problem 644 space. In fact, they usually offer an end-to-end secured connection. 645 An exception is the usage layered approach as might be PANA and EAP. 646 In such a case, this configuration (i) allows for a number of 647 configurations regarding the location of, e.g., the EAP authenticator 648 and authentication server and (ii) the layered architecture might 649 allow for authentication at different places. The drawback of this 650 approach, however, lies in its high signaling traffic volume compared 651 to other approaches. Hence, future work is required to ensure 652 security, performance and interoperability between IoT and the 653 Internet. 655 5.2. Bootstrapping of a Security Domain 657 Creating a security domain from a set of previously unassociated IoT 658 devices is a key operation in the lifecycle of a thing and in the IoT 659 network. In this section, we discuss general forms of network 660 operation, how to communicate a thing's identity and the privacy 661 implications arising from the communication of this identity. 663 5.2.1. Distributed vs. Centralized Architecture and Operation 665 Most things might be required to support both centralized and 666 distributed operation patterns. Distributed thing-to-thing 667 communication might happen on demand, for instance, when two things 668 form an ad-hoc security domain to cooperatively fulfill a certain 669 task. Likewise, nodes may communicate with a backend service located 670 in the Internet without a central security manager. The same nodes 671 may also be part of a centralized architecture with a dedicated node 672 being responsible for the security management for group communication 673 between things in the IoT domain. In today's IoT, most common 674 architectures are fully centralized in the sense that all the 675 security relationships within a segment are handled by a central 676 party. In the ZigBee standard, this entity is the trust center. 677 Current proposals for 6LoWPAN/CoRE identify the 6LoWPAN Border Router 678 (6LBR) as such a device. 680 A centralized architecture allows for central management of devices 681 and keying materials as well as for the backup of cryptographic keys. 682 However, it also imposes some limitations. First, it represents a 683 single point of failure. This is a major drawback, e.g., when key 684 agreement between two devices requires online connectivity to the 685 central node. Second, it limits the possibility to create ad-hoc 686 security domains without dedicated security infrastructure. 688 Decentralized architectures, on the other hand, allow creating ad-hoc 689 security domains that might not require an online management entity 690 and are operative in a stand-alone manner. The ad-hoc security 691 domains can be added to a centralized architecture at a later point 692 in time, allowing for central or remote management. 694 5.2.2. Bootstrapping a thing's identity and keying materials 696 Bootstrapping refers to the process by which a device is associated 697 to another one, to a network, or to a system. The way it is 698 performed depends upon the architecture: centralized or distributed. 700 In a distributed approach, a Diffie-Hellman type of handshake can 701 allow two peers to agree on a common secret. In general, IKEv2, HIP, 702 TLS, DTLS, can perform key exchanges and the setup of security 703 associations without online connections to a trust center. If we do 704 not consider the resource limitations of things, certificates and 705 certificate chains can be employed to securely communicate 706 capabilities in such a decentralized scenario. HIP and Diet HIP do 707 not directly use certificates for identifying a host, however 708 certificate handling capabilities exist for HIP and the same protocol 709 logic could be used for Diet HIP. It is noteworthy, that Diet HIP 710 does not require a host to implement cryptographic hashes. Hence, 711 some lightweight implementations of Diet HIP might not be able to 712 verify certificates unless a hash function is implemented by the 713 host. 715 In a centralized architecture, preconfigured keys or certificates 716 held by a thing can be used for the distribution of operational keys 717 in a given security domain. A current proposal [ID-O'Flynn] refers 718 to the use of PANA for the transport of EAP messages between the PANA 719 client (the joining thing) and the PANA Authentication Agent (PAA), 720 the 6LBR. EAP is thereby used to authenticate the identity of the 721 joining thing. After the successful authentication, the PANA PAA 722 provides the joining thing with fresh network and security 723 parameters. 725 IKEv2, HIP, TLS, and DTLS could be applied as well for the transfer 726 of configuration parameters in a centralized scenario. While HIP's 727 cryptographic secret identifies the thing, the other protocols do not 728 represent primary identifiers but are used instead to bind other 729 identifiers such as the operation keys to the public-key identities. 731 In addition to the protocols, operational aspects during 732 bootstrapping are of key importance as well. Many other standard 733 Internet protocols assume that the identity of a host is either 734 available by using secondary services like certificate authorities or 735 secure name resolution (e.g., DNSsec) or can be provided over a side 736 channel (entering passwords via screen and keyboard). While these 737 assumptions may hold in traditional networks, intermittent 738 connectivity, localized communication, and lack of input methods 739 complicate the situation for the IoT. 741 The order in which the things within a security domain are 742 bootstrapped plays an important role as well. In [ID-Duffy], the 743 PANA relay element is introduced, relaying PANA messages between a 744 PaC (joining thing) and PAA of a segment [ID-O'Flynn]. This approach 745 forces commissioning based on distance to PAA, i.e., things can only 746 be bootstrapped hop-by-hop starting from those closer to the PAA, all 747 things that are 1-hop away are bootstrapped first, followed by those 748 that are 2-hop away, and so on. Such an approach might impose 749 important limitations on actual use cases in which, e.g., an 750 installer without technical background has to roll-out the system. 752 5.2.3. Privacy-aware Identification 754 During the last years, the introduction of RFID tags has raised 755 privacy concerns because anyone might access and track tags. As the 756 IoT involves not only passive devices, but also includes active and 757 sensing devices, the IoT might irrupt even deeper in people's privacy 758 spheres. Thus, IoT protocols should be designed to avoid these 759 privacy threats during bootstrapping and operation where deemed 760 necessary. In H2T and T2T interactions, privacy-aware identifiers 761 might be used to prevent unauthorized user tracking. Similarly, 762 authentication can be used to prove membership of a group without 763 revealing unnecessary individual information. 765 TLS and DTLS provide the option of only authenticating the responding 766 host. This way, the initiating host can stay anonymous. If 767 authentication for the initiating host is required as well, either 768 public-key certificates or authentication via the established 769 encrypted payload channel can be employed. Such a setup allows to 770 only reveal the responder's identity to possible eavesdroppers. 772 HIP and IKEv2 use public-key identities to authenticate the initiator 773 of a connection. These identities could easily be traced if no 774 additional protection were in place. IKEv2 transmits this 775 information in an encrypted packet. Likewise, HIP provides the 776 option to keep the identity of the initiator secret from 777 eavesdroppers by encrypting it with the symmetric key generated 778 during the handshake. However, Diet HIP cannot provide a similar 779 feature because the identity of the initiator simultaneously serves 780 as static Diffie-Hellman key. Note that all discussed solutions 781 could use anonymous public-key identities that change for each 782 communication. However, such identity cycling may require a 783 considerable computational effort for generating new asymmetric key 784 pairs. In addition to the built-in privacy features of the here 785 discussed protocols, a large body of anonymity research for key 786 exchange protocols exists. However, the comparison of these 787 protocols and protocol extensions is out of scope for this work. 789 5.3. Operation 791 After the bootstrapping phase, the system enters the operational 792 phase. During the operational phase, things can relate to the state 793 information created during the bootstrapping phase in order to 794 exchange information securely and in an authenticated fashion. In 795 this section, we discuss aspects of communication patterns and 796 network dynamics during this phase. 798 5.3.1. End-to-End Security 800 Providing end-to-end security is of great importance to address and 801 secure individual T2T or H2T communication within one IoT domain. 802 Moreover, end-to-end security associations are an important measure 803 to bridge the gap between the IoT and the Internet. IKEv2 and HIP, 804 TLS and DTLS provide end-to end security services including peer 805 entity authentication, end-to-end encryption and integrity protection 806 above the network layer and the transport layer respectively. Once 807 bootstrapped, these functions can be carried out without online 808 connections to third parties, making the protocols applicable for 809 decentralized use in the IoT. However, protocol translation by 810 intermediary nodes may invalidate end-to-end protection measures (see 811 Section 5.1). 813 5.3.2. Group Membership and Security 815 In addition to end-to-end security, group key negotiation is an 816 important security service for the T2Ts and Ts2T communication 817 patterns in the IoT as efficient local broadcast and multicast relies 818 on symmetric group keys. 820 All discussed protocols only cover unicast communication and 821 therefore do not focus on group-key establishment. However, the 822 Diffie-Hellman keys that are used in IKEv2 and HIP could be used for 823 group Diffie-Hellman key-negotiations. Conceptually, solutions that 824 provide secure group communication at the network layer (IPsec/IKEv2, 825 HIP/Diet HIP) may have an advantage regarding the cryptographic 826 overhead compared to application-focused security solutions (TLS/ 827 DTLS). This is due to the fact that application-focused solutions 828 require cryptographic operations per group application, whereas 829 network layer approaches may allow to share secure group associations 830 between multiple applications (e.g., for neighbor discovery and 831 routing or service discovery). Hence, implementing shared features 832 lower in the communication stack can avoid redundant security 833 measures. 835 A number of group key solutions have been developed in the context of 836 the IETF working group MSEC in the context of the MIKEY architecture 838 [WG-MSEC][RFC4738]. These are specifically tailored for multicast 839 and group broadcast applications in the Internet and should also be 840 considered as candidate solutions for group key agreement in the IoT. 841 The MIKEY architecture describes a coordinator entity that 842 disseminates symmetric keys over pair-wise end-to-end secured 843 channels. However, such a centralized approach may not be applicable 844 in a distributed environment, where the choice of one or several 845 coordinators and the management of the group key is not trivial. 847 5.3.3. Mobility and IP Network Dynamics 849 It is expected that many things (e.g., wearable sensors, and user 850 devices) will be mobile in the sense that they are attached to 851 different networks during the lifetime of a security association. 852 Built-in mobility signaling can greatly reduce the overhead of the 853 cryptographic protocols because unnecessary and costly re- 854 establishments of the session (possibly including handshake and key 855 agreement) can be avoided. IKEv2 supports host mobility with the 856 MOBIKE [RFC4555][RFC4621] extension. MOBIKE refrains from applying 857 heavyweight cryptographic extensions for mobility. However, MOBIKE 858 mandates the use of IPsec tunnel mode which requires to transmit an 859 additional IP header in each packet. This additional overhead could 860 be alleviated by using header compression methods or the Bound End- 861 to-End Tunnel (BEET) mode [ID-Nikander], a hybrid of tunnel and 862 transport mode with smaller packet headers. 864 HIP offers a simple yet effective mobility management by allowing 865 hosts to signal changes to their associations [RFC5206]. However, 866 slight adjustments might be necessary to reduce the cryptographic 867 costs, for example, by making the public-key signatures in the 868 mobility messages optional. Diet HIP does not define mobility yet 869 but it is sufficiently similar to HIP to employ the same mechanisms. 870 TLS and DTLS do not have standards for mobility support, however, 871 work on DTLS mobility exists in the form of an Internet draft 872 [ID-Williams]. The specific need for IP-layer mobility mainly 873 depends on the scenario in which nodes operate. In many cases, 874 mobility support by means of a mobile gateway may suffice to enable 875 mobile IoT networks, such as body sensor networks. However, if 876 individual things change their point of network attachment while 877 communicating, mobility support may gain importance. 879 6. Next Steps towards a Flexible and Secure Internet of Things 881 Based on the discussions on the lifecycle of a thing and the existing 882 challenges for the Internet of Things, it is important to define 883 specific steps towards a feasibly secure IoTs, with special emphasis 884 on the security protocols. However, it is noteworthy that this goes 885 beyond the protection of a specific protocol such as CoAP or any 886 particular protocol that will be used. The aim is to put together 887 different security aspects of IoT, making clear how the operational, 888 architectural, and technical aspects impact the protocol design and 889 choices. Next, we list the most important topics towards achieving 890 this goal. 892 1 Performance assessment of the existing IP-security protocols on 893 resource constrained devices. From the best of our knowledge, 894 the implementation feasibility of existing protocols on 895 constrained devices (e.g., 8-bit CPU and limited RAM budget) has 896 not been fully assessed so far. Their performance should be 897 analyzed in terms of CPU and communication overhead, energy 898 consumption, and memory requirements for a better understanding 899 of the impact of security on the rest of the protocols and 900 systems. By having a number of standard node platforms as the 901 reference for performance benchmarking, this would serve as a 902 good basis for designing a suitable security architecture for 903 IoT. 905 2 Definition of a flexible architecture matching the different 906 operational scenarios during the lifecycle of a thing. In 907 addition to a centralized architecture, devices can be paired 908 together initially without the need for a trusted third party to 909 create ad-hoc security domains comprising a number of nodes. 910 These ad-hoc security domains should be able to be added later to 911 the Internet when a central node is available. Thus, the IoT can 912 transparently and effortlessly move from an ad-hoc security 913 domain to a centrally-managed security domain and the other way 914 around. 916 3 Definition of a minimal and standard security suite (protocols 917 and keying materials) reusable for different phases in the 918 lifecycle of a thing and across layers ensuring system 919 interoperability. The link layer, the network layer, as well as 920 the application layer have distinct security requirements and 921 communication patterns. For small devices, resource limitations 922 make it challenging to secure all layers individually. Securing 923 only the application layer leaves the network open to attacks, 924 while security focused only at the network and link layer might 925 introduce possible inter-application security threats. Hence, 926 the limited resources of things may require sharing of keying 927 material and common security mechanisms between layers. It is 928 required that the data format of the keying material is 929 standardized to facilitate this. Such cross layer concepts 930 should be considered for an IoT-driven redesign of Internet 931 security protocols. 933 4 Definition of a standard lightweight bootstrapping protocol for 934 commissioning of devices. A key challenge for secure 935 bootstrapping of a device in a centralized architecture is that 936 it is currently not feasible to commission a device when the 937 adjacent devices have not been commissioned yet. On the other 938 hand, such a standard bootstrapping protocol must also allow for 939 commissioning of devices from different manufacturers in both 940 centralized and ad-hoc scenarios. The bootstrapping protocol 941 should be reusable and lightweight to fit into small devices. 943 5 Definition of protocols with low fragmentation needs and 944 protection against DoS attacks. Many standard Internet protocols 945 have been designed for relatively big MTUs. For instance, EAP 946 assumes a minimum MTU in lower layers of 1020 B. However, IEEE 947 802.15.4 networks have physical packets of 127 B. Long messages 948 in security handshakes and protocols should be avoided to 949 prevent: (i) attackers from launching DoS attacks; (ii) high 950 resource needs regarding bandwidth or code. 952 7. Security Considerations 954 This document reflects upon the requirements and challenges of the 955 security architectural framework for Internet of Things. 957 8. IANA Considerations 959 This document contains no request to IANA. 961 9. Acknowledgements 963 We gratefully acknowledge feedback and fruitful discussion with 964 Tobias Heer and Robert Moskowitz. 966 10. Normative References 968 [AUTO-ID] "AUTO-ID LABS", Web http://www.autoidlabs.org/, Sept 2010. 970 [BACNET] "BACnet", Web http://www.bacnet.org/, Feb 2011. 972 [DALI] "DALI", Web http://www.dalibydesign.us/dali.html, 973 Feb 2011. 975 [ID-CoAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 976 "Constrained Application Protocol (CoAP)", 977 draft-ietf-core-coap-04 (work in progress), Jan 2011. 979 [ID-Duffy] 980 Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 981 Yegin, "Protocol for Carrying Authentication for Network 982 Access (PANA) Relay Element", draft-ohba-pana-relay-03 983 (work in progress), Nov 2010. 985 [ID-HIP] Moskowitz, R., "HIP Diet EXchange (DEX)", 986 draft-moskowitz-hip-rg-dex-02 (work in progress), 987 Jul 2010. 989 [ID-KIM] Kim, E., Kaspar, D., and J. Vasseur, "Design and 990 Application Spaces for 6LoWPANs", 991 draft-ietf-6lowpan-usecases-09 (work in progress), 992 January 2011. 994 [ID-Moskowitz] 995 Moskowitz, R., Jokela, P., Henderson, T., and T. Heer, 996 "Host Identity Protocol Version 2", 997 draft-ietf-hip-rfc5201-bis-03 (work in progress), 998 Oct 2010. 1000 [ID-Nikander] 1001 Nikander, P. and J. Melen, "A Bound End-to-End Tunnel 1002 (BEET) mode for ESP", Internet 1003 Draft draft-nikander-esp-beet-mode-09, Feb 2009. 1005 [ID-O'Flynn] 1006 O'Flynn, C., Sarikaya, B., Ohba, Y., Cao, Z., and R. 1007 Cragie, "Security Bootstrapping of Resource-Constrained 1008 Devices", draft-oflynn-core-bootstrapping-03 (work in 1009 progress), Nov 2010. 1011 [ID-Tsao] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. 1012 Lozano, "A Security Framework for Routing over Low Power 1013 and Lossy Networks", Internet 1014 Draft draft-ietf-roll-security-framework-04, Jan 2011. 1016 [ID-Williams] 1017 Williams, M. and J. Barrett, "Mobile DTLS", Internet 1018 Draft draft-barrett-mobile-dtls-00, Sept 2009. 1020 [JOURNAL-Perrig] 1021 Perrig, A., Szewczyk, R., Wen, V., Culler, D., and J. 1022 Tygar, "SPINS: Security protocols for Sensor Networks", 1023 Journal Wireless Networks, Sept 2002. 1025 [NIST] Dworkin, M., "NIST Specification Publication 800-38B", 1026 2005. 1028 [PROC-Chan] 1029 Chan, H., Perrig, A., and D. Song, "Random Key 1030 Predistribution Schemes for Sensor Networks", 1031 Proceedings IEEE Symposium on Security and Privacy, 2003. 1033 [PROC-Gupta] 1034 Gupta, V., Wurm, M., Zhu, Y., Millard, M., Fung, S., Gura, 1035 N., Eberle, H., and S. Shantz, "Sizzle: A Standards-based 1036 End-to-End Security Architecture for the Embedded 1037 Internet", Proceedings Pervasive Computing and 1038 Communications (PerCom), 2005. 1040 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1041 Requirement Levels", BCP 14, RFC 2119, March 1997. 1043 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1044 Levkowetz, "Extensible Authentication Protocol (EAP)", 1045 RFC 3748, June 2004. 1047 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1048 Protocol Architecture", RFC 4251, Jan 2006. 1050 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1051 (MOBIKE)", RFC 4555, Jun 2006. 1053 [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 1054 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, 1055 Aug 2006. 1057 [RFC4738] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1058 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 4738, 1059 Aug 2004. 1061 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1062 "Transmission of IPv6 Packets over IEEE 802.15.4 1063 Networks", RFC 4944, Sept 2007. 1065 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1066 Yegin, "Protocol for Carrying Authentication for Network 1067 Access (PANA)", RFC 5191, May 2008. 1069 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1070 "Host Identity Protocol", RFC 5201, Apr 2008. 1072 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 1073 Host Mobility and Multi-homing with the Host Identity 1074 Protocol", RFC 5206, Aug 2006. 1076 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1077 the Datagram Congestion Control Protocol (DCCP)", 1078 RFC 5238, May 2008. 1080 [RFC5246] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1081 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1082 for Transport Layer Security (TLS)", RFC 5246, May 2006. 1084 [RFC5282] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1085 RFC 5282, Dec 2005. 1087 [RFC5878] Kaufman, C., "The Transport Layer Security (TLS) Protocol 1088 version 1.2", RFC 5878, Aug 2008. 1090 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups Modulo a 1091 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 1092 June 2010. 1094 [THESIS-Langheinrich] 1095 Langheinrich, M., "Personal Privacy in Ubiquitous 1096 Computing", PhD Thesis ETH Zurich, 2005. 1098 [WG-6LoWPAN] 1099 "IETF 6LoWPAN Working Group", 1100 Web http://tools.ietf.org/wg/6lowpan/, Feb 2011. 1102 [WG-CoRE] "IETF Constrained RESTful Environment (CoRE) Working 1103 Group", Web https://datatracker.ietf.org/wg/core/charter/, 1104 Feb 2011. 1106 [WG-MSEC] "MSEC Working Group", 1107 Web http://datatracker.ietf.org/wg/msec/. 1109 [ZB] "ZigBee Alliance", Web http://www.zigbee.org/, Feb 2011. 1111 Authors' Addresses 1113 Oscar Garcia-Morchon 1114 Philips Research 1115 High Tech Campus 1116 Eindhoven, 5656 AA 1117 The Netherlands 1119 Email: oscar.garcia@philips.com 1121 Sye Loong Keoh 1122 Philips Research 1123 High Tech Campus 1124 Eindhoven, 5656 AA 1125 The Netherlands 1127 Email: sye.loong.keoh@philips.com 1129 Sandeep S. Kumar 1130 Philips Research 1131 High Tech Campus 1132 Eindhoven, 5656 AA 1133 The Netherlands 1135 Email: sandeep.kumar@philips.com 1137 Rene Hummen 1138 RWTH Aachen University 1139 Templergraben 55 1140 Aachen, 52056 1141 Germany 1143 Email: rene.hummen@cs.rwth-aachen.de 1145 Rene Struik 1146 Struik Security Consultancy 1147 Toronto, 1148 Canada 1150 Email: rstruik.ext@gmail.com