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