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