idnits 2.17.1 draft-he-6lo-analysis-iot-sbootstrapping-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 9, 2015) is 3336 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4861' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC4919' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC5216' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'RFC5487' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC7251' is defined on line 696, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-he-iot-security-bootstrapping-00 == Outdated reference: A later version (-02) exists of draft-pritikin-anima-bootstrapping-keyinfra-01 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. He, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational B. Sarikaya, Ed. 5 Expires: September 10, 2015 Huawei USA 6 March 9, 2015 8 IoT Security Bootstrapping: Survey and Design Considerations 9 draft-he-6lo-analysis-iot-sbootstrapping-00 11 Abstract 13 This document presents the importance of security bootstrapping for 14 IoT networks, analyzes the state-of-the-art works in standard 15 organizations and discusses what should be considered when designing 16 the secure bootstrapping mechanism. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 10, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Analysis of Related State-of-the-art Works . . . . . . . . . 3 55 3.1. Security bootstrapping . . . . . . . . . . . . . . . . . 3 56 3.1.1. Authentication framework . . . . . . . . . . . . . . 4 57 3.1.2. Credential Material and Architecture . . . . . . . . 7 58 3.2. Higher Layer Protocol Use After/During Bootstrapping . . 9 59 4. Role of IoT Security Bootstrapping . . . . . . . . . . . . . 10 60 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 61 5.1. Able to clearly define security dependency and trust 62 domains . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 5.2. Cross-layer design . . . . . . . . . . . . . . . . . . . 12 64 5.3. Reduce human interaction to the minimum . . . . . . . . 12 65 5.4. Able to resist attacks . . . . . . . . . . . . . . . . . 13 66 5.5. Low computation cost and communication overhead . . . . . 13 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 8.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 An Internet of Things (IoT) network is composed of connected things 77 that cooperate together to accomplish tasks such as smart buildings, 78 smart environment monitoring system, intelligent transport system, 79 etc. The size of IoT varies from tens to thousands depending on the 80 application, and things in an IoT network might be produced by 81 different vendors and they are normally heterogeneous with various 82 constraints e.g. power supply, communication capability, CPU and 83 memory. 85 IEEE 802.15.4 specifies the physical layer and media access control 86 for low-rate wireless personal area networks (LR-WPANs). It is 87 widely used in wireless sensor networks nowadays and is foreseen as 88 the most used lower layer protocol for low rate IoT networks with 89 resource constrained devices. In IETF, 6LoWPAN (concluded) developed 90 RFC 4944 [RFC4944] to describe how to transmit IPv6 packets over 91 802.15.4, and support mesh routing in LR-WPANs. 6lo defines generic 92 IPv6 packet header compression method [RFC7400] for LR-WPANs. 6tisch 93 tries to build adaptation protocols for IEEE 802.15.4e specification. 94 Roll develops routing protocol RPL [RFC6550] for IPv6 based low power 95 and lossy networks. Note that IEEE 802.15.4 can be applied to mobile 96 nodes, routing protocols such as AODV [RFC3561], DSL [RFC4728], OLSR 97 [RFC3626] by MANET group are also widely used. CoAP [RFC7252] from 98 CoRE defines a UDP based web transfer protocol for machine- to- 99 machine (M2M) applications such as smart energy and building 100 automation. 102 The above mentioned protocols provide different selections of IoT 103 protocol stacks to fulfill specific tasks based on IEEE 802.15.4. At 104 the start-up phase of a network or after the provisioned 105 communications have failed, bootstrapping is typically required to 106 configure nodes at all layers, including anything from link-layer 107 information (i.e., wireless channels, link-layer encryption keys) to 108 application-layer information (i.e., network names, application 109 encryption keys). It can be realized either manually via user 110 interface or automatically via interaction between nodes. 112 Traditional bootstrapping approaches tend to impose configuration 113 burdens upon users. For example, users need to follow a series of 114 instruction steps for configuration. Configuring IoT devices becomes 115 more complicated since they don't always provide user interface to 116 input all necessary information, and the scale of the IoT network can 117 be large, dynamic or error prone. As a result, human intervention is 118 expensive and not efficient in those situations. This motivates the 119 need for self-organization and automatic self-bootstrapping in IoT. 120 Enabling a plug & play framework not only reduces human efforts in 121 configuring IoT but also improve the scalability and flexibility. 122 This draft presents a survey of the state-of-the-art works on 123 bootstrapping/networking in IETF, ZigBee Alliance, IEEE and Thread 124 group, and the design considerations for security bootstrapping are 125 derived. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 [RFC2119]. 134 3. Analysis of Related State-of-the-art Works 136 Bootstrapping is required at all layers, where different conditions 137 and information should be transferred for different protocols. This 138 section provides analysis on the existing bootstrapping works in 139 standard organizations and summarizes the concerns. 141 3.1. Security bootstrapping 143 Security bootstrapping includes the authentication of devices to 144 establish trust relationships in a network, as well as transferring 145 security parameters and keying materials. Security bootstrapping is 146 believed as the fundamental part of bootstrapping, because once 147 secure and authentic channels are established, the bootstrapping of 148 all other information can be conducted as ordinary secured 149 communications. Accordingly, many works focus on security 150 bootstrapping and device authentication. In IETF, 151 [I-D.pritikin-anima-bootstrapping-keyinfra] is proposed in Anima, 152 [I-D.sarikaya-6lo-bootstrapping-solution] is proposed in 6lo, 153 [I-D.struik-6tisch-security-considerations] is in 6tisch, 154 [I-D.kwatsen-netconf-zerotouch] is in Netconf, and 155 [I-D.he-iot-security-bootstrapping] is proposed for bootstrapping 156 IEEE 802.15.4 based IoT networks. ZigBee IP stack is developed by 157 ZigBee Alliance and it supports EAP-TLS and PANA as authentication 158 protocols. In Thread Group, a networking solution is developed. The 159 devices are authenticated through pre-installed codes. IEEE 802.15.4 160 also defines two-step mechanism for nodes joining network with layer 161 2 authentication without considering IP infrastructure. 163 3.1.1. Authentication framework 165 The arguments on authentication framework focus on EAP, PANA, HIP- 166 DEX, 802.1X via EAPOL, and IKEv2. 168 [I-D.oflynn-core-bootstrapping] relates the aforementioned 169 authentication frameworks into IEEE 802.15.4 and requirements in 170 order to use them for bootstrapping procedure. 172 o If PANA is used, a new entity called PANA Relay Element should be 173 added in the architecture and behavior of PANA RE needs to be 174 defined [RFC6345]; New AVPs needed for PANA Relay Element 175 operation for relaying messages from the client to the 176 authenticator and vice versa are required to be specified. If 177 PANA is used to securely distribute group key [RFC6786] from the 178 PANA Authentication Agent to the PANA Client using AES Key Wrap 179 with padding algorithm, an extension to PANA needs to be defined. 181 o If HIP-DEX is used, the initiator should be able to get the IP 182 address of the responder, either using DNS infrastructure or local 183 configuration. 185 o If 802.1X is used, a special value in the Frame Type subfield of 186 the Frame Control Field of IEEE 802.15.4 MAC header should be 187 assigned to indicate the type of the payload. Group addresses for 188 802.15.4 corresponding to EAPOL Group Address Assignments defined 189 in Table 11.1 of [IEEE802.1x] are required, especially for EAPOL- 190 Start packet. The mapping of MAC frames and security level to 191 different types should be defined, for instance: which MAC frames 192 of beacon, data, acknowledgment and MAC command as defined in 193 [IEEE802.15.4] with what security levels are mapped to controlled 194 port, which MAC frames with what security levels are mapped to 195 uncontrolled port and which MAC frames are never mapped to any of 196 controlled/uncontrolled port (i.e., the payload of those frames 197 are used by the MAC-layer itself and never used by upper layers). 199 [I-D.garcia-core-security] discusses about using Internet Key 200 Exchange protocol version 2 (IKEv2) as authentication method. It 201 summarizes that IKEv2 can perform key exchanges and the setup of 202 security associations without online connections to a trust center. 203 It provides end-to-end security, and supports host mobility with 204 MOBIKE extension. However, MOBIKE mandates the use of IPsec tunnel 205 mode which requires to transmit an additional IP header in each 206 packet. This additional overhead could be alleviated by using header 207 compression methods or the Bound End-to-End Tunnel (BEET) mode 208 [I-D.nikander-esp-beet-mode], a hybrid of tunnel and transport mode 209 with smaller packet headers. 211 Several EAP methods have been standardized for different purposes. 212 One widely used method is the EAP-TLS [RFC7250] which enables mutual 213 authentication and distribute keying material to secure subsequent 214 communications. However it only supports certificate-based mutual 215 authentication, thus public key infrastructure is required and 216 fragmentation is needed when using IEEE 802.15.4 to exchange 217 authentication messages. 219 ZigBee Alliance specified an IPv6 stack aimed at IEEE 802.15.4 220 devices mainly used in smart meters developed primarily for SEP 2.0 221 (Smart Energy Profile) application layer traffic [SEP2.0]. This 222 specification assumes Class 2 devices which have 50 KiB of RAM and 223 250 KiB of flash memory [RFC7228]. Some devices in such systems have 224 more resources and processing power (e.g. ARM9 core, MiBs RAM/ 225 Flash). For security bootstrapping, ZigBee IP uses EAP-TLS. 227 Authentication that is not based on certificates reduces cost of 228 certificate management and fewer messages are needed to be exchanged 229 between client and server. [I-D.sarikaya-6lo-bootstrapping-solution] 230 proposes to use raw public keys via EAP-TLS, thus extension to EAP- 231 TLS is indicated. Note that EAP requires exchanging the device 232 identity in plain text at the beginning, but how to protect the 233 privacy information indicated in the device ID is out of concern of 234 EAP methods. 236 EAP-PSK [RFC4764] is another EAP method. It realizes mutual 237 authentication and session key derivation using a Pre-Shared Key 238 (PSK). Normally four messages are exchanged in the authentication 239 process. Once the authentication is successful, EAP-PSK provides a 240 protected communication channel. 242 EAP-IKEv2 [RFC5106] is an EAP method based on IKEv2.. It provides 243 mutual authentication and session key establishment between an EAP 244 peer and an EAP server. It supports authentication techniques that 245 are based on different credentials including asymmetric key pairs, 246 symmetric keys and passwords. Besides, it is possible to use a 247 different authentication credential in each direction. For example, 248 the EAP server authenticates itself using public/private key pair and 249 the EAP peer using symmetric key. As a result different combinations 250 of credentials are expected to be used in practice. Compared with 251 EAP-TLS and EAP-PSK, EAP-IKEv2 supports mobility and different 252 authentication techniques. 254 [I-D.kumar-6lo-selective-bootstrap] presents a selective 255 bootstrapping/commissioning method by introducing the concept of 256 Commissioning Tool (CT). In this method the devices are let to 257 connect to the network and execute 6LowPAN neighbor discovery 258 protocol and have an IPv6 address before they are authenticated. 259 Then the devices are selected one by one in some order to communicate 260 with the CT via untrusted constructed route. Once the ID of joining 261 device is authenticated, CT sends the layer-2 key material to the 262 device via secured channel, which is established by DTLS by 263 exchanging credential material installed during manufacturing. 265 The bootstrapping method in [I-D.kumar-6lo-selective-bootstrap] 266 creates security risks for the network by 268 1. letting the devices have IP addresses for layer3 communication 269 before authentication. 271 2. constructing routing topology before devices are authenticated. 273 3. establishing transport layer security before layer-2 security. 275 However, such a protocol could be justified in some application 276 domains like lightning control systems. 278 There is work going on in the IEEE 802.15.9 task group which 279 specifies a way to transport existing key management protocols (KMP) 280 over the 802.15.4 frames. The new feature would allow running IKEv2, 281 EAP,PANA, 802.1X, HIP and Dragonfly over the IEEE 802.15.4 and 282 generate keys for 802.15.4 security and protect all messages between 283 the two nodes [IEEE802.15.9]. It would be desired if the security 284 bootstrapping procedure reuses the KMPs that supported by lower 285 layers to reduce cost. 287 Table 1 summarizes the authentication frameworks and credential 288 materials of the aforementioned solutions. 290 +-------------------------------------+----------------+------------+ 291 | Referenced solution | Authentication | Credential | 292 | | method | material | 293 +-------------------------------------+----------------+------------+ 294 | [I-D.pritikin-anima-bootstrapping-k | 802.1x-EAPOL, | 802.1AR ce | 295 | eyinfra] | EAP-TLS, EAP- | rtificate | 296 | | IKEv2 | | 297 | [I-D.sarikaya-6lo-bootstrapping-sol | EAP-TLS | Raw public | 298 | ution] | (modified) | key | 299 | [I-D.struik-6tisch-security-conside | Joining | Certificat | 300 | rations] | Protocol | e | 301 | | (undefined) | | 302 | [I-D.kwatsen-netconf-zerotouch] | Unspecified | X.509 cert | 303 | | (EAP-TLS might | ificate | 304 | | be used) | | 305 | [I-D.he-iot-security-bootstrapping] | EAP, PANA | Unspecifie | 306 | | | d | 307 | [I-D.kumar-6lo-selective-bootstrap] | Selected by | PSK | 308 | | Commissioner | defined in | 309 | | with CT | CT | 310 | ZigBee IP stack based Smart Energy | EAP-TLS, PANA | Certificat | 311 | | | e | 312 | Thread networking | Unknown | Product | 313 | | | install | 314 | | | codes | 315 +-------------------------------------+----------------+------------+ 317 Table 1 319 3.1.2. Credential Material and Architecture 321 The trust relationship can be established by exchanging credential 322 materials, which can be asymmetric with user authentication or with 323 certificate authority, or symmetric pre-shared key configured by 324 network developer. In certificate authority (CA), a typical public 325 key infrastructure (PKI) is used, meaning that a set of hardware, 326 software, people, policies, and procedures are needed to create, 327 manage, distribute, use, store, and revoke digital certificates. The 328 public keys are obtained in PKI containers, and both ends are 329 validated using trust anchors based on a certification authority 330 (CA). [I-D.pritikin-anima-bootstrapping-keyinfra] uses 802.1AR 331 certificate, [I-D.kwatsen-netconf-zerotouch] uses X.509 certificate. 332 Certificate mechanism provides high security however it can add a 333 complicated trust relationship that is difficult to validate. When 334 it comes to large scale IoT networks, certificate management and 335 distribution will raise scalability and flexibility issue. Besides, 336 the time spent and CPU occupied by the cryptographic operations is 337 non-trivial when this mechanism is implemented on computational 338 constraint devices. Since some IEEE802.15.4 technologies including 339 802.15.4e only allows 127 Octets maximum payload, fragmentation is 340 unavoidable, which indicates that a large amount of data is 341 transmitted and communication overhead is heavy. The public-key 342 based handshake process of EAP-TLS is part of the bottleneck that 343 significantly degrades the performance. Designers are forced to use 344 highly efficient protocols for the sake of ensuring the computational 345 complexity of security algorithms as low as possible. 347 In today's IoT, most common architectures are fully centralized in a 348 sense that all the security relationships within a segment are 349 handled by a central party. 351 The 802.1x framework, the architecture proposed in 352 [I-D.pritikin-anima-bootstrapping-keyinfra] and the ZigBee IP smart 353 energy solution are centralized. A centralized authentication 354 architecture allows for central management of devices and keying 355 materials as well as for the backup of cryptographic keys. As a 356 result there is no high requirement on network devices in a 357 centralized architecture. However it also represents a single point 358 of failure and is more suitable for static network where the route to 359 the trust center/AAA server is stable. 361 The self-signed certificates are commonly used in smaller deployments 362 where they are distributed to all involved protocol endpoints out-of- 363 band, thus CA and certificate management are not required. This 364 practice does, however, still require the overhead of the certificate 365 generation even though none of the information found in the 366 certificate is actually used. 368 The raw public key method is proposed to generate light weight 369 certificate, which can significantly reduce overhead. However, the 370 self-signed certificate and raw public key only prove the possession 371 of the private-public key pair and are unable to prove whether the 372 owner is legitimate. 374 The pre-shared key based mechanisms are more suitable for constrained 375 environments, e.g. wireless communications, and limited CPU power 376 devices. It enables mutual authentication, meanwhile requires less 377 cryptographic operations and less communication overhead compared 378 with certificate based mechanism. However, traditional approaches of 379 key generation/distribution tend to impose configuration burdens upon 380 users. For example, users need to follow a series of instruction 381 steps for WiFi Protected Access 2, Pre-shared key (WPA2-PSK) 382 configuration, even though the pre-shared key mode is the simplest 383 option for using WPA. Establishing security among IoT devices 384 becomes more complicated since they don't always provide user 385 interface to input necessary security information. 387 As discussed, the authentication of self-signed certificate and pre- 388 shared key mechanisms are distributed. Distributed architecture 389 allows creating ad-hoc security domains that might not require a 390 single online management entity and are operative in a much more 391 stand-alone manner. In this case, hardware should be configured to 392 be able to authenticate and verify other peers. 394 In today's IoT, most common architectures are fully centralized in a 395 sense that all the security relationships within a segment are 396 handled by a central party. 398 The Thread protocol is expected to use product install codes as 399 authentication material. Currently not enough details are available 400 on the Thread protocol. 402 Physical unclonable function (PUF) arises as a promising 403 authentication technology. PUF is a physical entity that is embodied 404 in a physical structure and is easy to evaluate but hard to predict. 405 Further, an individual PUF device must be easy to make but 406 practically impossible to duplicate, even given the exact 407 manufacturing process that produced it. In this respect it is the 408 hardware analog of a one-way function. PUFs can serve as a root of 409 the trust and can provide a key which cannot be easily reverse 410 engineered. Temperature and aging have been given special attention 411 on developing reliable PUF [MIT2014]. 413 3.2. Higher Layer Protocol Use After/During Bootstrapping 415 Configurations of parameters for other protocols are important as 416 well to ensure a successful networking. Those parameters are 417 transferred upon a successful security bootstrapping. 419 The IP address configuration is a major issue which must be solved 420 before any other higher layer service can start. It can be locally 421 pre-configured, auto-configured or managed from a third party tool. 423 o Pre-configured: is mainly what is done today. No further network 424 service is needed, the assignment is done from a planning/ 425 commissioning tool instead. This method requires human 426 interaction, devices with IP configured are trusted by default. 427 scalability and flexibility cannot be satisfied in this case. 429 o Auto-configuration: the device creates its IP address itself, 430 applying one of the algorithms specified in the relevant 431 standards, e.g. ZigBee IP solved this problem by using SLAAC IPv6 432 addresses based on the EUI-64; 433 [I-D.pritikin-anima-bootstrapping-keyinfra] suggests to obtain an 434 IP address using existing methods, such as SLAAC or DHCPv6. RPL 436 [RFC6550] is a special routing protocol that generates for each 437 device an IP prefix based on the constructed routing topology, 438 thus special attention should be paid as chicken/egg issue arises 439 when relay of authentication is needed by the network level 440 bootstrapping. The auto-configured IP address may need to perform 441 a check for duplicates (i.e. APIPA17). Encoding of semantics 442 into the address may need information from lower layer (see above) 443 or from network service. Note, this only works for so-called link 444 local-addresses which are valid only in one Ethernet domain. 446 o Managed: pre-planned addresses are assigned by means of a third 447 party database, such as DHCP, a central server. 449 4. Role of IoT Security Bootstrapping 451 Figure 1 shows a network life cycle: after IoT devices being deployed 452 in field, the security bootstrapping starts. Devices are 453 authenticated, keying materials are exchanged for securing subsequent 454 configuration/data exchange messages. The device gets an IP address 455 and joins the network. 457 +--------------------------------------+ 458 | Device deployment | 459 +----------------+---------------------+ 460 | ------------+ 461 +----------------+---------------------+ | 462 | Network access authentication | | 463 +----------------+---------------------+ | 464 | +->Security Bootstrapping 465 +----------------+---------------------+ | 466 | Secured channel keying material | | 467 +----------------+---------------------+ | 468 | ------------+ 469 +----------------+-------------------------+ 470 | Secure communication in the network | 471 +------------------------------------------+ 473 Figure 1: IoT Life Cycle 475 5. Design Considerations 477 IoT can be deployed in different environments for different 478 applications, which calls for protocols with options where a set of 479 options is selected to construct a protocol stack that fits for a 480 given environment, e.g. home, enterprise or industrial. The 481 deployment and configurations can also be divided into two types, one 482 is for static network, and the other is for dynamic network. 484 IoT developed in buildings, homes, or industrial areas are often 485 static. A general approach is that a network engineer plans the 486 locations for each device and determines topology of network based on 487 deployment environment and channel estimation. Then the key devices 488 (e.g. sink nodes, or parent nodes of a routing protocol) are 489 installed before deploying other devices. Upon successful 490 installation, the device is plugged and security bootstrapping is run 491 in either centralized or distributed manner with pre-configured 492 credential material. The device is at work after all the protocols 493 are successfully bootstrapped. When a new device joins an existing 494 network, the joining device bootstrapping procedure is triggered by 495 itself. 497 In a dynamic network where devices come and go, their IPv6 addresses 498 might also change. Bootstrapping/re-commissioning at network level 499 is more frequently required than that in static network, hence 500 minimum human interaction is highly preferred. Reducing 501 communication overhead will improve the efficiency of networking, and 502 this is especially useful for low bandwidth and low rate IEEE 503 802.15.4. 505 Mains-powered devices can stay continuously connected to the network. 506 Normally-off power strategy can be used for battery powered devices 507 where the devices sleep long periods of time and stay disconnected 508 and reattach to the network after it is woken up. Between these two 509 extremes, there is low-power device mode where the devices need to be 510 able to communicate on a relatively frequent basis 511 [RFC7228].Bootstrapping protocol needs to be able to take into 512 consideration these power levels in the design. 514 The order of bootstrapping is another concern in designing the 515 bootstrapping protocol. The devices could arbitrarily be 516 bootstrapped as they join the network, especially in dynamic 517 topologies. In static topologies the order could be completely 518 installation and installer dependent and could be optimized to lower 519 cost and could be independent of network topology 520 [I-D.kumar-6lo-selective-bootstrap]. The order is also dependent on 521 the architecture of authentication. For centralized architecture, 522 incremental approach is recommended by 523 [I-D.he-iot-security-bootstrapping] , [I-D.garcia-core-security] and 524 [I-D.sarikaya-6lo-bootstrapping-solution], whereas a selective order 525 can be specified by CT [I-D.kumar-6lo-selective-bootstrap] and 526 special attention should be paid on the secured channel establishment 527 via untrusted route. For decentralized architecture, the mutual- 528 authentication is realized between equal peers in pure mesh topology 529 without any preferred order and network keys can be distributed by 530 cluster heads once clusters are formed. 532 Some mandatory considerations can be derived from different 533 applications for IoT security bootstrapping mechanism: 535 5.1. Able to clearly define security dependency and trust domains 537 Things of IoT are more related to private data, thus trust increases 538 its importance. It is easy to introduce a new node in a deployed IoT 539 to capture and analyze the data traffic. As a result, 541 a. Security dependencies between different devices must be 542 clarified. Circular dependencies must be avoided. 544 b. The designed protocol should enable mutual authentication between 545 devices running the security bootstrapping protocol. Proper 546 authentication material and mechanism should be chosen. 548 c. The security bootstrapping protocol processing devices should 549 agree upon the security associations (e.g. key materials, 550 algorithms etc.) for securing their communications before 551 exchanging any protocol packets. 553 5.2. Cross-layer design 555 The security bootstrapping method should take into account the 556 features and requirements of full stack protocols that are selected 557 for an IoT network. Security bootstrapping in collaboration with 558 other networking protocols is likely to produce a comprehensive 559 solution. 561 Cooperative communication and scheduling among neighboring things at 562 lower layer will reduce the possibility of network congestion and 563 assist finishing bootstrapping efficiently. Different power modes 564 should be considered by the designed protocol. 566 As discussed in Section 3.2, higher layer protocols impact the 567 procedure of bootstrapping. During network start-up, link local IP 568 address should be assigned in order to run PANA/TLS to forward 569 authentication messages by IoT routing protocols such as AODV and DSR 570 in MANET. However, the RPL for LLN configures IP addresses for all 571 the devices during/ at the end of routing procedure, which may create 572 a chicken/egg issue when PANA/TLS are also used. 802.1X uses link 573 layer address so no IP address is needed. 575 5.3. Reduce human interaction to the minimum 577 Configuring IoT devices can be complicated since they don't always 578 provide user interface to input all necessary information, and the 579 scale of the IoT network can be large, dynamic or error prone. 581 Besides, IoT network users usually do not have expertise in 582 networking, this motivates self-organizing IoT network protocol that 583 start from security bootstrapping. As a result, the design of 584 bootstrapping protocol should be able to reduce human interaction to 585 the minimum. 587 5.4. Able to resist attacks 589 The designed bootstrapping protocol should be able to resist attacks 590 and protect CIA triad. Typical threat modeling approaches (e.g. 591 STRIDE) should be used to guide the design of bootstrapping 592 architecture and procedure. STRIDE categorizes attack into spoofing, 593 Tampering with data, Repudiation, Information disclosure, Denial of 594 service and Elevation of privilege. 596 5.5. Low computation cost and communication overhead 598 The amount of transmitted data and the complexity of data processing 599 should be optimized to the minimum to save computation and 600 communication cost. 602 6. Security Considerations 604 TBD 606 7. Acknowledgements 608 TBD 610 8. References 612 8.1. Normative References 614 [IEEE802.15.4] 615 IEEE Standard, , "IEEE Std. 802.15.4-2011", October 2011, 616 . 619 [IEEE802.15.9] 620 IEEE P802.15.9/D01, "IEEE Draft Recommended Practice for 621 transport of key management protocol (KMP) datagrams", 622 November 2014, 623 . 626 [IEEE802.1x] 627 IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network 628 Access Control", February 2010, 629 . 632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 633 Requirement Levels", BCP 14, RFC 2119, March 1997. 635 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 636 Demand Distance Vector (AODV) Routing", RFC 3561, July 637 2003. 639 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 640 Protocol (OLSR)", RFC 3626, October 2003. 642 [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source 643 Routing Protocol (DSR) for Mobile Ad Hoc Networks for 644 IPv4", RFC 4728, February 2007. 646 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 647 Pre-Shared Key Extensible Authentication Protocol (EAP) 648 Method", RFC 4764, January 2007. 650 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 651 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 652 September 2007. 654 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 655 over Low-Power Wireless Personal Area Networks (6LoWPANs): 656 Overview, Assumptions, Problem Statement, and Goals", RFC 657 4919, August 2007. 659 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 660 "Transmission of IPv6 Packets over IEEE 802.15.4 661 Networks", RFC 4944, September 2007. 663 [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., 664 and F. Bersani, "The Extensible Authentication Protocol- 665 Internet Key Exchange Protocol version 2 (EAP-IKEv2) 666 Method", RFC 5106, February 2008. 668 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 669 Authentication Protocol", RFC 5216, March 2008. 671 [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 672 256/384 and AES Galois Counter Mode", RFC 5487, March 673 2009. 675 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 676 Yegin, "Protocol for Carrying Authentication for Network 677 Access (PANA) Relay Element", RFC 6345, August 2011. 679 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 680 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 681 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 682 Lossy Networks", RFC 6550, March 2012. 684 [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for 685 Carrying Authentication for Network Access (PANA) 686 Attribute-Value Pairs", RFC 6786, November 2012. 688 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 689 Constrained-Node Networks", RFC 7228, May 2014. 691 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 692 T. Kivinen, "Using Raw Public Keys in Transport Layer 693 Security (TLS) and Datagram Transport Layer Security 694 (DTLS)", RFC 7250, June 2014. 696 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 697 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 698 TLS", RFC 7251, June 2014. 700 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 701 Application Protocol (CoAP)", RFC 7252, June 2014. 703 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 704 IPv6 over Low-Power Wireless Personal Area Networks 705 (6LoWPANs)", RFC 7400, November 2014. 707 [SEP2.0] ZigBee Alliance, "ZigBee IP Specification", March 2014, 708 . 711 8.2. Informative References 713 [I-D.garcia-core-security] 714 Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and 715 R. Struik, "Security Considerations in the IP-based 716 Internet of Things", draft-garcia-core-security-06 (work 717 in progress), September 2013. 719 [I-D.he-iot-security-bootstrapping] 720 ana.hedanping@huawei.com, a., "Security Bootstrapping of 721 IEEE 802.15.4 based Internet of Things", draft-he-iot- 722 security-bootstrapping-00 (work in progress), January 723 2015. 725 [I-D.kumar-6lo-selective-bootstrap] 726 Kumar, S. and P. Stok, "Security Bootstrapping over IEEE 727 802.15.4 in selective order", draft-kumar-6lo-selective- 728 bootstrap-00 (work in progress), March 2015. 730 [I-D.kwatsen-netconf-zerotouch] 731 Watsen, K., Hanna, S., Clarke, J., and M. Abrahamsson, 732 "Zero Touch Provisioning for NETCONF Call Home 733 (ZeroTouch)", draft-kwatsen-netconf-zerotouch-01 (work in 734 progress), February 2014. 736 [I-D.nikander-esp-beet-mode] 737 Nikander, P. and J. Melen, "A Bound End-to-End Tunnel 738 (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 739 (work in progress), August 2008. 741 [I-D.oflynn-core-bootstrapping] 742 Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security 743 Bootstrapping of Resource-Constrained Devices", draft- 744 oflynn-core-bootstrapping-03 (work in progress), November 745 2010. 747 [I-D.pritikin-anima-bootstrapping-keyinfra] 748 Pritikin, M., Behringer, M., and S. Bjarnason, 749 "Bootstrapping Key Infrastructures", draft-pritikin-anima- 750 bootstrapping-keyinfra-01 (work in progress), February 751 2015. 753 [I-D.sarikaya-6lo-bootstrapping-solution] 754 Sarikaya, B., "Secure Bootstrapping Solution for Resource- 755 Constrained Devices", draft-sarikaya-6lo-bootstrapping- 756 solution-00 (work in progress), June 2013. 758 [I-D.struik-6tisch-security-considerations] 759 Struik, R., "6TiSCH Security Architectural 760 Considerations", draft-struik-6tisch-security- 761 considerations-01 (work in progress), January 2015. 763 [MIT2014] Herder, C., Farinaz Koushanfar, F., and S. Srinivas 764 Devadas, "Physical Unclonable Functions and Applications: 765 A Tutorial", Proceedings of the IEEE , vol. 102, no. 8, 766 pp. 1126-1141, August 2014. 768 Authors' Addresses 770 Ana(Danping) He (editor) 771 Huawei 772 Building Q14, 156 Beiqing Road 773 Beijing 100095 774 China 776 Email: ana.hedanping@huawei.com 778 Behcet Sarikaya (editor) 779 Huawei USA 780 5340 Legacy Dr. Building 3 781 Plano, TX 75024 783 Email: sarikaya@ieee.org