idnits 2.17.1 draft-sarikaya-t2trg-sbootstrapping-04.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 (June 8, 2018) is 2147 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-02 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-15 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-22 == 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: December 10, 2018 Ericsson 6 D. Garcia-Carillo 7 Odin Solutions, S.L 8 June 8, 2018 10 Secure IoT Bootstrapping: A Survey 11 draft-sarikaya-t2trg-sbootstrapping-04 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 December 10, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 20 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 [I-D.ietf-netconf-restconf] connection to the 419 deployment specific network management system (NMS). This 420 bootstrapping method requires the devices to be configured with trust 421 anchors in the form of X.509 certificates. 423 LP-WAN encompasses a wide variety of technologies, generally, with 424 severe constraints in the link in comparison with other typical IoT 425 technologies such as Bluetooth or IEEE 802.15.4. LPWAN typically 426 presents a star topology with support for thousands of devices per 427 antenna. Among the wide variety of technologies, we highlight the 428 ones mentioned in the LP-WAN overview document of the LPWAN working 429 group [RFC8376]: LoRaWAN, Narrowband IoT (NB-IoT), SIGFOX and Wi-SUN 430 Alliance Field Area Network (FAN). Each technology has different 431 methods to provide security for the communications. Bootstrapping is 432 not directly tackled by all of them, having in some cases proprietary 433 solutions that are not publicly accessible. Bootstrapping is 434 discussed in LoRaWAN and Wi-SUN Alliance Field Area Network (FAN) and 435 use managed bootstrapping methods. 437 LoRaWAN describes its own protocol to authenticate and incorporate 438 nodes into their network, called the Joining Procedure based on pre- 439 shared keys. The Joining procedure entails one exchange where the 440 node that intends to join the network sends its identity along with 441 other information to authenticate against a network server which 442 interacts with an entity that knows the pre-shared key (called 443 AppKey) and derives the necessary key material for its nominal 444 operation. 446 Wi-SUN Alliance Field Area Network (FAN) uses an EAP lower layer 447 (IEEE 802.1X) and the EAP-TLS method for network access 448 authentication and perform the 4-way handshake to establish a 449 security association similarly to a WPA2-Enterprise deployment. 451 In short, LP-WAN are still under development, and as it is identified 452 in the document, overview of LPWAN [RFC8376], due to the 453 characteristics of these technologies, they are prime candidates to 454 benefit from a standardized Authentication, Accounting, and 455 Authorization (AAA) infrastructure [RFC2904] as a way of offering a 456 scalable solution for some of the security and management issues that 457 are present in LPWANs. 459 Before closing the discussion on managed methods, it is also 460 important to mention some of the work done on implicit certificates 461 and identity-based cryptographic schemes [himmo], [implicit]. While 462 these are interesting and novel schemes that can be a part of 463 securely bootstrapping devices, at this point, it is hard to 464 speculate on whether such schemes would see large-scale deployment in 465 the future. 467 4.2. Peer to Peer or Adhoc Methods 469 While managed methods are viable for many IoT devices, they may not 470 be suitable or desirable in all scenarios. All the managed methods 471 assume that some credentials are provisioned into the device. These 472 credentials may be in the device micro-controller or in a replaceable 473 smart card such as a SIM card. The methods also sometimes assume 474 that the manufacturer embeds these credentials during the device 475 manufacture on the factory floor. However, in many cases the 476 manufacturer may not have sufficient incentive to do this. In other 477 scenarios, it may be hard to completely trust and rely on the device 478 manufacturer to securely perform this task. Therefore, many times, 479 P2P or Adhoc methods of bootstrapping are used. We discuss a few 480 example next. 482 P2P or ad-hoc bootstrapping methods are used for establishing keys 483 and credential information for secure communication without any pre- 484 provisioned information. These bootstrapping mechanisms typically 485 rely on an out-of-band (OOB) channel in order to prevent man-in-the- 486 middle (MitM) attacks. P2P and ad-hoc methods have typically been 487 used for securely pairing personal computing devices such as smart 488 phones. [devicepairing] provides a survey of such secure device 489 pairing methods. Many original pairing schemes required the user to 490 enter the same key string or authentication code to both devices or 491 to compare and approve codes displayed by the devices. While these 492 methods can provide reasonable security, they require user 493 interaction that is relatively unnatural and often considered a 494 nuisance. Thus, there is ongoing research for more natural ways of 495 pairing devices. To reduce the amount of user-interaction required 496 in the pairing process, several proposals use contextual or location- 497 dependent information, or natural user input such as sound or 498 movement, for device pairing [proximate]. 500 The local association created between two devices may later be used 501 for connecting/introducing one of the devices to a centralized 502 server. Such methods would however be classified as hybrids. 504 EAP-NOOB [I-D.aura-eap-noob] is an example of P2P and ad-hoc 505 bootstrapping method that establishes a security association between 506 an IoT device (node) and an online server (unlike pairing two devices 507 for local connections over WiFi or Bluetooth). 509 EAP-NOOB defines an EAP method where the authentication is based on a 510 user-assisted out-of-band (OOB) channel between the server and peer. 511 It is intended as a generic bootstrapping solution for Internet-of- 512 Things devices which have no pre-configured authentication 513 credentials and which are not yet registered on the authentication 514 server. This method claims to be more generic than most ad-hoc 515 bootstrapping solutions in that it supports many types of OOB 516 channels. The exact in-band messages and OOB message contents are 517 specified and not the OOB channel details. Also, EAP-NOOB supports 518 IoT devices with only output (e.g. display) or only input (e.g. 519 camera). It makes combined use of both secrecy and integrity of the 520 OOB channel for more robust security than the ad-hoc solutions. 522 Thread Group commissioning [threadcommissioning] introduces a two 523 phased process i.e. Petitioning and Joining. Entities involved are 524 Leader, Joiner, Commissioner, Joiner Router and Border Router. 525 Leader is the first device in Thread Network that must be 526 commissioned using out-of-band process and is used to inject correct 527 user generated Commissioning Credentials (can be changed later) into 528 Thread Network. Joiner is the node that intends to get authenticated 529 and authorized on Thread Network. Commissioner is either within the 530 Thread Network (Native) or connected with Thread Network via a WLAN 531 (External). 533 Under some topologies, Joiner Router and Border Router facilitate the 534 Joiner node to reach Native and External Commissioner, respectively. 535 Petitioning begins before Joining process and is used to grant sole 536 commissioning authority to a Commissioner. After an authorized 537 Commissioner is designated, eligible thread devices can join network. 538 Pair-wise key is shared between Commissioner and Joiner, network 539 parameters (Network Name, Security Policy, Steering Data, 540 Commissioning Data Timestamp, Commissioning Credential, Network 541 Master Key, Network Key Sequence, Network Mesh-Local ULA, Border 542 Router Locator, Commissioner Session ID, XPANID, PANID and Channel) 543 are sent out securely (using pair-wise key) by Joiner Router to 544 Joiner for letting Joiner to join the Thread Network. Entities 545 involved in Joining process depends on system topology i.e. location 546 of Commissioner and Joiner. 548 Thread networks only operates using IPv6. Thread devices can devise 549 GUAs (Global Unicast Addresses) [RFC4291]. Provision also exist via 550 Border Router, for Thread device to acquire individual global address 551 by means of DHCPv6 or using SLAAC (Stateless Address 552 Autoconfiguration) address derived with advertised network prefix. 554 DPP (Device Provisioning Protocol) [dpp] is a 3 message 555 authentication protocol currently being standardized by the WiFi 556 Alliance for devices that rely on IEEE 802.11 link-layer for 557 communication. The current DPP specification is only aimed at 558 networks that use WPA2-PSK (also known as WPA2-Home) for network 559 access authentication. Authentication Request, Response and Confirm 560 are 3 messages types based on [IEEE802.11] format. It provides 561 authentication and key establishment between an initiator and a 562 responder. Out of band mechanisms i.e. QR code, USB, NFC, Bluetooth 563 or proof of shared code/phrase/word is used to acquire bootstrapping 564 key [dpptech]. Afterwards, authentication and configuration exchange 565 takes place. Bootstrap trust in public key can be only for 566 responder's public key or for both parties in mutual authentication 567 manner. The role of initiator and responder as either enrollee or 568 configurator is decided during initial exchange of DPP Authentication 569 frames. Configurator's protocol key is always a one-time-used 570 (ephemeral) key but enrollee's protocol key always becomes its 571 network access provisioning key. 573 4.3. Leap-of-faith/Opportunistic Methods 575 Next, we look at a leap-of-faith/opportunistic bootstrapping method 576 for IoT devices. 578 Bergmann et al. [simplekey] develop a secure bootstrapping mechanism 579 that does not rely on pre-provisioned credentials using resurrecting- 580 duckling imprinting scheme. Their bootstrapping protocol involves 581 three distinct phases: discover (the duckling node searches for 582 network nodes that can act as mother node), imprint (the mother node 583 imprints a shared secret establishing a secure channel once a 584 positive response is received for the imprinting request) and 585 configure (additional configuration information such as network 586 prefix and default gateway are configured). In this model for 587 bootstrapping, a small initial vulnerability window is acceptable and 588 can be mitigated using techniques such as a Faraday Cage (securing 589 the communication physically) to protect the environment of the 590 mother and duck nodes, though this may be inconvenient for the user. 592 [RFC7250] defines how raw public keys can be used to authenticate 593 constrained devices for mutual authentication using EAP-TLS or DTLS. 594 Raw public key TLS/DTLS extension simplifies client_certificate_type 595 and server_certificate_type to carry only SubjectPublicKeyInfo 596 structure with the raw public key instead of many other parameters 597 found in the certificates. The device and the authentication server 598 (AS) exchange client_hello and server_hello messages and send their 599 raw public keys. The device and AS validate the keys by comparing 600 the pre-configured values [I-D.sarikaya-6lo-bootstrapping-solution]. 601 This bootstrapping method can be seen as a hybrid. This is because 602 it generally requires an out-of-band (OOB) step (P2P/Ad-hoc) where 603 the raw public keys [RFC7250] are provided to the authenticating 604 entities, after which the actual authentication occurs online 605 (managed). Raw public key approach when used with DTLS offers a 606 simple secure bootstrapping solution especially for smart energy and 607 building automation applications. It can be easily integrated with 608 the Constrained Application Protocol (CoAP). 610 5. Security Considerations 612 Bootstrapping protocols that do not rely on a pre-shared key for peer 613 authentication generally rely on an online or offline third-party 614 (e.g., an authentication server, a key distribution center in 615 Kerberos, a certification authority in PKI, a private key generator 616 in ID-based cryptography and so on) to prevent man-in-the-middle 617 attacks during bootstrapping. Depending on use cases, a resource- 618 constrained device may not always have access to an online third- 619 party for bootstrapping. Some bootstrapping methods therefore rely 620 on a configuration tool (such as a smartphone) that assists the 621 bootstrapping process by providing temporary reachability to the 622 online server. 624 Depending on use cases, a bootstrapping protocol may deal with 625 authorization separately from authentication in terms of timing and 626 signaling path. For example, two resource-constrained devices A and 627 B may perform mutual authentication using authentication credentials 628 provided by an offline third-party X whereas resource-constrained 629 device A obtains authorization for running a particular application 630 with resource-constrained device B from an online third-party Y 631 before or after the authentication. In some use cases, 632 authentication and authorization are tightly coupled, e.g., 633 successful authentication also means successful authorization. 635 If authorization information communicated includes cryptographic 636 keys, care must be taken for provisioning the keys, e.g., guidelines 637 for AAA-based key management are described in [RFC4962]. Re- 638 bootstrapping of IoT devices may required and therefore there must be 639 adequate provisions for revocation and re-bootstrapping of 640 authentication/authorization credentials. Re-bootstrapping must be 641 as secure as the initial bootstrapping regardless of whether this re- 642 bootstrapping is done manually or automatically over the network. 644 If resource-constrained devices use a multicast group key for 645 authentications of peers that belong to the group, or for message 646 authentication/encryption, the group key must be securely distributed 647 to the current members of the group. Protocols designed for group 648 key management [RFC4046] may be used for group key distribution after 649 the initial bootstrapping. Alternatively, key wrap attributes for 650 securely encapsulating group key may be defined in network access 651 authentication protocols such as PANA. Those protocols use an end- 652 to-end, point-to-point communication channel with a pair-wise 653 security association between a key distribution center and each key 654 recipient. Further considerations may be needed for more efficient 655 group key management to support a large number of resource- 656 constrained devices. 658 6. IANA Considerations 660 There are no IANA considerations for this document. 662 7. Acknowledgements 664 We would like to thank Tuomas Aura and Hannes Tschofenig for 665 providing extensive feedback and Rafa Marin for support. 667 8. Informative References 669 [allseen] AllSeen Alliance, "Onboarding service", 670 . 673 [devicepairing] 674 Mirzadeh, S., Cruickshank, H., and R. Tafazolli, "Secure 675 Device Pairing: A Survey", IEEE Communications Surveys and 676 Tutorials , pp. 17-40, 2014. 678 [dh] Diffie, W. and M. Hellman, "New directions in 679 cryptography", IEEE Transactions on Information Theory , 680 vol. 22, no. 6, pp. 644-654, 1976. 682 [dpp] Overview Document, "Wi-Fi Device Provisioning Protocol 683 (DPP)", Wi-Fi Alliance , 2016. 685 [dpptech] Technical Specification, "Technical Specification Draft 686 for DPP", Wi-Fi Alliance , 2016. 688 [himmo] Garcia-Morchon, O., Rietman, R., Sharma, S., Tolhuizen, 689 L., and J. Torre-Arce, "DTLS-HIMMO: Efficiently Securing a 690 Post-Quantum World with a Fully-Collusion Resistant KPS", 691 Submitted to NIST Workshop on Cybersecurity in a Post- 692 Quantum World , version 20141225:065757, December 2014, 693 . 695 [I-D.aura-eap-noob] 696 Aura, T. and M. Sethi, "Nimble out-of-band authentication 697 for EAP (EAP-NOOB)", draft-aura-eap-noob-02 (work in 698 progress), May 2017. 700 [I-D.ietf-anima-bootstrapping-keyinfra] 701 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 702 S., and K. Watsen, "Bootstrapping Remote Secure Key 703 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 704 keyinfra-15 (work in progress), April 2018. 706 [I-D.ietf-netconf-restconf] 707 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 708 Protocol", draft-ietf-netconf-restconf-18 (work in 709 progress), October 2016. 711 [I-D.ietf-netconf-zerotouch] 712 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 713 Provisioning for Networking Devices", draft-ietf-netconf- 714 zerotouch-22 (work in progress), June 2018. 716 [I-D.kumar-6lo-selective-bootstrap] 717 Kumar, S. and P. Stok, "Security Bootstrapping over IEEE 718 802.15.4 in selective order", draft-kumar-6lo-selective- 719 bootstrap-00 (work in progress), March 2015. 721 [I-D.marin-ace-wg-coap-eap] 722 Lopez, R. and D. Garcia, "EAP-based Authentication Service 723 for CoAP", draft-marin-ace-wg-coap-eap-06 (work in 724 progress), October 2017. 726 [I-D.oflynn-core-bootstrapping] 727 Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security 728 Bootstrapping of Resource-Constrained Devices", draft- 729 oflynn-core-bootstrapping-03 (work in progress), November 730 2010. 732 [I-D.sarikaya-6lo-bootstrapping-solution] 733 Sarikaya, B., "Secure Bootstrapping Solution for Resource- 734 Constrained Devices", draft-sarikaya-6lo-bootstrapping- 735 solution-00 (work in progress), June 2013. 737 [I-D.sethi-gba-constrained] 738 Sethi, M., Lehtovirta, V., and P. Salmela, "Using Generic 739 Bootstrapping Architecture with Constrained Devices", 740 draft-sethi-gba-constrained-01 (work in progress), 741 February 2014. 743 [identity2.0] 744 Hardt, D., "Identity 2.0", O'Reilly Open Source Convention 745 (OSCON) , 2005. 747 [IEEE802.11] 748 IEEE Standard, "IEEE Std. 802.11-2016", December 2016, 749 . 752 [IEEE802.15.4] 753 IEEE Standard, "IEEE Std. 802.15.4-2015", April 2016, 754 . 757 [implicit] 758 Porambage, P., Schmitt, C., Kumar, P., Gurtov, A., and M. 759 Ylianttila, "Pauthkey: A pervasive authentication protocol 760 and key establishment scheme for wireless sensor networks 761 in distributed iot applications", International Journal of 762 Distributed Sensor Networks , Hindawi Publishing 763 Corporation , 2014. 765 [iotwork] European Commission FP7, "IoT@Work bootstrapping 766 architecture Deliverable D2.2", June 2011. 768 [kerberosiot] 769 Hardjono, "Kerberos for Internet-of-Things", February 770 2014, . 773 [panaiot] Hernandez-Ramos, J., Carrillo, D., Marin-Lopez, R., and A. 774 Skarmeta, "Dynamic Security Credentials PANA-based 775 Provisioning for IoT Smart Objects", 2nd World Forum on 776 Internet of Things (WF-IoT) , IEEE , 2015. 778 [proximate] 779 Mathur, Miller, Varshavsky, Trappe, and Mandayam, 780 "Proximate: proximity-based secure pairing using ambient 781 wireless signals.", Proceedings of MobiSys International 782 Conference , pp. 211-224, June 2011. 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, 786 DOI 10.17487/RFC2119, March 1997, 787 . 789 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 790 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 791 D. Spence, "AAA Authorization Framework", RFC 2904, 792 DOI 10.17487/RFC2904, August 2000, 793 . 795 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 796 Levkowetz, Ed., "Extensible Authentication Protocol 797 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 798 . 800 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 801 "SEcure Neighbor Discovery (SEND)", RFC 3971, 802 DOI 10.17487/RFC3971, March 2005, 803 . 805 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 806 RFC 3972, DOI 10.17487/RFC3972, March 2005, 807 . 809 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 810 "Multicast Security (MSEC) Group Key Management 811 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 812 . 814 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 815 Kerberos Network Authentication Service (V5)", RFC 4120, 816 DOI 10.17487/RFC4120, July 2005, 817 . 819 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 820 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 821 January 2006, . 823 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 824 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 825 2006, . 827 [RFC4640] Patel, A., Ed. and G. Giaretta, Ed., "Problem Statement 828 for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 829 DOI 10.17487/RFC4640, September 2006, 830 . 832 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 833 Pre-Shared Key Extensible Authentication Protocol (EAP) 834 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 835 . 837 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 838 Authorization, and Accounting (AAA) Key Management", 839 BCP 132, RFC 4962, DOI 10.17487/RFC4962, July 2007, 840 . 842 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 843 and A. Yegin, "Protocol for Carrying Authentication for 844 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 845 May 2008, . 847 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 848 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 849 March 2008, . 851 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 852 and A. Bierman, Ed., "Network Configuration Protocol 853 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 854 . 856 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 857 Bormann, "Neighbor Discovery Optimization for IPv6 over 858 Low-Power Wireless Personal Area Networks (6LoWPANs)", 859 RFC 6775, DOI 10.17487/RFC6775, November 2012, 860 . 862 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 863 Constrained-Node Networks", RFC 7228, 864 DOI 10.17487/RFC7228, May 2014, 865 . 867 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 868 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 869 Transport Layer Security (TLS) and Datagram Transport 870 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 871 June 2014, . 873 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 874 Application Protocol (CoAP)", RFC 7252, 875 DOI 10.17487/RFC7252, June 2014, 876 . 878 [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 879 Architecture for Network Roaming", RFC 7593, 880 DOI 10.17487/RFC7593, September 2015, 881 . 883 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 884 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 885 . 887 [SEP2.0] ZigBee Alliance, "ZigBee IP Specification", March 2014, 888 . 891 [simplekey] 892 Bergmann, O., Gerdes, S., and C. Bormann, "Simple Keys for 893 Simple Smart Objects", Smart Object Security Workshop, 894 IETF 83 , March 2012. 896 [SimplePairing] 897 Bluetooth, SIG, "Simple pairing whitepaper", Technical 898 report , 2007. 900 [threadcommissioning] 901 White Paper, "Thread Commissioning", Thread Group, Inc. , 902 2015. 904 [TS33220] 3GPP, "3rd Generation Partnership Project; Technical 905 Specification Group Services and System Aspects; Generic 906 Authentication Architecture (GAA); Generic Bootstrapping 907 Architecture (GBA) (Release 14)", December 2016, 908 . 910 [vendorcert] 911 IEEE std. 802.1ar-2009, "Standard for local and 912 metropolitan area networks - secure device identity", 913 December 2009. 915 [vermillard] 916 Vermillard, J., "Bootstrapping device security with 917 lightweight M2M", Appeared on blog at medium.com , 918 February 2015. 920 [wps] IEEE Standard, "Wi-fi protected setup", Wi-Fi Alliance , 921 2007. 923 Authors' Addresses 925 Behcet Sarikaya 926 Denpel Informatique 928 Email: sarikaya@ieee.org 930 Mohit Sethi 931 Ericsson 932 Hirsalantie 11 933 Jorvas 02420 934 Finland 936 Email: mohit@piuha.net 938 Dan Garcia-Carillo 939 Odin Solutions, S.L 940 Murcia 30820 941 Spain 943 Email: dan.garcia@um.es