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