idnits 2.17.1 draft-irtf-t2trg-secure-bootstrapping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (April 07, 2021) is 1114 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-emu-eap-noob-03 == Outdated reference: A later version (-21) exists of draft-ietf-emu-eap-tls13-13 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Sethi 3 Internet-Draft Ericsson 4 Intended status: Informational B. Sarikaya 5 Expires: October 9, 2021 Denpel Informatique 6 D. Garcia-Carrillo 7 University of Oviedo 8 April 07, 2021 10 Secure IoT Bootstrapping: A Survey 11 draft-irtf-t2trg-secure-bootstrapping-00 13 Abstract 15 This draft provides an overview of the various terms that are used 16 when discussing bootstrapping of IoT devices. We document terms that 17 have been used within the IETF as well as other standards bodies. We 18 investigate if the terms refer to the same phenomena or have subtle 19 differences. We provide recommendations on the applicability of 20 terms in different contexts. Finally, this document presents a 21 survey of secure bootstrapping mechanisms available for smart objects 22 that are part of an Internet of Things (IoT) network. The survey 23 does not prescribe any one mechanism and rather presents IoT 24 developers with different options to choose from, depending on their 25 use-case, security requirements, and the user interface available on 26 their IoT devices. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 9, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Usage of bootstrapping terminology in standards . . . . . . . 4 65 3.1. Device Provisioning Protocol (DPP) . . . . . . . . . . . 4 66 3.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) . . . 5 67 3.3. Open Connectivity Foundation (OCF) . . . . . . . . . . . 6 68 3.4. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.5. Fast IDentity Online (FIDO) alliance . . . . . . . . . . 7 70 3.6. Internet Engineering Task Force (IETF) . . . . . . . . . 8 71 3.6.1. Enrollment over Secure Transport (EST) . . . . . . . 8 72 3.6.2. Bootstrapping Remote Secure Key Infrastructures 73 (BRSKI) . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.6.3. Secure Zero Touch Provisioning . . . . . . . . . . . 9 75 3.6.4. Nimble out-of-band authentication for EAP (EAP-NOOB) 9 76 4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Classification of available mechanisms . . . . . . . . . . . 10 79 7. IoT Device Bootstrapping Methods . . . . . . . . . . . . . . 11 80 7.1. Managed Methods . . . . . . . . . . . . . . . . . . . . . 12 81 7.1.1. Bootstrapping in LPWAN . . . . . . . . . . . . . . . 13 82 7.2. Peer-to-Peer or Ad-hoc Methods . . . . . . . . . . . . . 14 83 7.3. Leap-of-faith/Opportunistic Methods . . . . . . . . . . . 16 84 7.4. Hybrid Methods . . . . . . . . . . . . . . . . . . . . . 16 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 88 11. Informative References . . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 91 1. Introduction 93 We informally define bootstrapping as "any process that takes place 94 before a device can become operational". While bootstrapping is 95 necessary for all computing devices, until recently, most of our 96 devices typically had sufficient computing power and user interface 97 (UI) for ensuring somewhat smooth operation. For example, a typical 98 laptop device required the user to setup a username/password as well 99 as enter network settings for Internet connectivity. Following these 100 steps ensured that the laptop was fully operational. 102 The problem of bootstrapping is however exacerbated for Internet of 103 Things (IoT) networks. The size of an IoT network varies from a 104 couple of devices to tens of thousands, depending on the application. 105 Smart objects/things/devices in IoT networks are produced by a 106 variety of vendors and are typically heterogeneous in terms of the 107 constraints on their power supply, communication capability, 108 computation capacity, and user interfaces available. This problem of 109 bootstrapping in IoT was identified by Sethi et al. [Sethi14] while 110 developing a bootstrapping solution for smart displays. Although 111 this document focuses on bootstrapping terminology and methods for 112 IoT devices, we do not exclude bootstrapping related terminology used 113 in other contexts. 115 Bootstrapping devices typically also involves providing them with 116 some sort of network connectivity. Indeed, the functionality of a 117 disconnected device is rather limited. Bootstrapping devices often 118 assumes that some network has been setup a-priori. Setting up and 119 maintaining a network itself is challenging. For example, users may 120 need to configure the network name (called as Service Set Identifier 121 (SSID) in Wi-Fi networks) and passpharse before new devices can be 122 bootstrapped. Specifications such as the Wi-Fi Alliance Simple 123 Configuration [simpleconn] help users setup networks. However, this 124 document is only focused on terminology and processes associated with 125 bootstrapping devices and excludes any discussion on setting up 126 networks before devices can be bootstrapped. 128 In addition to our informal definition, it is helpful to look at 129 other definitions of bootstrapping. The IoT@Work project defines 130 bootstrapping in the context of IoT as "the process by which the 131 state of a device, a subsystem, a network, or an application changes 132 from not operational to operational" [iotwork]. Vermillard 133 [vermillard], on the other hand, describes bootstrapping as the 134 procedure by which an IoT device gets the URLs and secret keys for 135 reaching the necessary servers. Vermillard notes that the same 136 process is useful for re-keying, upgrading the security schemes, and 137 for redirecting the IoT devices to new servers. 139 There are several terms that have often been used in the context of 140 bootstrapping: 142 o Bootstrapping 144 o Provisioning 146 o Onboarding 148 o Enrollment 150 o Commissioning 152 o Initialization 154 o Configuration 156 o Registration 158 o Discovery 160 We attempt to find out whether all these terms refer to the same 161 phenomena. We begin by looking at how these terms have been used in 162 various standards and standardization bodies in Section 3. We then 163 summarize our understanding in Section 4, and provide our 164 recommendations on their usage in Section 5. Section 6 provides a 165 taxonomy of bootstrapping methods and Section 7 categorizes methods 166 according to the taxonomy. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in BCP 14 173 [RFC2119][RFC8174]. 175 3. Usage of bootstrapping terminology in standards 177 To better understand bootstrapping related terminology, let us first 178 look at the terms used by some existing specifications: 180 3.1. Device Provisioning Protocol (DPP) 182 The Wi-Fi Alliance Device provisioning protocol (DPP) [dpp] describes 183 itself as a standardized protocol for providing user friendly Wi-Fi 184 setup while maintaining or increasing the security. DPP relies on a 185 configurator, e.g. a smartphone application, for setting up all other 186 devices, called enrollees, in the network. DPP has the following 187 three phases/sub-protocols: 189 o Bootstrapping: The configurator obtains bootstrapping information 190 from the enrollee using an out-of-band channel such as scanning a 191 QR code or tapping NFC. The bootstrapping information includes 192 the public-key of the device and metadata such as the radio 193 channel on which the device is listening. 195 o Authentication: In DPP, either the configurator or the enrollee 196 can initiate the authentication protocol. The side initiating the 197 authentication protocol is called as the initiator while the other 198 side is called the responder. The authentication sub-protocol 199 provides authentication of the responder to an initiator. It can 200 optionally authenticate the initiator to the responder (only if 201 the bootstrapping information was exchange out-of-band in both 202 directions). 204 o Configuration: Using the key established from the authentication 205 protocol, the enrollee asks the configurator for network 206 information such as the SSID and passphrase of the access point. 208 3.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) 210 The OMA LwM2M specification [oma] defines an architecture where a new 211 device (LwM2M client) contacts a Bootstrap-server which is 212 responsible for "provisioning" essential information such as 213 credentials. After receiving this essential information, the LwM2M 214 client device "registers" itself with one or more LwM2M Servers which 215 will manage the device during its lifecycle. The current standard 216 defines the following four bootstrapping modes: 218 o Factory Bootstrap: An IoT device in this case is configured with 219 all the necessary bootstrap information during manufacturing and 220 prior to its deployment. 222 o Bootstrap from Smartcard: An IoT device retrieves and processes 223 all the necessary bootstrap data from a Smartcard. 225 o Client Initiated Bootstrap: This mode provides a mechanism for an 226 IoT client device to retrieve the bootstrap information from a 227 Bootstrap Server. This requires the client device to have an 228 account at the Bootstrap Server and credentials to obtain the 229 necessary information securely. 231 o Server Initiated Bootstrap: In this bootstrapping mode, the 232 bootstrapping server configures all the bootstrap information on 233 the IoT device without receiving a request from the client. This 234 means that the bootstrap server needs to know if a client IoT 235 Device is ready for bootstrapping before it can be configured. 236 For example, a network may inform the bootstrap server of a new 237 connecting IoT client device. 239 3.3. Open Connectivity Foundation (OCF) 241 The Open Connectivity Foundation (OCF) [ocf] defines the process 242 before a device is operational as onboarding. The first step of this 243 onboarding process is "configuring" the ownership, i.e., establishing 244 a legitimate user that owns the device. For this, the user is 245 supposed to use an Onboarding tool (OBT) and an Owner Transfer 246 Methods (OTM). 248 The OBT is described as a logical entity that may be implemented on a 249 single or multiple entities such as a home gateway, a device 250 management tool, etc. OCF lists several optional OTMs. At the end 251 of the execution of an OTM, the onboarding tool must have 252 "provisioned" an Owner Credential onto the device. The following 253 owner transfer methods are specified: 255 o Just works: Performs an un-authenticated Diffie-Hellman key 256 exchange over Datagram Transport Layer Security (DTLS). The key 257 exchange results in a symmetric session key which is later used 258 for provisioning. Naturally, this mode is vulnerable to Man-in- 259 The-Middle (MiTM) attackers. 261 o Random PIN: The device generates a PIN code that is entered into 262 the onboarding tool by the user. This pin code is used together 263 with TLS-PSK ciphersuites for establishing a symmetric session 264 key. OCF recommends PIN codes to have an entropy of 40 bits. 266 o Manufacturer certificate: An onboarding tool authenticates the 267 device by verifying a manufacturer installed certificate. 268 Similarly, the device may authenticate the onboarding tool by 269 verifying its signature. 271 o Vendor specific: Vendors implement their own transfer method that 272 accommodates any specific device constraints. 274 Once the onboarding tool and the new device have authenticated and 275 established secure communication, the onboarding tool 276 "provisions"/"configures" the device with Owner credentials. Owner 277 credentials may consist of certificates, shared keys, or Kerberos 278 tickets for example. 280 The OBT additionally configures/provisions information about the 281 Access Management Service (AMS), the Credential Management Service 282 (CMS), and the credentials for interacting with them. The AMS is 283 responsible for provisioning access control entries, while the CMS 284 provisions security credentials necessary for device operation. 286 3.4. Bluetooth 288 Bluetooth mesh provisioning. Beacons for discovery. Public-key 289 exchange followed by authentication. Finally provisioning of the 290 network key and unicast address. To be expanded. 292 3.5. Fast IDentity Online (FIDO) alliance 294 The Fast IDentity Online Alliance (FIDO) is currently specifying an 295 automatic onboarding protocol for IoT devices [fidospec]. The goal 296 of this protocol is to provide a new IoT device with information for 297 interacting securely with an online IoT platform. This protocol 298 allows owners to choose the IoT platform for their devices at a late 299 stage in the device lifecyle. The draft specification refers to this 300 feature as "late binding". 302 The FIDO IoT protocol itself is composed of one Device Initialization 303 (DI) protocol and 3 Transfer of Ownership (TO) protocols TO0, TO1, 304 TO2. Protocol messages are encoded in Concise Binary Object 305 Representation (CBOR) [RFC8949] and can be transported over 306 application layer protocols such as Constrained Application Protocol 307 (CoAP) [RFC7252] or directly over TCP, Bluetooth etc. FIDO IoT 308 however assumes that the device already has IP connectivity to a 309 rendezvous server. Establishing this initial IP connectivity is 310 explicitly stated as "out-of-scope" but the draft specification hints 311 at the usage of Hypertext Transfer Protocol (HTTP) [RFC7230] proxies 312 for IP networks and other forms of tunneling for non-IP networks. 314 The specification only provides a non-normative example of the DI 315 protocol which must be executed in the factory during device 316 manufacture. This protocol embeds initial ownership and 317 manufacturing credentials into Restricted Operation Environment (ROE) 318 on the device. The initial information embedded also includes a 319 unique device identifier (called as GUID in the specification). 320 After DI is executed, the manufacturer has an ownership voucher which 321 is passed along the supply chain to the device owner. 323 When a device is unboxed and powered on by the new owner, the device 324 discovers a network-local or an Internet-based rendezvous server. 325 Protocols (TO0, TO1, and TO2) between the device, the rendezvous 326 server, and the new owner (as the owner onboarding service) ensure 327 that the device and the new owner are able to authenticate each 328 other. Thereafter, the new owner establishes cryptographic control 329 of the device and provides it with credentials of the IoT platform 330 which the device should used. 332 3.6. Internet Engineering Task Force (IETF) 334 In this section, we will look at some IETF standards and draft 335 specifications related to IoT bootstrapping. 337 3.6.1. Enrollment over Secure Transport (EST) 339 Enrollment over Secure Transport (EST) [RFC7030] defines a profile of 340 Certificate Management over CMS (CMC) [RFC5272]. EST relies on 341 Hypertext Transfer Protocol (HTTP) and Transport Layer Security (TLS) 342 for exchanging CMC messages and allows client devices to obtain 343 client certificates and associated Certification Authority (CA) 344 certificates. A companion specification for using EST over secure 345 CoAP has also been standardized [I-D.ietf-ace-coap-est]. EST assumes 346 that some initial information is already distributed so that EST 347 client and servers can perform mutual authentication before 348 continuing with protocol. [RFC7030] further defines "Bootstrap 349 Distribution of CA Certificates" which allows minimally configured 350 EST clients to obtain initial trust anchors. It relies on human 351 users to verify information such as the CA certificate "fingerprint" 352 received over the unauthenticated TLS connection setup. After 353 successful completion of this bootstrapping step, clients can proceed 354 to the enrollment step during which they obtain client certificates 355 and associated CA certificates. 357 3.6.2. Bootstrapping Remote Secure Key Infrastructures (BRSKI) 359 The ANIMA working group is working on a bootstrapping solution for 360 devices that relies on 802.1AR vendor certificates called 361 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 362 [I-D.ietf-anima-bootstrapping-keyinfra]. In addition to vendor 363 installed IEEE 802.1AR certificates, a vendor based service on the 364 Internet is required. Before being authenticated, a new device only 365 needs link-local connectivity, and does not require a routable 366 address. When a vendor provides an Internet based service, devices 367 can be forced to join only specific domains. The document highlights 368 that the described solution is aimed in general at non-constrained 369 (i.e. class 2+ defined in [RFC7228]) devices operating in a non- 370 challenged network. It claims to scale to thousands of devices 371 located in hostile environments, such as ISP provided CPE devices 372 which are drop-shipped to the end user. 374 3.6.3. Secure Zero Touch Provisioning 376 [RFC8572] defines a bootstrapping strategy for enabling devices to 377 securely obtain all the configuration information with no installer 378 input, beyond the actual physical placement and connection of cables. 379 Their goal is to enable a secure NETCONF [RFC6241] or RESTCONF 380 [RFC8040] connection to the deployment specific network management 381 system (NMS). This bootstrapping method requires the devices to be 382 configured with trust anchors in the form of X.509 certificates. 383 [RFC8572] is similar to BRSKI based on [RFC8366]. 385 3.6.4. Nimble out-of-band authentication for EAP (EAP-NOOB) 387 EAP-NOOB [I-D.ietf-emu-eap-noob] defines an EAP method where the 388 authentication is based on a user-assisted out-of-band (OOB) channel 389 between the server and peer. It is intended as a generic 390 bootstrapping solution for IoT devices which have no pre-configured 391 authentication credentials and which are not yet registered on the 392 authentication server. This method claims to be more generic than 393 most ad-hoc bootstrapping solutions in that it supports many types of 394 OOB channels. The exact in-band messages and OOB message contents 395 are specified and not the OOB channel details. EAP-NOOB also 396 supports IoT devices with only output (e.g. display) or only input 397 (e.g. camera). It makes combined use of both secrecy and integrity 398 of the OOB channel for more robust security than the ad-hoc 399 solutions. 401 4. Comparison 403 There are several stages before a device becomes fully operational. 404 This typically involves establishing some initial trust after which 405 credentials and other parameters are configured. For DPP, 406 bootstrapping is the first step before authentication and 407 provisioning of credentials can occur. For EST, bootstrapping 408 happens as the first step when the client devices have no 409 certificates available for starting enrollment. Provisioning/ 410 configuring are terms used for providing additional information to 411 devices before they are fully operational. For example, credentials 412 are provisioned onto the device. But before credential provisioning, 413 a device is bootstrapped and authenticated. Some protocols may only 414 deal with parts of the process. For example, TLS maybe used for 415 authentication after bootstrapping. A separate device management 416 protocol then may run over this TLS tunnel for provisioning 417 operational information and credentials. 419 5. Recommendations 421 o It is recommended that the IETF use the term "bootstrapping" for 422 the initial (authentication) step that a device must perform. 423 Bootstrapping will likely happen before the device has obtained 424 full network connectivity. 426 o It is recommended to use the term "provisioning"/"configuring" for 427 the process of providing necessary information to a device to 428 become operational after initial authentication is complete. As 429 is evident from above, provisioning and configuring may include 430 bootstrapping and authentication as a sub protocol. 432 o IETF specifications should aim to avoid mixing terminology or 433 adding new terminology for better consistency. 435 6. Classification of available mechanisms 437 Given the large number of bootstrapping protocols and related 438 specifications, it can be helpful to classify them. We categorize 439 the available bootstrapping solutions into the following major 440 classes: 442 o Managed methods: These methods rely on pre-established trust 443 relations and authentication credentials. They typically utilize 444 centralized servers for authentication, although several such 445 servers may join to form a distributed federation. Example 446 methods include Extensible Authentication Protocol (EAP) 447 [RFC3748], Generic Bootstrapping Architecture (GBA) [TS33220], 448 Kerberos [RFC4120], Bootstrapping Remote Secure Key 449 Infrastructures (BRSKI) and vendor certificates [vendorcert]. EAP 450 Transport Layer Security EAP-TLS [I-D.ietf-emu-eap-tls13] for 451 instance assumes that both the client and the server have 452 certificates to authenticate each other. Based on this 453 authentication, the server authorizes the client for network 454 access. The Eduroam federation [RFC7593] uses a network of such 455 servers to support roaming clients. 457 o Opportunistic and leap-of-faith methods: In these methods, rather 458 than verifying the initial authentication, the continuity of the 459 initial identity or connection is verified. Some of these methods 460 assume that the attacker is not present during the initial setup. 461 Example methods include Secure Neighbor Discovery (SEND) [RFC3971] 462 and Cryptographically Generated Addresses (CGA) [RFC3972], Wifi 463 Protected Setup (WPS) push button [wps], and Secure Shell (SSH) 464 [RFC4253]. 466 o Peer-to-Peer (P2P) and Ad-hoc methods: These bootstrapping methods 467 do not rely on any pre-established credentials. Instead, the 468 bootstrapping protocol results in credentials being established 469 for subsequent secure communication. Such bootstrapping methods 470 typically perform an unauthenticated Diffie-Hellman exchange [dh] 471 and then use an out-of-band (OOB) communication channel to prevent 472 a man-in-the-middle attack (MitM). Various secure device pairing 473 protocols fall in this category. Based on how the OOB channel is 474 used, the P2P methods can be further classified into two sub 475 categories: 477 * Key derivation: Contextual information received over the OOB 478 channel is used for shared key derivation. For example, 479 [proximate] relies on the common radio environment of the 480 devices being paired to derive the shared secret which would 481 then be used for secure communication. 483 * Key confirmation: A Diffie-Hellman key exchange occurs over the 484 insecure network and the established key is used to 485 authenticate with the help of the OOB channel. For example, 486 Bluetooth simple pairing [SimplePairing] use the OOB channel to 487 ask the user to compare pins and approve the completed 488 exchange. 490 o Hybrid methods: Most deployed methods are hybrid and use 491 components from both managed and ad-hoc methods. For instance, 492 central management may be used for devices after they have been 493 registered with the server using ad-hoc registration methods. 495 It is important to note here that categorization of different methods 496 is not always easy or clear. For example, all the opportunistic and 497 leap-of-faith methods become managed methods after the initial 498 vulnerability window. The choice of bootstrapping method used for 499 devices depends heavily on the business case. Questions that may 500 govern the choice include: What third parties are available? Who 501 wants to retain control or avoid work? In each category, there are 502 many different methods of secure bootstrapping available. The choice 503 of the method may also be governed by the type of device being 504 bootstrapped. 506 7. IoT Device Bootstrapping Methods 508 In this section we look at additional bootstrapping protocols for IoT 509 devices which are not covered in Section 3. Protocols already 510 covered in Section 3 however are mentioned in their respective 511 classes. This list is non-exhaustive. 513 7.1. Managed Methods 515 EAP-TLS is a widely used EAP method for network access authentication 516 [I-D.ietf-emu-eap-tls13]. It requires certificate-based mutual 517 authentication and a public key infrastructure. The ZigBee Alliance 518 has specified an IPv6 stack for IEEE 802.15.4 [IEEE802.15.4] devices 519 used in smart meters developed primarily for SEP 2.0 (Smart Energy 520 Profile) application layer traffic [SEP2.0]. The ZigBee IP stack 521 uses EAP-TLS for secure bootstrapping of devices. 523 EAP-PSK [RFC4764] is another EAP method that realizes mutual 524 authentication and session key derivation using a Pre-Shared Key 525 (PSK). Given the light-weight nature of EAP-PSK, it can be suitable 526 for resource-constrained devices. However, secure distribution of a 527 large number of PSKs can be challenging. 529 CoAP-EAP [I-D.marin-ace-wg-coap-eap] defines a bootstrapping service 530 for IoT. The authors propose transporting EAP over CoAP [RFC7252] 531 for the constrained link, and communication with AAA infrastructures 532 in the non-constrained link. While the draft discusses the use of 533 EAP-PSK, the authors claim that they are specifying a new EAP lower 534 layer and any EAP method which results in generation is suitable. 536 Protocol for Carrying Authentication for Network Access (PANA) 537 [RFC5191] is a network layer protocol with which a node can 538 authenticate itself to gain access to the network. PANA does not 539 define a new authentication protocol and rather uses EAP over User 540 Datagram Protocol (UDP) for authentication. 542 Colin O'Flynn [I-D.oflynn-core-bootstrapping] proposes the use of 543 PANA for secure bootstrapping of resource constrained devices. He 544 demonstrates how a 6LowPAN Border Router (PANA Authentication Agent 545 (PAA)) can authenticate the identity of a joining constrained device 546 (PANA Client). Once the constrained device has been successfully 547 authenticated, the border router can also provide network and 548 security parameters to the joining device. 550 Hernandez-Ramos et al. [panaiot] also use EAP-TLS over PANA for 551 secure bootstrapping of smart objects. They extend their 552 bootstrapping scheme for configuring additional keys that are used 553 for secure group communication. 555 Generic Bootstrapping Architecture (GBA) is another bootstrapping 556 method that falls in centralized category. GBA is part of the 3GPP 557 standard [TS33220] and is based on 3GPP Authentication and Key 558 Agreement (3GPP AKA). GBA is an application independent mechanism to 559 provide a client application (running on the User equipment (UE)) and 560 any application server with a shared session secret. This shared 561 session secret can subsequently be used to authenticate and protect 562 the communication between the client application and the application 563 server. GBA authentication is based on the permanent secret shared 564 between the UE's Universal Integrated Circuit Card (UICC), for 565 example SIM card, and the corresponding profile information stored 566 within the cellular network operator's Home Subscriber System (HSS) 567 database. [I-D.sethi-gba-constrained] describes a resource- 568 constrained adaptation of GBA for IoT. 570 The four bootstrapping modes specified by the Open Mobile Alliance 571 (OMA) Light-weight M2M (LwM2M) standard require some sort of pre- 572 provisioned credentials on the device. All the four modes are 573 examples of managed bootstrapping methods. 575 The Kerberos protocol [RFC4120] is a network authentication protocol 576 that allows several endpoints to communicate over an insecure 577 network. Kerberos relies on a symmetric cryptography scheme and 578 requires a trusted third party, that guarantees the identities of the 579 various actors. It relies on the use of "tickets" for nodes to prove 580 identity to one another in a secure manner. There has been research 581 work on using Kerberos for IoT devices [kerberosiot]. 583 It is also important to mention some of the work done on implicit 584 certificates and identity-based cryptographic schemes [himmo], 585 [implicit]. While these are interesting and novel schemes that can 586 be a part of securely bootstrapping devices, at this point, it is 587 hard to speculate on whether such schemes would see large-scale 588 deployment in the future. 590 7.1.1. Bootstrapping in LPWAN 592 Low Power Wide Area Network (LPWAN) encompasses a wide variety of 593 technologies whose link-layer characteristics are severely 594 constrained in comparison to other typical IoT link-layer 595 technologies such as Bluetooth or IEEE 802.15.4. While some LPWAN 596 technologies rely on proprietary bootstrapping solutions which are 597 not publicly accessible, others simply ignore the challenge of 598 bootstrapping and key distribution. In this section, we discuss the 599 bootstrapping methods used by LPWAN technologies covered in 600 [RFC8376]. 602 o LoRaWAN [LoRaWAN] describes its own protocol to authenticate nodes 603 before allowing them join a LoRaWAN network. This process is 604 called as joining and it is based on pre-shared keys (called 605 AppKeys in the standard). The joining procedure comprises only 606 one exchange (join-request and join-accept) between the joining 607 node and the network server. There are several adaptations to 608 this joining procedure that allow network servers to delegate 609 authentication and authorization to a backend AAA infrastructure 610 [RFC2904]. 612 o Wi-SUN Alliance Field Area Network (FAN) uses IEEE 802.1X and EAP- 613 TLS for network access authentication. It performs a 4-way 614 handshake to establish a session keys after EAP-TLS 615 authentication. 617 o NB-IoT relies on the traditional 3GPP mutual authentication scheme 618 based on a shared-secret in the Subscriber Identity Module (SIM) 619 of the device and the mobile operator. 621 o Sigfox security is based on unique device identifiers and 622 cryptographic keys. As stated in [RFC8376], although the 623 algorithms and keying details are not publicly available, there is 624 sufficient information to indicate that bootstrapping in Sigfox is 625 based on pre-established credentials between the device and the 626 Sigfox network. 628 From the above, it is clear that all LPWAN technologies rely on pre- 629 provisioned credentials for authentication between a new device and 630 the network. Thus, all of them can be categorized as managed 631 bootstrapping methods. 633 7.2. Peer-to-Peer or Ad-hoc Methods 635 While managed methods are viable for many IoT devices, they may not 636 be suitable or desirable in all scenarios. All the managed methods 637 assume that some credentials are provisioned into the device. These 638 credentials may be in the device micro-controller or in a replaceable 639 smart card such as a SIM card. The methods also sometimes assume 640 that the manufacturer embeds these credentials during the device 641 manufacture on the factory floor. However, in many cases the 642 manufacturer may not have sufficient incentive to do this. In other 643 scenarios, it may be hard to completely trust and rely on the device 644 manufacturer to securely perform this task. Therefore, many times, 645 P2P or Ad-hoc methods of bootstrapping are used. We discuss a few 646 example next. 648 P2P or ad-hoc bootstrapping methods are used for establishing keys 649 and credential information for secure communication without any pre- 650 provisioned information. These bootstrapping mechanisms typically 651 rely on an out-of-band (OOB) channel in order to prevent man-in-the- 652 middle (MitM) attacks. P2P and ad-hoc methods have typically been 653 used for securely pairing personal computing devices such as smart 654 phones. [devicepairing] provides a survey of such secure device 655 pairing methods. Many original pairing schemes required the user to 656 enter the same key string or authentication code to both devices or 657 to compare and approve codes displayed by the devices. While these 658 methods can provide reasonable security, they require user 659 interaction that is relatively unnatural and often considered a 660 nuisance. Thus, there is ongoing research for more natural ways of 661 pairing devices. To reduce the amount of user-interaction required 662 in the pairing process, several proposals use contextual or location- 663 dependent information, or natural user input such as sound or 664 movement, for device pairing [proximate]. 666 The local association created between two devices may later be used 667 for connecting/introducing one of the devices to a centralized 668 server. Such methods would however be classified as hybrids. 670 EAP-NOOB [I-D.ietf-emu-eap-noob] is an example of P2P and ad-hoc 671 bootstrapping method that establishes a security association between 672 an IoT device (node) and an online server (unlike pairing two devices 673 for local connections over WiFi or Bluetooth). 675 Thread Group commissioning [threadcommissioning] introduces a two 676 phased process i.e. Petitioning and Joining. Entities involved are 677 leader, joiner, commissioner, joiner router and border router. 678 Leader is the first device in Thread network that must be 679 commissioned using out-of-band process and is used to inject correct 680 user generated Commissioning Credentials (can be changed later) into 681 Thread Network. Joiner is the node that intends to get authenticated 682 and authorized on Thread Network. Commissioner is either within the 683 Thread Network (Native) or connected with Thread Network via a WLAN 684 (External). 686 Under some topologies, Joiner Router and Border Router facilitate the 687 Joiner node to reach Native and External Commissioner, respectively. 688 Petitioning begins before Joining process and is used to grant sole 689 commissioning authority to a Commissioner. After an authorized 690 Commissioner is designated, eligible thread devices can join network. 691 Pair-wise key is shared between Commissioner and Joiner, network 692 parameters (such as network name, security policy, etc.,) are sent 693 out securely (using pair-wise key) by Joiner Router to Joiner for 694 letting Joiner to join the Thread Network. Entities involved in 695 Joining process depends on system topology i.e. location of 696 Commissioner and Joiner. Thread networks only operate using IPv6. 697 Thread devices can devise GUAs (Global Unicast Addresses) [RFC4291]. 698 Provision also exist via Border Router, for Thread device to acquire 699 individual global address by means of DHCPv6 or using SLAAC 700 (Stateless Address Autoconfiguration) address derived with advertised 701 network prefix. 703 7.3. Leap-of-faith/Opportunistic Methods 705 Bergmann et al. [simplekey] develop a secure bootstrapping mechanism 706 that does not rely on pre-provisioned credentials using resurrecting- 707 duckling imprinting scheme. Their bootstrapping protocol involves 708 three distinct phases: discover (the duckling node searches for 709 network nodes that can act as mother node), imprint (the mother node 710 imprints a shared secret establishing a secure channel once a 711 positive response is received for the imprinting request) and 712 configure (additional configuration information such as network 713 prefix and default gateway are configured). In this model for 714 bootstrapping, a small initial vulnerability window is acceptable and 715 can be mitigated using techniques such as a Faraday Cage (securing 716 the communication physically) to protect the environment of the 717 mother and duck nodes, though this may be inconvenient for the user. 719 7.4. Hybrid Methods 721 [RFC7250] defines how raw public keys can be used for mutual 722 authentication of devices and servers. The extension specified in 723 [RFC7250] simplifies client_certificate_type and 724 server_certificate_type to carry only SubjectPublicKeyInfo structure 725 with the raw public key instead of many other parameters found in 726 typical X.509 version 3 certificates. Each side validates the keys 727 received with pre-configured values stored. Using raw public keys 728 for bootstrapping can be seen as a hybrid method. This is because it 729 generally requires an out-of-band (OOB) step (P2P/Ad-hoc) where the 730 raw public keys [RFC7250] are provided to the authenticating 731 entities, after which the actual authentication occurs online 732 (managed). CoAP already provides support for using raw public keys 733 (see Section 9.1.3.2. of [RFC7252]) 735 8. Security Considerations 737 This draft does not take any posture on the security properties of 738 the different bootstrapping protocols discussed. Specific security 739 considerations of bootstrapping protocols are present in the 740 respective specifications. 742 Nonetheless, we briefly discuss some important security aspects which 743 are not fully explored in various specifications. 745 Firstly, an IoT system may deal with authorization for resources and 746 services separately from bootstrapping and authentication in terms of 747 timing as well as protocols. As an example, two resource-constrained 748 devices A and B may perform mutual authentication using credentials 749 provided by an offline third-party X before device A obtains 750 authorization for running a particular application on device B from 751 an online third-party Y. In some cases, authentication and 752 authorization maybe tightly coupled, e.g., successful authentication 753 also means successful authorization. 755 Secondly, re-bootstrapping of IoT devices may be required since keys 756 have limited lifetimes and devices may be lost or resold. Protocols 757 and systems must have adequate provisions for revocation and re- 758 bootstrapping. Re-bootstrapping must be as secure as the initial 759 bootstrapping regardless of whether this re-bootstrapping is done 760 manually or automatically over the network. 762 Lastly, some IoT networks use a common group key for multicast and 763 broadcast traffic. As the number of devices in a network increase 764 over time, a common group key may not be scalable and the same 765 network may need to be split into separate groups with different 766 keys. Bootstrapping and provisioning protocols may need appropriate 767 mechanisms for identifying and distributing keys to the current 768 member devices of each group. 770 9. IANA Considerations 772 There are no IANA considerations for this document. 774 10. Acknowledgements 776 We would like to thank Tuomas Aura, Hannes Tschofenig, and Michael 777 Richardson for providing extensive feedback as well as Rafa Marin- 778 Lopez for his support. 780 11. Informative References 782 [devicepairing] 783 Mirzadeh, S., Cruickshank, H., and R. Tafazolli, "Secure 784 Device Pairing: A Survey", IEEE Communications Surveys and 785 Tutorials , pp. 17-40, 2014. 787 [dh] Diffie, W. and M. Hellman, "New directions in 788 cryptography", IEEE Transactions on Information Theory , 789 vol. 22, no. 6, pp. 644-654, 1976. 791 [dpp] Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol 792 (DPP)", Wi-Fi Alliance Specification version 1.1, 2018, 793 . 797 [fidospec] 798 Fast Identity Online Alliance, "FIDO IoT Spec", Fido 799 Alliance Version: 1.0, August 2020, 800 . 803 [himmo] Garcia-Morchon, O., Rietman, R., Sharma, S., Tolhuizen, 804 L., and J. Torre-Arce, "DTLS-HIMMO: Efficiently Securing a 805 Post-Quantum World with a Fully-Collusion Resistant KPS", 806 Submitted to NIST Workshop on Cybersecurity in a Post- 807 Quantum World , version 20141225:065757, December 2014, 808 . 810 [I-D.ietf-ace-coap-est] 811 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 812 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 813 est-18 (work in progress), January 2020. 815 [I-D.ietf-anima-bootstrapping-keyinfra] 816 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 817 and K. Watsen, "Bootstrapping Remote Secure Key 818 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 819 keyinfra-45 (work in progress), November 2020. 821 [I-D.ietf-emu-eap-noob] 822 Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band 823 authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap- 824 noob-03 (work in progress), December 2020. 826 [I-D.ietf-emu-eap-tls13] 827 Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3", 828 draft-ietf-emu-eap-tls13-13 (work in progress), November 829 2020. 831 [I-D.marin-ace-wg-coap-eap] 832 Marin-Lopez, R. and D. Garcia-Carrillo, "EAP-based 833 Authentication Service for CoAP", draft-marin-ace-wg-coap- 834 eap-07 (work in progress), January 2021. 836 [I-D.oflynn-core-bootstrapping] 837 Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security 838 Bootstrapping of Resource-Constrained Devices", draft- 839 oflynn-core-bootstrapping-03 (work in progress), November 840 2010. 842 [I-D.sethi-gba-constrained] 843 Sethi, M., Lehtovirta, V., and P. Salmela, "Using Generic 844 Bootstrapping Architecture with Constrained Devices", 845 draft-sethi-gba-constrained-01 (work in progress), 846 February 2014. 848 [IEEE802.15.4] 849 IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 850 Std. 802.15.4-2015, April 2016, 851 . 854 [implicit] 855 Porambage, P., Schmitt, C., Kumar, P., Gurtov, A., and M. 856 Ylianttila, "Pauthkey: A pervasive authentication protocol 857 and key establishment scheme for wireless sensor networks 858 in distributed iot applications", International Journal of 859 Distributed Sensor Networks , Hindawi Publishing 860 Corporation , 2014. 862 [iotwork] European Commission FP7, "IoT@Work bootstrapping 863 architecture Deliverable D2.2", June 2011. 865 [kerberosiot] 866 Hardjono, T., "Kerberos for Internet-of-Things", February 867 2014, . 870 [LoRaWAN] Sornin, N., Luis, M., Eirich, T., and T. Kramp, "LoRa 871 Specification V1.0", January 2015, . 875 [ocf] Open Connectivity Foundation, "OCF Security 876 Specification", Version 1.0.0, June 2017, 877 . 880 [oma] Open Mobile Alliance, "Lightweight Machine to Machine 881 Technical Specification: Core", Approved Version 1.2, 882 November 2020, 883 . 887 [panaiot] Hernandez-Ramos, J., Carrillo, D., Marin-Lopez, R., and A. 888 Skarmeta, "Dynamic Security Credentials PANA-based 889 Provisioning for IoT Smart Objects", 2nd World Forum on 890 Internet of Things (WF-IoT) , IEEE , 2015. 892 [proximate] 893 Mathur, S., Miller, R., Varshavsky, A., Trappe, W., and N. 894 Mandayam, "Proximate: proximity-based secure pairing using 895 ambient wireless signals.", Proceedings of MobiSys 896 International Conference , pp. 211-224, June 2011. 898 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 899 Requirement Levels", BCP 14, RFC 2119, 900 DOI 10.17487/RFC2119, March 1997, 901 . 903 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 904 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 905 D. Spence, "AAA Authorization Framework", RFC 2904, 906 DOI 10.17487/RFC2904, August 2000, 907 . 909 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 910 Levkowetz, Ed., "Extensible Authentication Protocol 911 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 912 . 914 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 915 "SEcure Neighbor Discovery (SEND)", RFC 3971, 916 DOI 10.17487/RFC3971, March 2005, 917 . 919 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 920 RFC 3972, DOI 10.17487/RFC3972, March 2005, 921 . 923 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 924 Kerberos Network Authentication Service (V5)", RFC 4120, 925 DOI 10.17487/RFC4120, July 2005, 926 . 928 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 929 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 930 January 2006, . 932 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 933 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 934 2006, . 936 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 937 Pre-Shared Key Extensible Authentication Protocol (EAP) 938 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 939 . 941 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 942 and A. Yegin, "Protocol for Carrying Authentication for 943 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 944 May 2008, . 946 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 947 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 948 . 950 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 951 and A. Bierman, Ed., "Network Configuration Protocol 952 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 953 . 955 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 956 "Enrollment over Secure Transport", RFC 7030, 957 DOI 10.17487/RFC7030, October 2013, 958 . 960 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 961 Constrained-Node Networks", RFC 7228, 962 DOI 10.17487/RFC7228, May 2014, 963 . 965 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 966 Protocol (HTTP/1.1): Message Syntax and Routing", 967 RFC 7230, DOI 10.17487/RFC7230, June 2014, 968 . 970 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 971 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 972 Transport Layer Security (TLS) and Datagram Transport 973 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 974 June 2014, . 976 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 977 Application Protocol (CoAP)", RFC 7252, 978 DOI 10.17487/RFC7252, June 2014, 979 . 981 [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 982 Architecture for Network Roaming", RFC 7593, 983 DOI 10.17487/RFC7593, September 2015, 984 . 986 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 987 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 988 . 990 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 991 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 992 May 2017, . 994 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 995 "A Voucher Artifact for Bootstrapping Protocols", 996 RFC 8366, DOI 10.17487/RFC8366, May 2018, 997 . 999 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 1000 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 1001 . 1003 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1004 Touch Provisioning (SZTP)", RFC 8572, 1005 DOI 10.17487/RFC8572, April 2019, 1006 . 1008 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1009 Representation (CBOR)", STD 94, RFC 8949, 1010 DOI 10.17487/RFC8949, December 2020, 1011 . 1013 [SEP2.0] ZigBee Alliance, "ZigBee IP Specification", March 2014, 1014 . 1017 [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure 1018 Bootstrapping of Cloud-Managed Ubiquitous Displays", 1019 Proceedings of ACM International Joint Conference on 1020 Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 1021 739-750, Seattle, USA, September 2014, 1022 . 1024 [simpleconn] 1025 Wi-Fi Alliance, "Wi-Fi Simple Configuration", 1026 Version 2.0.7, 2019, 1029 . 1031 [simplekey] 1032 Bergmann, O., Gerdes, S., and C. Bormann, "Simple Keys for 1033 Simple Smart Objects", Smart Object Security Workshop, 1034 IETF 83 , March 2012. 1036 [SimplePairing] 1037 Bluetooth, SIG, "Simple pairing whitepaper", Technical 1038 report , 2007. 1040 [threadcommissioning] 1041 Thread Group, "Thread Commissioning", 2015. 1043 [TS33220] 3GPP, "3rd Generation Partnership Project; Technical 1044 Specification Group Services and System Aspects; Generic 1045 Authentication Architecture (GAA); Generic Bootstrapping 1046 Architecture (GBA) (Release 14)", December 2016, 1047 . 1049 [vendorcert] 1050 IEEE std. 802.1ar-2009, "Standard for local and 1051 metropolitan area networks - secure device identity", 1052 December 2009. 1054 [vermillard] 1055 Vermillard, J., "Bootstrapping device security with 1056 lightweight M2M", Appeared on blog at medium.com , 1057 February 2015. 1059 [wps] Wi-Fi Alliance, "Wi-fi protected setup", IEEE 1060 Standard XXXXXXXTBS, 2007. 1062 Authors' Addresses 1064 Mohit Sethi 1065 Ericsson 1066 Hirsalantie 11 1067 Jorvas 02420 1068 Finland 1070 Email: mohit@piuha.net 1071 Behcet Sarikaya 1072 Denpel Informatique 1074 Email: sarikaya@ieee.org 1076 Dan Garcia-Carrillo 1077 University of Oviedo 1078 Oviedo 33207 1079 Spain 1081 Email: garciadan@uniovi.es