idnits 2.17.1 draft-sarikaya-t2trg-sbootstrapping-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2017) is 2641 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-aura-eap-noob-01 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-12 == Outdated reference: A later version (-07) exists of draft-marin-ace-wg-coap-eap-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei 4 Intended status: Informational M. Sethi 5 Expires: August 5, 2017 Ericsson 6 AR. Sangi 7 Huawei Technologies 8 February 1, 2017 10 Secure IoT Bootstrapping: A Survey 11 draft-sarikaya-t2trg-sbootstrapping-03 13 Abstract 15 This document presents a survey of secure bootstrapping mechanisms 16 available for smart objects that are part of an Internet of Things 17 (IoT) network. It aims to provide a structured classification of the 18 available mechanisms. The document does not prescribe any one secure 19 bootstrapping mechanism and rather presents IoT developers with 20 different options to choose from, depending on their use-case, 21 security requirements and the user interface available on their smart 22 objects. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 5, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Classification of available mechanisms . . . . . . . . . . . 5 61 4. IoT Device Bootstrapping Methods . . . . . . . . . . . . . . 6 62 4.1. Managed Methods . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Peer to Peer or Adhoc Methods . . . . . . . . . . . . . . 10 64 4.3. Leap-of-faith/Opportunistic Methods . . . . . . . . . . . 12 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 68 8. Informative References . . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 71 1. Introduction 73 An Internet of Things (IoT) network consists of connected things that 74 cooperate together to accomplish tasks such as smart buildings, smart 75 environment monitoring system, and intelligent transport systems. 76 The size of an IoT network varies from a couple of devices to tens of 77 thousands depending on the application. A smart object, or a thing, 78 or a device in an IoT network is typically produced by a variety of 79 vendors and are typically heterogeneous in terms of the constraints 80 on their power supply, communication capability, computation capacity 81 and memory available. Due to this heterogeneity, a wide variety of 82 bootstrapping mechanisms are proposed and used for these smart 83 objects. 85 Before classifying and describing the various methods of 86 bootstrapping, it is important to discuss what is meant by the term 87 bootstrapping. In order to understand the term bootstrapping, we 88 need to discuss some important preliminaries first. We start by 89 discussing the meaning of identity and identifiers. The dictionary 90 defines identity as "something that distinguishes an entity from 91 other entities". Dick Hardt (an advocate of identity 2.0 concept) in 92 his keynote talk on identity describes human identity as "who you 93 are, what you like, what you say about yourself and what others say 94 about you" [identity2.0]. In addition to human beings, other 95 entities in our physical environment such as the electronic devices 96 we use, our pets and wildlife also have identities. 98 Just as in the real world, humans also have identities in the digital 99 world. For example, a digital identity may be used by online service 100 to verify the identity of a registered user and provide it with 101 secure personalized service. This process of identity verification 102 is also known as authentication. An attribute that can be used to 103 identify and distinguish one entity from another is referred to as an 104 identifier. The passport number of a citizen is an example of an 105 real-world identifier. Similarly, an email address is an example of 106 a digital identifier. Often the digital identifier of a human user 107 and the digital identifier of its electronic devices are used 108 interchangeably and one may subsume the other for authentication 109 purposes. For instance, when performing network access 110 authentication, the user may enter its identity credentials on the 111 device that should connect to the network. In this case, the device 112 assumes the user identity on its behalf and authenticates to obtain 113 network access. Ubiquitous computing devices increasingly interact 114 with each other without human intervention. This essentially 115 requires the devices to have their own identifiers for authentication 116 and secure communication. 118 With these preliminaries in mind, we try to decipher the meaning of 119 bootstrapping. The term itself has often been used in many different 120 contexts. For instance, [RFC4640] describes bootstrapping as the 121 process by which a mobile IPv6 node obtains information about the 122 home address, the home agent address, and a security association. 123 The IoT@Work project defines bootstrapping in the context of Internet 124 of Things (IoT) as the process by which the state of a device, a 125 subsystem, a network, or an application changes from not operational 126 to operational [iotwork]. [I-D.oflynn-core-bootstrapping] also 127 discusses the problem of secure bootstrapping for resource- 128 constrained devices and highlights the role of IETF in defining 129 suitable solutions. 131 We define bootstrapping as any process that is required before the 132 resource-constrained device network can operate. Similarly, 133 Vermillard [vermillard] describes bootstrapping as the procedure by 134 which an IoT device gets the secret keys and URL for reaching the 135 necessary servers. Vermillard notes that this procedure is also 136 useful for re-keying, upgrading the security schemes and for 137 redirecting the devices to other servers. The term device onboarding 138 refers to similar ideas and is often used interchangeably with the 139 term bootstrapping. As an example, the AllSeen Alliance [allseen] 140 defines onboarding as a service that provides a common and simple way 141 for new devices to be brought onto an existing WiFi network. Some 142 solutions and standards organizations distinguish the processes 143 involved in bootstrapping into the following sub-processes: 145 a. initial establishment of keys and configuration information 146 b. subsequent provisioning of keys and configuration information 148 The Open Connectivity Foundation (OCF), for example, uses the term 149 onboarding for (a) and bootstrapping for (b). Some specifications 150 consider (a) out of scope and assume that this information is 151 manufacturer provisioned. However, in many cases the two processes 152 are interdependent and may require business agreements and/or 153 protocols to ensure security for both the sub-processes. Instead of 154 providing yet another definition of bootstrapping, here we list the 155 different goals that bootstrapping may be used to fulfill: 157 o Authentication of a pre-established identity or creation of a new 158 identity: To illustrate this with an example, consider the case 159 where a user wishes to use one of the many free online mail 160 services. The user in this case needs to first register and 161 create a unique identifier (email address) for its identity. 162 Thereafter, the user will use this email address along with the 163 password to authenticate and access the mails. Both these 164 processes can be considered as a part of bootstrapping. 166 o Authorization for network access that may include configuration of 167 communication parameters: Bootstrapping also includes the process 168 by which a device authenticates to the network and receives 169 authorization and credentials for subsequent secure communication. 171 o Registration or joining a domain or group: The process by which a 172 windows device joins a windows domain can also be seen as 173 bootstrapping. 175 o Pairing with a specific node, or connecting to a cloud service: 176 Securely pairing two personal computing devices that have no 177 a-priori information about each other, and securely connecting a 178 device to an online cloud service are both different forms of 179 bootstrapping. 181 It is evident that bootstrapping maybe used in many diverse scenarios 182 to fulfill different goals. Thus, it is not surprising that there 183 are many different bootstrapping protocols and methods available. 184 Rather than trying to achieve the impossible target of enlisting all 185 the different bootstrapping solutions, we instead classify them into 186 the following categories in section 3. 188 2. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in 193 [RFC2119]. 195 3. Classification of available mechanisms 197 While some bootstrapping approaches are more user-intensive and 198 require extensive user-involvement by scanning QR codes or entering 199 passwords; others maybe more automated, such as those that rely on 200 mobile networks [I-D.sethi-gba-constrained]. We classify available 201 bootstrapping solutions into the following major categories: 203 o Managed methods: These bootstrapping methods rely on pre- 204 established trust relations and authentication credentials. They 205 typically utilize centralized servers for authentication, although 206 several such servers may join to form a distributed federation. 207 Example methods include Extensible Authentication Protocol (EAP) 208 [RFC3748], Generic Bootstrapping Architecture (GBA) [TS33220], 209 Kerberos [RFC4120], and vendor certificates [vendorcert]. EAP 210 Transport Layer Security EAP-TLS [RFC5216] for instance assumes 211 that both the client and the server have certificates to 212 authenticate each other. Based on this authentication, the server 213 would then authorize the client for network access. The Eduroam 214 federation [RFC7593] uses a network of such servers to support 215 roaming clients. 217 o Peer-to-Peer (P2P) and Ad-hoc methods: These bootstrapping methods 218 do not rely on any pre-established credentials. Instead, the 219 bootstrapping protocol results in credentials being established 220 for subsequent secure communication. Such bootstrapping methods 221 typically perform an unauthenticated Diffie-Hellman exchange [dh] 222 and then use an out-of-band (OOB) communication channel to prevent 223 a man-in-the-middle attack (MitM). Various secure device pairing 224 protocols fall in this category. Another example P2P or Ad-hoc 225 method is EAP-NOOB [I-D.aura-eap-noob] that specifies nimble out- 226 of-band authentication for EAP. Based on how the OOB channel is 227 used, the P2P methods can be further classified into two sub 228 categories: 230 * Key derivation: Contextual information received over the OOB 231 channel is used for shared key derivation. For example, 232 [proximate] relies on the common radio environment of the 233 devices being paired to derive the shared secret which would 234 then be used for secure communication. 236 * Key confirmation: A Diffie-Hellman key exchange occurs over the 237 insecure network and the established key is used to 238 authenticate with the help of the OOB channel. For example, 239 Bluetooth simple pairing [SimplePairing] use the OOB channel to 240 ask the user to compare pins and approve the completed 241 exchange. 243 o Opportunistic and leap-of-faith methods: In these bootstrapping 244 methods, rather than verifying the initial authentication, the 245 continuity of the initial identity or connection is verified. 246 Some of these methods assume that the attacker is not present 247 during the initial setup. Example methods include Secure Neighbor 248 Discovery (SEND) [RFC3971] and Cryptographically Generated 249 Addresses (CGA) [RFC3972], Wifi Protected Setup (WPS) push button 250 [wps], and Secure Shell (SSH) [RFC4253]. Additionally, various 251 online services such as Gmail and Facebook allow anyone to create 252 a new identity during the initial setup and later only verify the 253 continuity of the same identity. 255 o Hybrid methods: Most deployed methods are hybrid and use 256 components from both managed and ad-hoc methods. For instance, 257 central management may be used for devices after they have been 258 registered with the server using ad-hoc registration methods. 260 It is important to note here that categorization of different 261 bootstrapping methods is not always easy or clear. For example, all 262 the opportunistic and leap-of-faith methods become managed methods 263 after the initial vulnerability window. The choice of bootstrapping 264 method used for devices depends heavily on the business case. 265 Questions that may govern the choice include: What third parties are 266 available? Who wants to retain control or avoid work? In each 267 category, there are many different methods of secure bootstrapping 268 available. The choice of the method may also be governed by the type 269 of device being bootstrapped. Depending on the link-layer technology 270 used, and the User Interface (UI) available, one or more of the above 271 mentioned methods might be suitable. 273 4. IoT Device Bootstrapping Methods 275 In this section we look at some of the recent bootstrapping proposals 276 for IoT devices both at the IETF and elsewhere. Needless to say, if 277 the devices are capable in terms of their computation power and UI 278 available, they can always rely on many existing methods such as 279 username and password combinations and various EAP methods. 281 4.1. Managed Methods 283 We first discuss some examples of managed bootstrapping methods. 285 EAP-TLS is a widely used EAP method for network access authentication 286 [RFC7250]. It allows mutual authentication and distributes the 287 keying material for secure subsequent communications. However it 288 only supports certificate-based mutual authentication, and therefore 289 a public key infrastructure is required. The ZigBee Alliance has 290 specified an IPv6 stack aimed at IEEE 802.15.4 [IEEE802.15.4] devices 291 mainly used in smart meters developed primarily for SEP 2.0 (Smart 292 Energy Profile) application layer traffic [SEP2.0]. The ZigBee IP 293 stack uses EAP-TLS for secure bootstrapping of devices. 295 EAP-PSK [RFC4764] is another EAP method. It realizes mutual 296 authentication and session key derivation using a Pre-Shared Key 297 (PSK). Normally four messages are exchanged in the authentication 298 process. Once the authentication is successful, EAP-PSK provides a 299 protected communication channel. Given the light-weight nature of 300 EAP-PSK, it can often be a good choice on constrained devices. 302 EAP-COAP [I-D.marin-ace-wg-coap-eap] uses EAP transported over CoAP 303 [RFC7252] messages for authenticating two CoAP endpoints and 304 configuring key material to protect CoAP messages exchanged between 305 them. They discuss the use of EAP-PSK in the draft, but state that 306 any EAP method that results in generation of cryptographic material 307 is suitable. 309 Protocol for Carrying Authentication for Network Access (PANA) 310 [RFC5191] is a network layer protocol with which a node can 311 authenticate itself to gain access to the network. PANA does not 312 define a new authentication protocol and rather uses EAP over User 313 Datagram Protocol (UDP) for authentication. Colin O'Flynn 314 [I-D.oflynn-core-bootstrapping]proposes the use of PANA for secure 315 bootstrapping of resource constrained devices. He demonstrates how a 316 6LowPAN Border Router (PANA Authentication Agent (PAA)) can 317 authenticate the identity of a joining constrained device (PANA 318 Client). Once the constrained device has been successfully 319 authenticated, the border router can also provide network and 320 security parameters to the joining device. Hernandez-Ramos et al. 321 [panaiot] also use EAP-TLS over PANA for secure bootstrapping of 322 smart objects. They also extend their bootstrapping scheme for 323 configuring additional keys that are used for secure group 324 communication. 326 When a device is not a direct neighbor of the authenticator, its 327 parent node MUST act as relay. Different EAP encapsulation protocols 328 have different mechanisms for the relay function, such as the PANA 329 Relay Element (PRE). 331 After a successful bootstrapping, the device runs neighbor discovery 332 protocol to get an IPv6 address assigned [RFC6775]. Data transfer 333 can be secured using DTLS or IPSec. Keys derived from EAP TLS are 334 used in either generating DTLS ciphering keys after a successful DTLS 335 handshake or IPSec ESP ciphering keys after a successful IKEv2 336 handshake. 338 Generic Bootstrapping Architecture (GBA) is another bootstrapping 339 method that falls in centralized category. GBA is part of the 3GPP 340 standard [TS33220] and is based on 3GPP Authentication and Key 341 Agreement (3GPP AKA). GBA is an application independent mechanism to 342 provide a client application (running on the User equipment (UE)) and 343 any application server with a shared session secret. This shared 344 session secret can subsequently be used to authenticate and protect 345 the communication between the client application and the application 346 server. GBA authentication is based on the permanent secret shared 347 between the UE's Universal Integrated Circuit Card (UICC), for 348 example SIM card, and the corresponding profile information stored 349 within the cellular network operator's Home Subscriber System (HSS) 350 database. [I-D.sethi-gba-constrained] describes a resource- 351 constrained adaptation of GBA to IoT applications. 353 Open Mobile Alliance (OMA) Light-weight M2M standard also defines 354 secure bootstrapping for resource-constrained IoT devices with a 355 centralized Bootstrapping Server (BS). The current standard defines 356 the following four bootstrapping modes: 358 o Factory Bootstrap: An IoT device in this case is configured with 359 all the necessary bootstrap information during manufacturing and 360 prior to its deployment. 362 o Bootstrap from Smartcard: An IoT device retrieves and processes 363 all the necessary bootstrap data from a Smartcard. 365 o Client Initiated Bootstrap: This mode provides a mechanism for an 366 IoT client device to retrieve the bootstrap information from a 367 Bootstrap Server. This requires the client device to have an 368 account at the Bootstrap Server and credentials to obtain the 369 necessary information securely. 371 o Server Initiated Bootstrap: In this bootstrapping mode, the 372 bootstrapping server configures all the bootstrap information on 373 the IoT device without receiving a request from the client. This 374 means that the bootstrap server needs to know if a client IoT 375 Device is ready for bootstrapping before it can be configured. 376 For example, a network may inform the bootstrap server of a new 377 connecting IoT client device. 379 The Kerberos protocol [RFC4120] is a network authentication protocol 380 that allows several endpoints to communicate over an insecure 381 network. Kerberos relies on a symmetric cryptography scheme and 382 requires a trusted third party, that guarantees the identities of the 383 various actors. It relies on the use of "tickets" for nodes to prove 384 identity to one another in a secure manner. There has been research 385 work on using Kereberos for IoT devices[kerberosiot]. 387 The ANIMA working group is also working on a bootstrapping solution 388 for resource-constrained devices that relies on 802.1AR vendor 389 certificates [I-D.ietf-anima-bootstrapping-keyinfra] called 390 Bootstrapping Remote Secure Key Infrastructures (BRSKI). In addition 391 to vendor installed IEEE 802.1AR certificates, a vendor based service 392 on the Internet is required. Before being authenticated, a new 393 device only needs link-local connectivity, and does not require a 394 routable address. When a vendor provides an Internet based service, 395 devices can be forced to join only specific domains. The draft 396 highlights that the described solution is aimed in general at non- 397 constrained (i.e. class 2+ defined in [RFC7228]) devices operating in 398 a non-Challenged network. It claims to scale to thousands of devices 399 located in hostile environments, such as ISP provided CPE devices 400 which are drop-shipped to the end user. 402 [I-D.kumar-6lo-selective-bootstrap] presents a selective 403 bootstrapping/commissioning method by introducing the concept of 404 Commissioning Tool (CT). In this method the devices are left to 405 connect to the network and execute 6LowPAN neighbor discovery 406 protocol and have an IPv6 address before they are authenticated. 407 Then the devices are selected one by one in some order to communicate 408 with the CT via untrusted constructed route. Once the ID of joining 409 device is authenticated, the CT sends the layer-2 key material to the 410 device via secured channel. This secure channel is established with 411 DTLS with credential material that has to be installed onto the 412 device during its manufacture. 414 [I-D.ietf-netconf-zerotouch] defines a bootstrapping strategy for 415 enabling devices to securely obtain all the configuration information 416 with no installer input, beyond the actual physical placement and 417 connection of cables. Their goal is to enable a secure NETCONF 418 [RFC6241] or RESTCONF [RFC8040] connection to the deployment specific 419 network management system (NMS). This bootstrapping method requires 420 the devices to be configured with trust anchors in the form of X.509 421 certificates. 423 Before closing the discussion on managed methods, it is also 424 important to mention some of the work done on implicit certificates 425 and identity-based cryptographic schemes [himmo], [implicit]. While 426 these are interesting and novel schemes that can be a part of 427 securely bootstrapping devices, at this point, it is hard to 428 speculate on whether such schemes would see large-scale deployment in 429 the future. 431 4.2. Peer to Peer or Adhoc Methods 433 While managed methods are viable for many IoT devices, they may not 434 be suitable or desirable in all scenarios. All the managed methods 435 assume that some credentials are provisioned into the device. These 436 credentials may be in the device micro-controller or in a replaceable 437 smart card such as a SIM card. The methods also sometimes assume 438 that the manufacturer embeds these credentials during the device 439 manufacture on the factory floor. However, in many cases the 440 manufacturer may not have sufficient incentive to do this. In other 441 scenarios, it may be hard to completely trust and rely on the device 442 manufacturer to securely perform this task. Therefore, many times, 443 P2P or Adhoc methods of bootstrapping are used. We discuss a few 444 example next. 446 P2P or ad-hoc bootstrapping methods are used for establishing keys 447 and credential information for secure communication without any pre- 448 provisioned information. These bootstrapping mechanisms typically 449 rely on an out-of-band (OOB) channel in order to prevent man-in-the- 450 middle (MitM) attacks. P2P and ad-hoc methods have typically been 451 used for securely pairing personal computing devices such as smart 452 phones. [devicepairing] provides a survey of such secure device 453 pairing methods. Many original pairing schemes required the user to 454 enter the same key string or authentication code to both devices or 455 to compare and approve codes displayed by the devices. While these 456 methods can provide reasonable security, they require user 457 interaction that is relatively unnatural and often considered a 458 nuisance. Thus, there is ongoing research for more natural ways of 459 pairing devices. To reduce the amount of user-interaction required 460 in the pairing process, several proposals use contextual or location- 461 dependent information, or natural user input such as sound or 462 movement, for device pairing [proximate]. 464 The local association created between two devices may later be used 465 for connecting/introducing one of the devices to a centralized 466 server. Such methods would however be classified as hybrids. 468 EAP-NOOB [I-D.aura-eap-noob] is an example of P2P and ad-hoc 469 bootstrapping method that establishes a security association between 470 an IoT device (node) and an online server (unlike pairing two devices 471 for local connections over WiFi or Bluetooth). 473 EAP-NOOB defines an EAP method where the authentication is based on a 474 user-assisted out-of-band (OOB) channel between the server and peer. 475 It is intended as a generic bootstrapping solution for Internet-of- 476 Things devices which have no pre-configured authentication 477 credentials and which are not yet registered on the authentication 478 server. This method claims to be more generic than most ad-hoc 479 bootstrapping solutions in that it supports many types of OOB 480 channels. The exact in-band messages and OOB message contents are 481 specified and not the OOB channel details. Also, EAP-NOOB supports 482 IoT devices with only output (e.g. display) or only input (e.g. 483 camera). It makes combined use of both secrecy and integrity of the 484 OOB channel for more robust security than the ad-hoc solutions. 486 Thread Group commissioning [threadcommissioning] introduces a two 487 phased process i.e. Petitioning and Joining. Entities involved are 488 Leader, Joiner, Commissioner, Joiner Router and Border Router. 489 Leader is the first device in Thread Network that must be 490 commissioned using out-of-band process and is used to inject correct 491 user generated Commissioning Credentials (can be changed later) into 492 Thread Network. Joiner is the node that intends to get authenticated 493 and authorized on Thread Network. Commissioner is either within the 494 Thread Network (Native) or connected with Thread Network via a WLAN 495 (External). 497 Under some topologies, Joiner Router and Border Router facilitate the 498 Joiner node to reach Native and External Commissioner, respectively. 499 Petitioning begins before Joining process and is used to grant sole 500 commissioning authority to a Commissioner. After an authorized 501 Commissioner is designated, eligible thread devices can join network. 502 Pair-wise key is shared between Commissioner and Joiner, network 503 parameters (Network Name, Security Policy, Steering Data, 504 Commissioning Data Timestamp, Commissioning Credential, Network 505 Master Key, Network Key Sequence, Network Mesh-Local ULA, Border 506 Router Locator, Commissioner Session ID, XPANID, PANID and Channel) 507 are sent out securely (using pair-wise key) by Joiner Router to 508 Joiner for letting Joiner to join the Thread Network. Entities 509 involved in Joining process depends on system topology i.e. location 510 of Commissioner and Joiner. 512 Thread networks only operates using IPv6. Thread devices can devise 513 GUAs (Global Unicast Addresses) [RFC4291]. Provision also exist via 514 Border Router, for Thread device to acquire individual global address 515 by means of DHCPv6 or using SLAAC (Stateless Address 516 Autoconfiguration) address derived with advertised network prefix. 518 DPP (Device Provisioning Protocol) [dpp] is a 3 message 519 authentication protocol currently being standardized by the WiFi 520 Alliance for devices that rely on IEEE 802.11 link-layer for 521 communication. The current DPP specification is only aimed at 522 networks that use WPA2-PSK (also known as WPA2-Home) for network 523 access authentication. Authentication Request, Response and Confirm 524 are 3 messages types based on [IEEE802.11] format. It provides 525 authentication and key establishment between an initiator and a 526 responder. Out of band mechanisms i.e. QR code, USB, NFC, Bluetooth 527 or proof of shared code/phrase/word is used to acquire bootstrapping 528 key [dpptech]. Afterwards, authentication and configuration exchange 529 takes place. Bootstrap trust in public key can be only for 530 responder's public key or for both parties in mutual authentication 531 manner. The role of initiator and responder as either enrollee or 532 configurator is decided during initial exchange of DPP Authentication 533 frames. Configurator's protocol key is always a one-time-used 534 (ephemeral) key but enrollee's protocol key always becomes its 535 network access provisioning key. 537 4.3. Leap-of-faith/Opportunistic Methods 539 Next, we look at a leap-of-faith/opportunistic bootstrapping method 540 for IoT devices. 542 Bergmann et al. [simplekey] develop a secure bootstrapping mechanism 543 that does not rely on pre-provisioned credentials using resurrecting- 544 duckling imprinting scheme. Their bootstrapping protocol involves 545 three distinct phases: discover (the duckling node searches for 546 network nodes that can act as mother node), imprint (the mother node 547 imprints a shared secret establishing a secure channel once a 548 positive response is received for the imprinting request) and 549 configure (additional configuration information such as network 550 prefix and default gateway are configured). In this model for 551 bootstrapping, a small initial vulnerability window is acceptable and 552 can be mitigated using techniques such as a Faraday Cage (securing 553 the communication physically) to protect the environment of the 554 mother and duck nodes, though this may be inconvenient for the user. 556 [RFC7250] defines how raw public keys can be used to authenticate 557 constrained devices for mutual authentication using EAP-TLS or DTLS. 558 Raw public key TLS/DTLS extension simplifies client_certificate_type 559 and server_certificate_type to carry only SubjectPublicKeyInfo 560 structure with the raw public key instead of many other parameters 561 found in the certificates. The device and the authentication server 562 (AS) exchange client_hello and server_hello messages and send their 563 raw public keys. The device and AS validate the keys by comparing 564 the pre-configured values [I-D.sarikaya-6lo-bootstrapping-solution]. 565 This bootstrapping method can be seen as a hybrid. This is because 566 it generally requires an out-of-band (OOB) step (P2P/Ad-hoc) where 567 the raw public keys [RFC7250] are provided to the authenticating 568 entities, after which the actual authentication occurs online 569 (managed). Raw public key approach when used with DTLS offers a 570 simple secure bootstrapping solution especially for smart energy and 571 building automation applications. It can be easily integrated with 572 the Constrained Application Protocol (CoAP). 574 5. Security Considerations 576 Bootstrapping protocols that do not rely on a pre-shared key for peer 577 authentication generally rely on an online or offline third-party 578 (e.g., an authentication server, a key distribution center in 579 Kerberos, a certification authority in PKI, a private key generator 580 in ID-based cryptography and so on) to prevent man-in-the-middle 581 attacks during bootstrapping. Depending on use cases, a resource- 582 constrained device may not always have access to an online third- 583 party for bootstrapping. Some bootstrapping methods therefore rely 584 on a configuration tool (such as a smartphone) that assists the 585 bootstrapping process by providing temporary reachability to the 586 online server. 588 Depending on use cases, a bootstrapping protocol may deal with 589 authorization separately from authentication in terms of timing and 590 signaling path. For example, two resource-constrained devices A and 591 B may perform mutual authentication using authentication credentials 592 provided by an offline third-party X whereas resource-constrained 593 device A obtains authorization for running a particular application 594 with resource-constrained device B from an online third-party Y 595 before or after the authentication. In some use cases, 596 authentication and authorization are tightly coupled, e.g., 597 successful authentication also means successful authorization. 599 If authorization information communicated includes cryptographic 600 keys, care must be taken for provisioning the keys, e.g., guidelines 601 for AAA-based key management are described in [RFC4962]. Re- 602 bootstrapping of IoT devices may required and therefore there must be 603 adequate provisions for revocation and re-bootstrapping of 604 authentication/authorization credentials. Re-bootstrapping must be 605 as secure as the initial bootstrapping regardless of whether this re- 606 bootstrapping is done manually or automatically over the network. 608 If resource-constrained devices use a multicast group key for 609 authentications of peers that belong to the group, or for message 610 authentication/encryption, the group key must be securely distributed 611 to the current members of the group. Protocols designed for group 612 key management [RFC4046] may be used for group key distribution after 613 the initial bootstrapping. Alternatively, key wrap attributes for 614 securely encapsulating group key may be defined in network access 615 authentication protocols such as PANA. Those protocols use an end- 616 to-end, point-to-point communication channel with a pair-wise 617 security association between a key distribution center and each key 618 recipient. Further considerations may be needed for more efficient 619 group key management to support a large number of resource- 620 constrained devices. 622 6. IANA Considerations 624 There are no IANA considerations for this document. 626 7. Acknowledgements 628 We would like to thank Tuomas Aura and Hannes Tschofenig for 629 providing extensive feedback. 631 8. Informative References 633 [allseen] AllSeen Alliance, "Onboarding service", 634 . 637 [devicepairing] 638 Mirzadeh, S., Cruickshank, H., and R. Tafazolli, "Secure 639 Device Pairing: A Survey", IEEE Communications Surveys and 640 Tutorials , pp. 17-40, 2014. 642 [dh] Diffie, W. and M. Hellman, "New directions in 643 cryptography", IEEE Transactions on Information Theory , 644 vol. 22, no. 6, pp. 644-654, 1976. 646 [dpp] Overview Document, , "Wi-Fi Device Provisioning Protocol 647 (DPP)", Wi-Fi Alliance , 2016. 649 [dpptech] Technical Specification, , "Technical Specification Draft 650 for DPP", Wi-Fi Alliance , 2016. 652 [himmo] Garcia-Morchon, O., Rietman, R., Sharma, S., Tolhuizen, 653 L., and J. Torre-Arce, "DTLS-HIMMO: Efficiently Securing a 654 Post-Quantum World with a Fully-Collusion Resistant KPS", 655 Submitted to NIST Workshop on Cybersecurity in a Post- 656 Quantum World , version 20141225:065757, December 2014, 657 . 659 [I-D.aura-eap-noob] 660 Aura, T. and M. Sethi, "Nimble out-of-band authentication 661 for EAP (EAP-NOOB)", draft-aura-eap-noob-01 (work in 662 progress), July 2016. 664 [I-D.ietf-anima-bootstrapping-keyinfra] 665 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 666 S., and K. Watsen, "Bootstrapping Remote Secure Key 667 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 668 keyinfra-04 (work in progress), October 2016. 670 [I-D.ietf-netconf-zerotouch] 671 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 672 for NETCONF or RESTCONF based Management", draft-ietf- 673 netconf-zerotouch-12 (work in progress), January 2017. 675 [I-D.kumar-6lo-selective-bootstrap] 676 Kumar, S. and P. Stok, "Security Bootstrapping over IEEE 677 802.15.4 in selective order", draft-kumar-6lo-selective- 678 bootstrap-00 (work in progress), March 2015. 680 [I-D.marin-ace-wg-coap-eap] 681 Lopez, R. and D. Garcia, "EAP-based Authentication Service 682 for CoAP", draft-marin-ace-wg-coap-eap-04 (work in 683 progress), October 2016. 685 [I-D.oflynn-core-bootstrapping] 686 Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security 687 Bootstrapping of Resource-Constrained Devices", draft- 688 oflynn-core-bootstrapping-03 (work in progress), November 689 2010. 691 [I-D.sarikaya-6lo-bootstrapping-solution] 692 Sarikaya, B., "Secure Bootstrapping Solution for Resource- 693 Constrained Devices", draft-sarikaya-6lo-bootstrapping- 694 solution-00 (work in progress), June 2013. 696 [I-D.sethi-gba-constrained] 697 Sethi, M., Lehtovirta, V., and P. Salmela, "Using Generic 698 Bootstrapping Architecture with Constrained Devices", 699 draft-sethi-gba-constrained-01 (work in progress), 700 February 2014. 702 [identity2.0] 703 Hardt, D., "Identity 2.0", O'Reilly Open Source Convention 704 (OSCON) , 2005. 706 [IEEE802.11] 707 IEEE Standard, , "IEEE Std. 802.11-2016", December 2016, 708 . 711 [IEEE802.15.4] 712 IEEE Standard, , "IEEE Std. 802.15.4-2015", April 2016, 713 . 716 [implicit] 717 Porambage, P., Schmitt, C., Kumar, P., Gurtov, A., and M. 718 Ylianttila, "Pauthkey: A pervasive authentication protocol 719 and key establishment scheme for wireless sensor networks 720 in distributed iot applications", International Journal of 721 Distributed Sensor Networks , Hindawi Publishing 722 Corporation , 2014. 724 [iotwork] European Commission FP7, "IoT@Work bootstrapping 725 architecture Deliverable D2.2", June 2011. 727 [kerberosiot] 728 Hardjono, , "Kerberos for Internet-of-Things", February 729 2014, . 732 [panaiot] Hernandez-Ramos, J., Carrillo, D., Marin-Lopez, R., and A. 733 Skarmeta, "Dynamic Security Credentials PANA-based 734 Provisioning for IoT Smart Objects", 2nd World Forum on 735 Internet of Things (WF-IoT) , IEEE , 2015. 737 [proximate] 738 Mathur, , Miller, , Varshavsky, , Trappe, , and Mandayam, 739 "Proximate: proximity-based secure pairing using ambient 740 wireless signals.", Proceedings of MobiSys International 741 Conference , pp. 211-224, June 2011. 743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, 745 DOI 10.17487/RFC2119, March 1997, 746 . 748 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 749 Levkowetz, Ed., "Extensible Authentication Protocol 750 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 751 . 753 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 754 "SEcure Neighbor Discovery (SEND)", RFC 3971, 755 DOI 10.17487/RFC3971, March 2005, 756 . 758 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 759 RFC 3972, DOI 10.17487/RFC3972, March 2005, 760 . 762 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 763 "Multicast Security (MSEC) Group Key Management 764 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 765 . 767 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 768 Kerberos Network Authentication Service (V5)", RFC 4120, 769 DOI 10.17487/RFC4120, July 2005, 770 . 772 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 773 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 774 January 2006, . 776 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 777 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 778 2006, . 780 [RFC4640] Patel, A., Ed. and G. Giaretta, Ed., "Problem Statement 781 for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 782 DOI 10.17487/RFC4640, September 2006, 783 . 785 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 786 Pre-Shared Key Extensible Authentication Protocol (EAP) 787 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 788 . 790 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 791 Authorization, and Accounting (AAA) Key Management", 792 BCP 132, RFC 4962, DOI 10.17487/RFC4962, July 2007, 793 . 795 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 796 and A. Yegin, "Protocol for Carrying Authentication for 797 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 798 May 2008, . 800 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 801 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 802 March 2008, . 804 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 805 and A. Bierman, Ed., "Network Configuration Protocol 806 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 807 . 809 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 810 Bormann, "Neighbor Discovery Optimization for IPv6 over 811 Low-Power Wireless Personal Area Networks (6LoWPANs)", 812 RFC 6775, DOI 10.17487/RFC6775, November 2012, 813 . 815 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 816 Constrained-Node Networks", RFC 7228, 817 DOI 10.17487/RFC7228, May 2014, 818 . 820 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 821 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 822 Transport Layer Security (TLS) and Datagram Transport 823 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 824 June 2014, . 826 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 827 Application Protocol (CoAP)", RFC 7252, 828 DOI 10.17487/RFC7252, June 2014, 829 . 831 [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 832 Architecture for Network Roaming", RFC 7593, 833 DOI 10.17487/RFC7593, September 2015, 834 . 836 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 837 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 838 . 840 [SEP2.0] ZigBee Alliance, "ZigBee IP Specification", March 2014, 841 . 844 [simplekey] 845 Bergmann, O., Gerdes, S., and C. Bormann, "Simple Keys for 846 Simple Smart Objects", Smart Object Security Workshop, 847 IETF 83 , March 2012. 849 [SimplePairing] 850 Bluetooth, SIG, "Simple pairing whitepaper", Technical 851 report , 2007. 853 [threadcommissioning] 854 White Paper, , "Thread Commissioning", Thread Group, 855 Inc. , 2015. 857 [TS33220] 3GPP, "3rd Generation Partnership Project; Technical 858 Specification Group Services and System Aspects; Generic 859 Authentication Architecture (GAA); Generic Bootstrapping 860 Architecture (GBA) (Release 14)", December 2016, 861 . 863 [vendorcert] 864 IEEE std. 802.1ar-2009, "Standard for local and 865 metropolitan area networks - secure device identity", 866 December 2009. 868 [vermillard] 869 Vermillard, J., "Bootstrapping device security with 870 lightweight M2M", Appeared on blog at medium.com , 871 February 2015. 873 [wps] IEEE Standard, , "Wi-fi protected setup", Wi-Fi Alliance , 874 2007. 876 Authors' Addresses 878 Behcet Sarikaya 879 Huawei 880 5340 Legacy Dr. Building 3 881 Plano, TX 75024 882 USA 884 Email: sarikaya@ieee.org 886 Mohit Sethi 887 Ericsson 888 Hirsalantie 11 889 Jorvas 02420 890 Finland 892 Email: mohit@piuha.net 894 Abdur Rashid Sangi 895 Huawei Technologies 896 No.156 Beiqing Rd. Haidian District 897 Beijing 100095 898 P.R. China 900 Email: rashid.sangi@huawei.com