idnits 2.17.1 draft-irtf-t2trg-secure-bootstrapping-02.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (25 April 2022) is 725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ace-wg-coap-eap' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'IEEE802.15.4' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 781, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 786, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 795, but no explicit reference was found in the text == Unused Reference: 'RFC4253' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'RFC4764' is defined on line 808, but no explicit reference was found in the text == Unused Reference: 'RFC5191' is defined on line 813, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'RFC7593' is defined on line 853, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'RFC9190' is defined on line 895, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ace-wg-coap-eap-06 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 17 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 Aalto University 4 Intended status: Informational B. Sarikaya 5 Expires: 27 October 2022 Denpel Informatique 6 D. Garcia-Carrillo 7 University of Oviedo 8 25 April 2022 10 Terminology and processes for initial security setup of IoT devices 11 draft-irtf-t2trg-secure-bootstrapping-02 13 Abstract 15 This document provides an overview of terms that are commonly used 16 when discussing the initial security setup of Internet of Things 17 (IoT) devices. This document also presents a brief but illustrative 18 survey of protocols and standards available for initial security 19 setup of IoT devices. For each protocol, we identify the terminology 20 used, the entities involved, the initial assumptions, the processes 21 necessary for completetion, and the knowledge imparted to the IoT 22 devices after the setup is complete. 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 27 October 2022. 41 Copyright Notice 43 Copyright (c) 2022 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Standards and Protocols . . . . . . . . . . . . . . . . . . . 4 59 2.1. Device Provisioning Protocol (DPP) . . . . . . . . . . . 4 60 2.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) . . . 5 61 2.3. Open Connectivity Foundation (OCF) . . . . . . . . . . . 6 62 2.4. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.5. Fast IDentity Online (FIDO) alliance . . . . . . . . . . 9 64 2.6. Enrollment over Secure Transport (EST) . . . . . . . . . 10 65 2.7. Bootstrapping Remote Secure Key Infrastructures 66 (BRSKI) . . . . . . . . . . . . . . . . . . . . . . . . 10 67 2.8. Secure Zero Touch Provisioning . . . . . . . . . . . . . 11 68 2.9. Nimble out-of-band authentication for EAP (EAP-NOOB) . . 12 69 2.10. LPWAN . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 2.11. Thread . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 3. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 3.1. Comparison of terminology . . . . . . . . . . . . . . . . 15 73 3.2. Comparison of players . . . . . . . . . . . . . . . . . . 15 74 3.3. Comparison of initial beliefs . . . . . . . . . . . . . . 15 75 3.4. Comparison of processes . . . . . . . . . . . . . . . . . 15 76 3.5. Comparison of knowledge imparted to the device . . . . . 15 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 80 7. Informative References . . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 Initial security setup for a device refers to any process that takes 86 place before a device can become operational. The phrase "initial 87 security setup" intentionally includes the term "security" as setup 88 of devices without adequate security or with insecure processes is no 89 longer acceptable. The initial security setup process, among other 90 things, involves network discovery and selection, access 91 authentication, configuration of necessary credentials and 92 parameters. 94 Initial security setup for IoT devices is challenging because the 95 size of an IoT network varies from a couple of devices to tens of 96 thousands, depending on the application. Moreover, devices in IoT 97 networks are produced by a variety of vendors and are typically 98 heterogeneous in terms of the constraints on their power supply, 99 communication capability, computation capacity, and user interfaces 100 available. This challenge of initial security setup in IoT was 101 identified by Sethi et al. [Sethi14] while developing a solution for 102 smart displays. 104 Initial security setup of devices typically also involves providing 105 them with some sort of network connectivity. The functionality of a 106 disconnected device is rather limited. Initial security setup of 107 devices often assumes that some network has been setup a-priori. 108 Setting up and maintaining a network itself is challenging. For 109 example, users may need to configure the network name (called as 110 Service Set Identifier (SSID) in Wi-Fi networks) and passpharse 111 before new devices can be setup. Specifications such as the Wi-Fi 112 Alliance Simple Configuration [simpleconn] help users setup networks. 113 However, this document is only focused on terminology and processes 114 associated with initial security setup of devices and excludes any 115 discussion on setting up networks. 117 There are several terms that are used in the context of initial 118 security setup of devices: 120 * Bootstrapping 122 * Provisioning 124 * Onboarding 126 * Enrollment 128 * Commissioning 130 * Initialization 132 * Configuration 134 * Registration 136 * Discovery 138 In addition to using a variety of different terms, initial security 139 setup mechanisms can rely on a number of entities. For example, a 140 companion smartphone device maybe necessary for some initial security 141 setup mechanisms. Moreover, security setup procedures have diverese 142 initial assumptions about the device being setup. As an example, an 143 initial security setup mechanism may assume that the device is 144 provisioned with a pre-shared key and a list of trusted network 145 identifiers. Finally, initial security setup mechanisms impart 146 different information to the device after completion. For example, 147 some mechanisms may only provide a key for use with an authorization 148 server, while others may configure elaborate access control lists 149 directly. 151 The next section provides an overview of some standards and protocols 152 for initial security setup of IoT devices. For each mechanism, the 153 following are explicitly identified: 155 * Terminology used 157 * Entities or "players" involved 159 * Initial assumptions about the device 161 * Processes necessary for completetion 163 * Knowledge imparted to the device after completion 165 2. Standards and Protocols 167 2.1. Device Provisioning Protocol (DPP) 169 The Wi-Fi Alliance Device provisioning protocol (DPP) [dpp] describes 170 itself as a standardized protocol for providing user friendly Wi-Fi 171 setup while maintaining or increasing the security. DPP relies on a 172 configurator, e.g. a smartphone application, for setting up all other 173 devices, called enrollees, in the network. DPP has the following 174 three phases/sub-protocols: 176 * Bootstrapping: The configurator obtains bootstrapping information 177 from the enrollee using an out-of-band channel such as scanning a 178 QR code or tapping NFC. The bootstrapping information includes 179 the public-key of the device and metadata such as the radio 180 channel on which the device is listening. 182 * Authentication: In DPP, either the configurator or the enrollee 183 can initiate the authentication protocol. The side initiating the 184 authentication protocol is called as the initiator while the other 185 side is called the responder. The authentication sub-protocol 186 provides authentication of the responder to an initiator. It can 187 optionally authenticate the initiator to the responder (only if 188 the bootstrapping information was exchange out-of-band in both 189 directions). 191 * Configuration: Using the key established from the authentication 192 protocol, the enrollee asks the configurator for network 193 information such as the SSID and passphrase of the access point. 195 DPP has the following characteristics: 197 * Terms: Bootstrapping, configuration, discovery, enrollment, 198 provisioning. 200 * Players: Authenticator, Bootstrap Server, Client, Configurator, 201 Device, Initiator, Manager, Manufacturer, Owner, Peer, Peer, 202 Persona, Responder, Server, User 204 * Initial beliefs assumed in the device: 206 * Processes: 208 * Beliefs imparted to the device after protocol execution: 210 2.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) 212 The OMA LwM2M specification [oma] defines an architecture where a new 213 device (LwM2M client) contacts a Bootstrap-server which is 214 responsible for provisioning essential information such as 215 credentials. After receiving this essential information, the LwM2M 216 client device registers itself with one or more LwM2M Servers which 217 will manage the device during its lifecycle. The current standard 218 defines the following four bootstrapping modes: 220 * Factory Bootstrap: An IoT device in this case is configured with 221 all the necessary bootstrap information during manufacturing and 222 prior to its deployment. 224 * Bootstrap from Smartcard: An IoT device retrieves and processes 225 all the necessary bootstrap data from a Smartcard. 227 * Client Initiated Bootstrap: This mode provides a mechanism for an 228 IoT client device to retrieve the bootstrap information from a 229 Bootstrap Server. This requires the client device to have an 230 account at the Bootstrap Server and credentials to obtain the 231 necessary information securely. 233 * Server Initiated Bootstrap: In this bootstrapping mode, the 234 bootstrapping server configures all the bootstrap information on 235 the IoT device without receiving a request from the client. This 236 means that the bootstrap server needs to know if a client IoT 237 Device is ready for bootstrapping before it can be configured. 238 For example, a network may inform the bootstrap server of a new 239 connecting IoT client device. 241 OMA has the following characteristics: 243 * Terms: Bootstrapping, provisioning, intialization, configuration, 244 registration. 246 * Players: Bootstrap Server, Client, Device, Manufacturer, Owner, 247 Server, User 249 * Initial beliefs assumed in the device: 251 * Processes: 253 * Beliefs imparted to the device after protocol execution: 255 2.3. Open Connectivity Foundation (OCF) 257 The Open Connectivity Foundation (OCF) [ocf] defines the process 258 before a device is operational as onboarding. The first step of this 259 onboarding process is configuring the ownership, i.e., establishing a 260 legitimate user that owns the device. For this, the user is supposed 261 to use an Onboarding tool (OBT) and an Owner Transfer Method (OTM). 263 The OBT is described as a logical entity that may be implemented on a 264 single or multiple entities such as a home gateway, a device 265 management tool, etc. OCF lists several optional OTMs. At the end 266 of the execution of an OTM, the onboarding tool must have provisioned 267 an Owner Credential onto the device. The following owner transfer 268 methods are specified: 270 * Just works: Performs an un-authenticated Diffie-Hellman key 271 exchange over Datagram Transport Layer Security (DTLS). The key 272 exchange results in a symmetric session key which is later used 273 for provisioning. Naturally, this mode is vulnerable to on-path 274 attackers. 276 * Random PIN: The device generates a PIN code that is entered into 277 the onboarding tool by the user. This pin code is used together 278 with TLS-PSK ciphersuites for establishing a symmetric session 279 key. OCF recommends PIN codes to have an entropy of 40 bits. 281 * Manufacturer certificate: An onboarding tool authenticates the 282 device by verifying a manufacturer installed certificate. 283 Similarly, the device may authenticate the onboarding tool by 284 verifying its signature. 286 * Vendor specific: Vendors implement their own transfer method that 287 accommodates any specific device constraints. 289 Once the onboarding tool and the new device have authenticated and 290 established secure communication, the onboarding tool provisions/ 291 configures the device with Owner credentials. Owner credentials may 292 consist of certificates, shared keys, or Kerberos tickets for 293 example. 295 The OBT additionally configures/provisions information about the 296 Access Management Service (AMS), the Credential Management Service 297 (CMS), and the credentials for interacting with them. The AMS is 298 responsible for provisioning access control entries, while the CMS 299 provisions security credentials necessary for device operation. 301 OCF has the following characteristics: 303 * Terms: Configuration, discovery, enrollment, onboarding, 304 provisioning, registration, 306 * Players: Client, Device, Manager, Manufacturer, Owner, Peer, 307 Responder, Server, User 309 * Initial beliefs assumed in the device: 311 * Processes: 313 * Beliefs imparted to the device after protocol execution: 315 2.4. Bluetooth 317 Bluetooth mesh specifies a provisioning protocol. The goal of the 318 provisioning phase is to securely incorporate a new Bluetooth mesh 319 node, by completing two critical tasks. First, to authenticate the 320 unprovisioned device and second, to create a secure link with said 321 device to share information. 323 The provisioning process is divided into five distinct stages 324 summarize next: 326 * Beaconing for discover: The new unprovisioned device is discovered 327 by the provisioner 329 * Negotiation: The unprovisioned device indicates to the provisioner 330 a set of capabilities such as the security algorithms supported, 331 the availability of its public key using an Out-of-Band (OOB) 332 channel and the input/output interfaces supported 334 * Public-key exchange: The authentication method is selected by the 335 provisioner and both devices exchange Elliptic-curve Diffie- 336 Hellman (ECDH) public keys. These keys may be static or 337 ephemeral. Their exchange can be done in two ways, either via 338 Out-of-Band or directly through a Bluetooth link. Each device 339 then generates a symmetric key, named ECDHSecret, by combining its 340 own private key and the public key of the peer device. The 341 EDCHSecret is used to protect communication between the two 342 devices. 344 * Authentication: During this phase, the ECDH key exchange is 345 authenticated. The authentication method can be Output OOB, Input 346 OOB, static OOB, or No OOB. With Output OOB, the unprovisioned 347 device chooses a random number and outputs that number in manner 348 consistent with its capabilities. The provisioner then inputs 349 this number. Then, a check confirmation value operation is 350 performed. This involves a cryptographic exchange regarding (in 351 this case) the random number to complete the authentication. With 352 Input OOB, the roles are reversed, being the provisioner the 353 entity that generates the random number. When neither of the 354 previous authentication procedures are feasible, both the 355 provisioner and unprovisioned device generate a random number and 356 require the user supervising the setup to verify that values on 357 the device and provisioner are the same. 359 * Distribution of provisioning data: At this point, the provisioning 360 process can be protected. This involves the distribution of data 361 such as a Network key, to secure the communications at network 362 layer and a unicast address among other information. 364 Bluetooth mesh has the following characteristics: 366 * Terms: Configuration, discovery, provisioning. 368 * Players: Client, Device, Manager, Manufacturer, Peer, Server, User 370 * Initial beliefs assumed in the device: 372 * Processes: 374 * Beliefs imparted to the device after protocol execution: 376 2.5. Fast IDentity Online (FIDO) alliance 378 The Fast IDentity Online Alliance (FIDO) is currently specifying an 379 automatic onboarding protocol for IoT devices [fidospec]. The goal 380 of this protocol is to provide a new IoT device with information for 381 interacting securely with an online IoT platform. This protocol 382 allows owners to choose the IoT platform for their devices at a late 383 stage in the device lifecyle. The draft specification refers to this 384 feature as "late binding". 386 The FIDO IoT protocol itself is composed of one Device Initialization 387 (DI) protocol and 3 Transfer of Ownership (TO) protocols TO0, TO1, 388 TO2. Protocol messages are encoded in Concise Binary Object 389 Representation (CBOR) [RFC8949] and can be transported over 390 application layer protocols such as Constrained Application Protocol 391 (CoAP) [RFC7252] or directly over TCP, Bluetooth etc. FIDO IoT 392 however assumes that the device already has IP connectivity to a 393 rendezvous server. Establishing this initial IP connectivity is 394 explicitly stated as "out-of-scope" but the draft specification hints 395 at the usage of Hypertext Transfer Protocol (HTTP) [RFC7230] proxies 396 for IP networks and other forms of tunneling for non-IP networks. 398 The specification only provides a non-normative example of the DI 399 protocol which must be executed in the factory during device 400 manufacture. This protocol embeds initial ownership and 401 manufacturing credentials into Restricted Operation Environment (ROE) 402 on the device. The initial information embedded also includes a 403 unique device identifier (called as GUID in the specification). 404 After DI is executed, the manufacturer has an ownership voucher which 405 is passed along the supply chain to the device owner. 407 When a device is unboxed and powered on by the new owner, the device 408 discovers a network-local or an Internet-based rendezvous server. 409 Protocols (TO0, TO1, and TO2) between the device, the rendezvous 410 server, and the new owner (as the owner onboarding service) ensure 411 that the device and the new owner are able to authenticate each 412 other. Thereafter, the new owner establishes cryptographic control 413 of the device and provides it with credentials of the IoT platform 414 which the device should used. 416 FIDO has the following characteristics: 418 * Terms: Provisioning, onboarding, commissioning, initialization. 420 * Players: Device, Manager, Manufacturer, Owner, Rendezvous Server, 421 Server, User 423 * Initial beliefs assumed in the device: 425 * Processes: 427 * Beliefs imparted to the device after protocol execution: 429 2.6. Enrollment over Secure Transport (EST) 431 Enrollment over Secure Transport (EST) [RFC7030] defines a profile of 432 Certificate Management over CMS (CMC) [RFC5272]. EST relies on 433 Hypertext Transfer Protocol (HTTP) and Transport Layer Security (TLS) 434 for exchanging CMC messages and allows client devices to obtain 435 client certificates and associated Certification Authority (CA) 436 certificates. A companion specification for using EST over secure 437 CoAP has also been standardized [I-D.ietf-ace-coap-est]. EST assumes 438 that some initial information is already distributed so that EST 439 client and servers can perform mutual authentication before 440 continuing with protocol. [RFC7030] further defines "Bootstrap 441 Distribution of CA Certificates" which allows minimally configured 442 EST clients to obtain initial trust anchors. It relies on human 443 users to verify information such as the CA certificate "fingerprint" 444 received over the unauthenticated TLS connection setup. After 445 successful completion of this bootstrapping step, clients can proceed 446 to the enrollment step during which they obtain client certificates 447 and associated CA certificates. 449 EST has the following characteristics: 451 * Terms: Bootstrapping, enrollment, initialization, configuration. 453 * Players: Administrator, Client, Device, Manufacturer, Owner, Peer, 454 Peer, Responder, Server, User 456 * Initial beliefs assumed in the device: 458 * Processes: 460 * Beliefs imparted to the device after protocol execution: 462 2.7. Bootstrapping Remote Secure Key Infrastructures (BRSKI) 464 The ANIMA working group is working on a bootstrapping solution for 465 devices that relies on 802.1AR vendor certificates called 466 Bootstrapping Remote Secure Key Infrastructures (BRSKI) [RFC8995]. 467 In addition to vendor installed IEEE 802.1AR certificates, a vendor 468 based service on the Internet is required. Before being 469 authenticated, a new device only needs link-local connectivity, and 470 does not require a routable address. When a vendor provides an 471 Internet based service, devices can be forced to join only specific 472 domains. The document highlights that the described solution is 473 aimed in general at non-constrained (i.e. class 2+ defined in 474 [RFC7228]) devices operating in a non-challenged network. It claims 475 to scale to thousands of devices located in hostile environments, 476 such as ISP provided CPE devices which are drop-shipped to the end 477 user. 479 BRSKI has the following characteristics: 481 * Terms: Bootstrapping, provisioning, enrollment, onboarding. 483 * Players: Administrator, Client, Cloud Registrar, Configurator, 484 Device, Domain Registrar, Initiator, Join Proxy, JRC, 485 Manufacturer, Owner, Peer, Pledge, Server, User 487 * Initial beliefs assumed in the device: 489 * Processes: 491 * Beliefs imparted to the device after protocol execution: 493 2.8. Secure Zero Touch Provisioning 495 [RFC8572] defines a bootstrapping strategy for enabling devices to 496 securely obtain all the configuration information with no installer 497 input, beyond the actual physical placement and connection of cables. 498 Their goal is to enable a secure NETCONF [RFC6241] or RESTCONF 499 [RFC8040] connection to the deployment specific network management 500 system (NMS). This bootstrapping method requires the devices to be 501 configured with trust anchors in the form of X.509 certificates. 502 [RFC8572] is similar to BRSKI based on [RFC8366]. 504 SZTP has the following characteristics: 506 * Terms: Bootstrapping, provisioning, onboarding, enrollment, 507 configuration, discovery. 509 * Players: Administrator, Bootstrap Server, Client, Device, 510 Manufacturer, Onboarding Server, Owner, Redirect Server, 511 Responder, Server, User 513 * Initial beliefs assumed in the device: 515 * Processes: 517 * Beliefs imparted to the device after protocol execution: 519 2.9. Nimble out-of-band authentication for EAP (EAP-NOOB) 521 EAP-NOOB [RFC9140] defines an EAP method where the authentication is 522 based on a user-assisted out-of-band (OOB) channel between the server 523 and peer. It is intended as a generic bootstrapping solution for IoT 524 devices which have no pre-configured authentication credentials and 525 which are not yet registered on the authentication server. This 526 method claims to be more generic than most ad-hoc bootstrapping 527 solutions in that it supports many types of OOB channels. The exact 528 in-band messages and OOB message contents are specified and not the 529 OOB channel details. EAP-NOOB also supports IoT devices with only 530 output (e.g. display) or only input (e.g. camera). It makes combined 531 use of both secrecy and integrity of the OOB channel for more robust 532 security than the ad-hoc solutions. 534 EAP-NOOB has the following characteristics: 536 * Terms: Bootstrapping, configuration, registration. 538 * Players: Administrator, Authenticator, Client, Device, 539 Manufacturer, Owner, Peer, Server, User 541 * Initial beliefs assumed in the device: 543 * Processes: 545 * Beliefs imparted to the device after protocol execution: 547 2.10. LPWAN 549 Low Power Wide Area Network (LPWAN) encompasses a wide variety of 550 technologies whose link-layer characteristics are severely 551 constrained in comparison to other typical IoT link-layer 552 technologies such as Bluetooth or IEEE 802.15.4. While some LPWAN 553 technologies rely on proprietary bootstrapping solutions which are 554 not publicly accessible, others simply ignore the challenge of 555 bootstrapping and key distribution. In this section, we discuss the 556 bootstrapping methods used by LPWAN technologies covered in 557 [RFC8376]. 559 * LoRaWAN [LoRaWAN] describes its own protocol to authenticate nodes 560 before allowing them join a LoRaWAN network. This process is 561 called as joining and it is based on pre-shared keys (called 562 AppKeys in the standard). The joining procedure comprises only 563 one exchange (join-request and join-accept) between the joining 564 node and the network server. There are several adaptations to 565 this joining procedure that allow network servers to delegate 566 authentication and authorization to a backend AAA infrastructure 567 [RFC2904]. 569 * Wi-SUN Alliance Field Area Network (FAN) uses IEEE 802.1X and EAP- 570 TLS for network access authentication. It performs a 4-way 571 handshake to establish a session keys after EAP-TLS 572 authentication. 574 * NB-IoT relies on the traditional 3GPP mutual authentication scheme 575 based on a shared-secret in the Subscriber Identity Module (SIM) 576 of the device and the mobile operator. 578 * Sigfox security is based on unique device identifiers and 579 cryptographic keys. As stated in [RFC8376], although the 580 algorithms and keying details are not publicly available, there is 581 sufficient information to indicate that bootstrapping in Sigfox is 582 based on pre-established credentials between the device and the 583 Sigfox network. 585 From the above, it is clear that all LPWAN technologies rely on pre- 586 provisioned credentials for authentication between a new device and 587 the network. 589 LPWAN has the following characteristics: 591 * Terms: Bootstrapping, provisioning, configuration, discovery. 593 * Players: Administrator, Authenticator, Border Router, Client, 594 Device, Manager, Network Server, User 596 * Initial beliefs assumed in the device: 598 * Processes: 600 * Beliefs imparted to the device after protocol execution: 602 2.11. Thread 604 Thread Group commissioning [threadcommissioning] introduces a two 605 phased process i.e. Petitioning and Joining. Entities involved are 606 leader, joiner, commissioner, joiner router, and border router. 607 Leader is the first device in Thread network that must be 608 commissioned using out-of-band process and is used to inject correct 609 user generated Commissioning Credentials (can be changed later) into 610 Thread Network. Joiner is the node that intends to get authenticated 611 and authorized on Thread Network. Commissioner is either within the 612 Thread Network (Native) or connected with Thread Network via a WLAN 613 (External). 615 Under some topologies, Joiner Router and Border Router facilitate the 616 Joiner node to reach Native and External Commissioner, respectively. 617 Petitioning begins before Joining process and is used to grant sole 618 commissioning authority to a Commissioner. After an authorized 619 Commissioner is designated, eligible thread devices can join network. 620 Pair-wise key is shared between Commissioner and Joiner, network 621 parameters (such as network name, security policy, etc.,) are sent 622 out securely (using pair-wise key) by Joiner Router to Joiner for 623 letting Joiner to join the Thread Network. Entities involved in 624 Joining process depends on system topology i.e. location of 625 Commissioner and Joiner. Thread networks only operate using IPv6. 626 Thread devices can devise GUAs (Global Unicast Addresses) [RFC4291]. 627 Provision also exist via Border Router, for Thread device to acquire 628 individual global address by means of DHCPv6 or using SLAAC 629 (Stateless Address Autoconfiguration) address derived with advertised 630 network prefix. 632 Thread has the following characteristics: 634 * Terms: Commissioning, discovery, provisioning. 636 * Players: Administrator, Border Agent, Border Router, Commissioner, 637 Commissioner Candidate, Configurator, Device, End Device, End 638 Device, Endpoint Identifier, Initiator, Joiner, Joiner Router, 639 Owner, Peer, Peer, Responder, Server, User 641 * Initial beliefs assumed in the device: 643 * Processes: 645 * Beliefs imparted to the device after protocol execution: 647 3. Comparison 649 There are several stages before a device becomes fully operational. 650 This typically involves establishing some initial trust after which 651 credentials and other parameters are configured. For DPP, 652 bootstrapping is the first step before authentication and 653 provisioning of credentials can occur. For EST, bootstrapping 654 happens as the first step when the client devices have no 655 certificates available for starting enrollment. Provisioning/ 656 configuring are terms used for providing additional information to 657 devices before they are fully operational. For example, credentials 658 are provisioned onto the device. But before credential provisioning, 659 a device is bootstrapped and authenticated. Some protocols may only 660 deal with parts of the process. For example, TLS maybe used for 661 authentication after bootstrapping. A separate device management 662 protocol then may run over this TLS tunnel for provisioning 663 operational information and credentials. 665 3.1. Comparison of terminology 667 3.2. Comparison of players 669 3.3. Comparison of initial beliefs 671 3.4. Comparison of processes 673 3.5. Comparison of knowledge imparted to the device 675 4. Security Considerations 677 This draft does not take any posture on the security properties of 678 the different bootstrapping protocols discussed. Specific security 679 considerations of bootstrapping protocols are present in the 680 respective specifications. 682 Nonetheless, we briefly discuss some important security aspects which 683 are not fully explored in various specifications. 685 Firstly, an IoT system may deal with authorization for resources and 686 services separately from initial security setup in terms of timing as 687 well as protocols. As an example, two resource-constrained devices A 688 and B may perform mutual authentication using credentials provided by 689 an offline third-party X before device A obtains authorization for 690 running a particular application on device B from an online third- 691 party Y. In some cases, authentication and authorization maybe 692 tightly coupled, e.g., successful authentication also means 693 successful authorization. 695 Secondly, initial security setup of IoT devices may be necessary 696 several times during the device lifecycle since keys have limited 697 lifetimes and devices may be lost or resold. Protocols and systems 698 must have adequate provisions for revocation and fresh security 699 setup. A rerun of the security setup mechanism must be as secure as 700 the initial security setup regardless of whether it is done manually 701 or automatically over the network. 703 Lastly, some IoT networks use a common group key for multicast and 704 broadcast traffic. As the number of devices in a network increase 705 over time, a common group key may not be scalable and the same 706 network may need to be split into separate groups with different 707 keys. Bootstrapping and provisioning protocols may need appropriate 708 mechanisms for identifying and distributing keys to the current 709 member devices of each group. 711 5. IANA Considerations 713 There are no IANA considerations for this document. 715 6. Acknowledgements 717 We would like to thank Tuomas Aura, Hannes Tschofenig, and Michael 718 Richardson for providing extensive feedback as well as Rafa Marin- 719 Lopez for his support. 721 7. Informative References 723 [dpp] Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol 724 (DPP)", Wi-Fi Alliance Specification version 1.1, 2018, 725 . 729 [fidospec] Fast Identity Online Alliance, "FIDO Device Onboard 730 Specification", Fido Alliance Version: 1.0, March 2021, 731 . 734 [I-D.ietf-ace-coap-est] 735 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 736 Raza, "EST over secure CoAP (EST-coaps)", Work in 737 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 738 January 2020, . 741 [I-D.ietf-ace-wg-coap-eap] 742 Marin-Lopez, R. and D. Garcia-Carrillo, "EAP-based 743 Authentication Service for CoAP", Work in Progress, 744 Internet-Draft, draft-ietf-ace-wg-coap-eap-06, 7 December 745 2021, . 748 [IEEE802.15.4] 749 IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 750 Std. 802.15.4-2015, April 2016, 751 . 754 [LoRaWAN] LoRa Alliance, "LoRa Specification V1.1", LoRa 755 Alliance Version: 1.1, October 2017, . 758 [ocf] Open Connectivity Foundation, "OCF Security 759 Specification", Version 2.2.2, February 2021, 760 . 763 [oma] Open Mobile Alliance, "Lightweight Machine to Machine 764 Technical Specification: Core", Approved Version 1.2, 765 November 2020, 766 . 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, 772 DOI 10.17487/RFC2119, March 1997, 773 . 775 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 776 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 777 D. Spence, "AAA Authorization Framework", RFC 2904, 778 DOI 10.17487/RFC2904, August 2000, 779 . 781 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 782 Levkowetz, Ed., "Extensible Authentication Protocol 783 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 784 . 786 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 787 "SEcure Neighbor Discovery (SEND)", RFC 3971, 788 DOI 10.17487/RFC3971, March 2005, 789 . 791 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 792 RFC 3972, DOI 10.17487/RFC3972, March 2005, 793 . 795 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 796 Kerberos Network Authentication Service (V5)", RFC 4120, 797 DOI 10.17487/RFC4120, July 2005, 798 . 800 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 801 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 802 January 2006, . 804 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 805 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 806 2006, . 808 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 809 Pre-Shared Key Extensible Authentication Protocol (EAP) 810 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 811 . 813 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 814 and A. Yegin, "Protocol for Carrying Authentication for 815 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 816 May 2008, . 818 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 819 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 820 . 822 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 823 and A. Bierman, Ed., "Network Configuration Protocol 824 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 825 . 827 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 828 "Enrollment over Secure Transport", RFC 7030, 829 DOI 10.17487/RFC7030, October 2013, 830 . 832 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 833 Constrained-Node Networks", RFC 7228, 834 DOI 10.17487/RFC7228, May 2014, 835 . 837 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 838 Protocol (HTTP/1.1): Message Syntax and Routing", 839 RFC 7230, DOI 10.17487/RFC7230, June 2014, 840 . 842 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 843 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 844 Transport Layer Security (TLS) and Datagram Transport 845 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 846 June 2014, . 848 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 849 Application Protocol (CoAP)", RFC 7252, 850 DOI 10.17487/RFC7252, June 2014, 851 . 853 [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 854 Architecture for Network Roaming", RFC 7593, 855 DOI 10.17487/RFC7593, September 2015, 856 . 858 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 859 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 860 . 862 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 863 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 864 May 2017, . 866 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 867 "A Voucher Artifact for Bootstrapping Protocols", 868 RFC 8366, DOI 10.17487/RFC8366, May 2018, 869 . 871 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 872 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 873 . 875 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 876 Touch Provisioning (SZTP)", RFC 8572, 877 DOI 10.17487/RFC8572, April 2019, 878 . 880 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 881 Representation (CBOR)", STD 94, RFC 8949, 882 DOI 10.17487/RFC8949, December 2020, 883 . 885 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 886 and K. Watsen, "Bootstrapping Remote Secure Key 887 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 888 May 2021, . 890 [RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band 891 Authentication for EAP (EAP-NOOB)", RFC 9140, 892 DOI 10.17487/RFC9140, December 2021, 893 . 895 [RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the 896 Extensible Authentication Protocol with TLS 1.3", 897 RFC 9190, DOI 10.17487/RFC9190, February 2022, 898 . 900 [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure 901 Bootstrapping of Cloud-Managed Ubiquitous Displays", 902 Proceedings of ACM International Joint Conference on 903 Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 904 739-750, Seattle, USA, September 2014, 905 . 907 [simpleconn] 908 Wi-Fi Alliance, "Wi-Fi Simple Configuration", 909 Version 2.0.7, 2019, 912 . 914 [threadcommissioning] 915 Thread Group, "Thread Commissioning", 2015. 917 [vendorcert] 918 IEEE std. 802.1ar-2009, "Standard for local and 919 metropolitan area networks - secure device identity", 920 December 2009. 922 Authors' Addresses 924 Mohit Sethi 925 Aalto University 926 FI-02150 Espoo 927 Finland 928 Email: mohit@iki.fi 930 Behcet Sarikaya 931 Denpel Informatique 932 Email: sarikaya@ieee.org 934 Dan Garcia-Carrillo 935 University of Oviedo 936 33207 Oviedo 937 Spain 938 Email: garciadan@uniovi.es