idnits 2.17.1 draft-sarikaya-t2trg-sbootstrapping-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1509 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-aura-eap-noob-07 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-35 == Outdated reference: A later version (-07) exists of draft-marin-ace-wg-coap-eap-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Sethi 3 Internet-Draft Ericsson 4 Intended status: Informational B. Sarikaya 5 Expires: September 10, 2020 Denpel Informatique 6 D. Garcia-Carrillo 7 Odin Solutions 8 March 9, 2020 10 Secure IoT Bootstrapping: A Survey 11 draft-sarikaya-t2trg-sbootstrapping-08 13 Abstract 15 This draft provides an overview of the various terms that are used 16 when discussing bootstrapping of 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 smart objects. 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 September 10, 2020. 45 Copyright Notice 47 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Usage of terms . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Device Provisioning Protocol . . . . . . . . . . . . . . 4 66 3.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) . . . 5 67 3.3. Open Connectivity Foundation . . . . . . . . . . . . . . 5 68 3.4. Internet Engineering Task Force . . . . . . . . . . . . . 6 69 3.4.1. Enrollment over Secure Transport (EST) . . . . . . . 6 70 3.4.2. Bootstrapping Remote Secure Key Infrastructures 71 (BRSKI) . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.4.3. Secure Zero Touch Provisioning . . . . . . . . . . . 7 73 4. Comparsion . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Classification of available mechanisms . . . . . . . . . . . 7 76 7. IoT Device Bootstrapping Methods . . . . . . . . . . . . . . 9 77 7.1. Managed Methods . . . . . . . . . . . . . . . . . . . . . 9 78 7.1.1. Bootstrapping in LPWAN . . . . . . . . . . . . . . . 11 79 7.2. Peer to Peer or Adhoc Methods . . . . . . . . . . . . . . 13 80 7.3. Leap-of-faith/Opportunistic Methods . . . . . . . . . . . 14 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 84 11. Informative References . . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 87 1. Introduction 89 We informally define bootstrapping as "any process that takes place 90 before a device can become operational". While bootstrapping is 91 necessary for all computing devices, until recently, most of our 92 devices typically had sufficient computing power and user interface 93 (UI) for ensuring somewhat smooth operation. For example, a typical 94 laptop device required the user to setup a username/password as well 95 as enter network settings for Internet connectivity. Following these 96 steps ensured that the laptop was fully operational. 98 The problem of bootstrapping is however exacerbated for Internet of 99 Things (IoT) networks. The size of an IoT network varies from a 100 couple of devices to tens of thousands, depending on the application. 101 Smart objects/things/devices in IoT networks are produced by a 102 variety of vendors and are typically heterogeneous in terms of the 103 constraints on their power supply, communication capability, 104 computation capacity, and user interfaces available. This problem of 105 bootstrapping in IoT was identified by Sethi et al. [Sethi14] while 106 developing a bootstrapping solution for smart displays. Although 107 this document focuses on bootstrapping terminology and methods for 108 IoT devices, we do not exclude bootstrapping related terminology used 109 in other contexts. 111 Bootstrapping devices typically also involves providing them with 112 some sort of network connectivity. Indeed, the functionality of a 113 disconnected device is rather limited. Ipso facto, bootstrapping 114 assumes that some network has been setup a-priori. Setting up a 115 network itself is challenging. For example, the Wi-Fi Alliance 116 Simple Configuration specification [simpleconn] helps users setup 117 home networks. This document is only focused on terminology 118 associated with bootstrapping devices and excludes any discussion on 119 setting up networks. 121 In addition to our informal definition, it is helpful to look at 122 other definitions of bootstrapping. The IoT@Work project defines 123 bootstrapping in the context of IoT as "the process by which the 124 state of a device, a subsystem, a network, or an application changes 125 from not operational to operational" [iotwork]. Vermillard 126 [vermillard] , on the other hand, describes bootstrapping as the 127 procedure by which an IoT device gets the URLs and secret keys for 128 reaching the necessary servers. Vermillard notes that the same 129 process is useful for re-keying, upgrading the security schemes, and 130 for redirecting the IoT devices to new servers. 132 There are several terms that have often been used in the context of 133 bootstrapping: 135 o Bootstrapping 137 o Provisioning 139 o Onboarding 140 o Enrollment 142 o Commissioning 144 o Initialization 146 o Configuration 148 o Registration 150 We attempt to find out whether all these terms refer to the same 151 phenomena. We begin by looking at how these terms have been used in 152 various standards and standardization bodies in Section 3. We then 153 summarize our understanding in Section 4, and provide our 154 recommendations on their usage in Section 5. Section 6 provides a 155 taxonomy of bootstrapping methods and Section 7 categorizes methods 156 according to the taxonomy. 158 2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 3. Usage of terms 166 3.1. Device Provisioning Protocol 168 Device provisioning protocol (DPP) [dpp] describes itself as a 169 standardized protocol for providing user friendly Wi-Fi setup while 170 maintaining or increasing the security. DPP relies on a 171 configurator, e.g. a smartphone application, for setting up all all 172 other devices, called enrollees, in the network. DPP has the 173 following three phases/sub-protocols: 175 o Bootstrapping: The configurator obtains bootstrapping information 176 from the enrollee using an out-of-band channel such as scanning a 177 QR code or tapping NFC. The bootstrapping information includes 178 the public-key of the device and metadata such as the radio 179 channel on which the device is listening. 181 o Authentication: In DPP, either the configurator or the enrollee 182 can initiate the authentication protocol. The side initiating the 183 authentication protocol is called as the initiator while the other 184 side is called the responder. The authentication sub-protocol 185 provides authentication of the responder to an initiator. It can 186 optionally authenticate the initiator to the responder (only if 187 the bootstrapping information was exchange out-of-band in both 188 directions). 190 o Configuration: Using the key established from the authentication 191 protocol, the enrollee asks the configurator for network 192 information such as the SSID and passphrase of the access point. 194 3.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) 196 The OMA LWM2M specification [oma] defines an architecture where a new 197 device (LWM2M client) contacts a Bootstrap-server which is 198 responsible for "provisioning" essential information such as 199 credentials. After receiving this essential information, the LwM2M 200 client device "registers" itself with one or more LwM2M Servers which 201 will manage the device during its lifecycle. The current standard 202 defines the following four bootstrapping modes: 204 o Factory Bootstrap: An IoT device in this case is configured with 205 all the necessary bootstrap information during manufacturing and 206 prior to its deployment. 208 o Bootstrap from Smartcard: An IoT device retrieves and processes 209 all the necessary bootstrap data from a Smartcard. 211 o Client Initiated Bootstrap: This mode provides a mechanism for an 212 IoT client device to retrieve the bootstrap information from a 213 Bootstrap Server. This requires the client device to have an 214 account at the Bootstrap Server and credentials to obtain the 215 necessary information securely. 217 o Server Initiated Bootstrap: In this bootstrapping mode, the 218 bootstrapping server configures all the bootstrap information on 219 the IoT device without receiving a request from the client. This 220 means that the bootstrap server needs to know if a client IoT 221 Device is ready for bootstrapping before it can be configured. 222 For example, a network may inform the bootstrap server of a new 223 connecting IoT client device. 225 3.3. Open Connectivity Foundation 227 The Open Connectivitiy Foundation [ocf] defines the process before a 228 device is operational as onboarding. The first step of this 229 onboarding process is "configuring" the ownership, i.e., establishing 230 a legitimate user that owns the device. For this, the user is 231 supposed to use an Onboarding tool (OBT) and an Owner Transfer 232 Methods (OTM). 234 The Onboarding tool (OBT) is described as a logical entity that may 235 be implemented on a single or multiple entities such as a home 236 gateway, a device management tool, etc. OCF lists several optional 237 Owner Transfer Methods (OTMs). At the end of the execution of an 238 OTM, the Onboarding tool must have "provisioned" an Owner Credential 239 onto the device. The following owner transfer methods are specified: 241 o Just works: Performs an un-authenticated Diffie-Hellman key 242 exchange over DTLS. The key exchange results in a symmetric 243 session key which is later used for provisioning. Naturally, this 244 mode is vulnerable to Man-in-The-Middle (MiTM) attackers. 246 o Random PIN: The device generates a PIN code that is entered into 247 the onboarding tool by the user. This pin code is used together 248 with TLS-PSK ciphersuites for establishing a symmetric session 249 key. OCF recommends PIN codes to have an entropy of 40 bits. 251 o Manufacturer certificate: An onboarding tool authenticates the 252 device by verifying a manufacturer installed certificate. 253 Similarly, the device may authenticate the onboarding tool by 254 verifying its signature. Fo 256 o Vendor specific: Vendors implement their own transfer method that 257 accommodates any specific device constraints. 259 Once the onboarding tool and the new device have authenticated and 260 established secure communication, the onboarding tool 261 "provisions"/"configures" the device with Owner credentials. Owner 262 credentials may consist of certificates, shared keys, or Kerberos 263 tickets for example. 265 The OBT will .... 267 3.4. Internet Engineering Task Force 269 3.4.1. Enrollment over Secure Transport (EST) 271 [RFC7030] 273 3.4.2. Bootstrapping Remote Secure Key Infrastructures (BRSKI) 275 The ANIMA working group is working on a bootstrapping solution for 276 devices that relies on 802.1AR vendor certificates called 277 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 278 [I-D.ietf-anima-bootstrapping-keyinfra]. In addition to vendor 279 installed IEEE 802.1AR certificates, a vendor based service on the 280 Internet is required. Before being authenticated, a new device only 281 needs link-local connectivity, and does not require a routable 282 address. When a vendor provides an Internet based service, devices 283 can be forced to join only specific domains. The document highlights 284 that the described solution is aimed in general at non-constrained 285 (i.e. class 2+ defined in [RFC7228]) devices operating in a non- 286 challenged network. It claims to scale to thousands of devices 287 located in hostile environments, such as ISP provided CPE devices 288 which are drop-shipped to the end user. 290 3.4.3. Secure Zero Touch Provisioning 292 [RFC8572] defines a bootstrapping strategy for enabling devices to 293 securely obtain all the configuration information with no installer 294 input, beyond the actual physical placement and connection of cables. 295 Their goal is to enable a secure NETCONF [RFC6241] or RESTCONF 296 [RFC8040] connection to the deployment specific network management 297 system (NMS). This bootstrapping method requires the devices to be 298 configured with trust anchors in the form of X.509 certificates. 299 [RFC8572] is similar to BRSKI based on [RFC8366], but using a 300 different set of assumptions .... 302 4. Comparsion 304 There are several stages before a device becomes fully operational. 305 This typically involves establishing some initial trust after which 306 credentials and other parameter. 308 5. Recommendations 310 TBD 312 6. Classification of available mechanisms 314 While some bootstrapping approaches are more user-intensive and 315 require extensive user-involvement by scanning QR codes or entering 316 passwords; others maybe more automated, such as those that rely on 317 mobile networks [I-D.sethi-gba-constrained]. We classify available 318 bootstrapping solutions into the following major categories: 320 o Managed methods: These bootstrapping methods rely on pre- 321 established trust relations and authentication credentials. They 322 typically utilize centralized servers for authentication, although 323 several such servers may join to form a distributed federation. 324 Example methods include Extensible Authentication Protocol (EAP) 325 [RFC3748], Generic Bootstrapping Architecture (GBA) [TS33220], 326 Kerberos [RFC4120], Bootstrapping Remote Secure Key 327 Infrastructures (BRSKI) and vendor certificates [vendorcert]. EAP 328 Transport Layer Security EAP-TLS [RFC5216] for instance assumes 329 that both the client and the server have certificates to 330 authenticate each other. Based on this authentication, the server 331 would then authorize the client for network access. The Eduroam 332 federation [RFC7593] uses a network of such servers to support 333 roaming clients. 335 o Opportunistic and leap-of-faith methods: In these bootstrapping 336 methods, rather than verifying the initial authentication, the 337 continuity of the initial identity or connection is verified. 338 Some of these methods assume that the attacker is not present 339 during the initial setup. Example methods include Secure Neighbor 340 Discovery (SEND) [RFC3971] and Cryptographically Generated 341 Addresses (CGA) [RFC3972], Wifi Protected Setup (WPS) push button 342 [wps], and Secure Shell (SSH) [RFC4253]. 344 o Hybrid methods: Most deployed methods are hybrid and use 345 components from both managed and ad-hoc methods. For instance, 346 central management may be used for devices after they have been 347 registered with the server using ad-hoc registration methods. 349 o Peer-to-Peer (P2P) and Ad-hoc methods: These bootstrapping methods 350 do not rely on any pre-established credentials. Instead, the 351 bootstrapping protocol results in credentials being established 352 for subsequent secure communication. Such bootstrapping methods 353 typically perform an unauthenticated Diffie-Hellman exchange [dh] 354 and then use an out-of-band (OOB) communication channel to prevent 355 a man-in-the-middle attack (MitM). Various secure device pairing 356 protocols fall in this category. Another example P2P or Ad-hoc 357 method is EAP-NOOB [I-D.aura-eap-noob] that specifies nimble out- 358 of-band authentication for EAP. Based on how the OOB channel is 359 used, the P2P methods can be further classified into two sub 360 categories: 362 * Key derivation: Contextual information received over the OOB 363 channel is used for shared key derivation. For example, 364 [proximate] relies on the common radio environment of the 365 devices being paired to derive the shared secret which would 366 then be used for secure communication. 368 * Key confirmation: A Diffie-Hellman key exchange occurs over the 369 insecure network and the established key is used to 370 authenticate with the help of the OOB channel. For example, 371 Bluetooth simple pairing [SimplePairing] use the OOB channel to 372 ask the user to compare pins and approve the completed 373 exchange. 375 It is important to note here that categorization of different 376 bootstrapping methods is not always easy or clear. For example, all 377 the opportunistic and leap-of-faith methods become managed methods 378 after the initial vulnerability window. The choice of bootstrapping 379 method used for devices depends heavily on the business case. 380 Questions that may govern the choice include: What third parties are 381 available? Who wants to retain control or avoid work? In each 382 category, there are many different methods of secure bootstrapping 383 available. The choice of the method may also be governed by the type 384 of device being bootstrapped. Depending on the link-layer technology 385 used, and the User Interface (UI) available, one or more of the above 386 mentioned methods might be suitable. 388 7. IoT Device Bootstrapping Methods 390 In this section we look at some of the recent bootstrapping proposals 391 for IoT devices both at the IETF and elsewhere. Needless to say, if 392 the devices are capable in terms of their computation power and UI 393 available, they can always rely on many existing methods such as 394 username and password combinations and various EAP methods. 396 7.1. Managed Methods 398 We first discuss some examples of managed bootstrapping methods. 400 EAP-TLS is a widely used EAP method for network access authentication 401 [RFC7250]. It allows mutual authentication and distributes the 402 keying material for secure subsequent communications. However it 403 only supports certificate-based mutual authentication, and therefore 404 a public key infrastructure is required. The ZigBee Alliance has 405 specified an IPv6 stack aimed at IEEE 802.15.4 [IEEE802.15.4] devices 406 mainly used in smart meters developed primarily for SEP 2.0 (Smart 407 Energy Profile) application layer traffic [SEP2.0]. The ZigBee IP 408 stack uses EAP-TLS for secure bootstrapping of devices. 410 EAP-PSK [RFC4764] is another EAP method. It realizes mutual 411 authentication and session key derivation using a Pre-Shared Key 412 (PSK). Normally four messages are exchanged in the authentication 413 process. Once the authentication is successful, EAP-PSK provides a 414 protected communication channel. Given the light-weight nature of 415 EAP-PSK, it can often be a good choice on constrained devices. 417 CoAP-EAP [I-D.marin-ace-wg-coap-eap] defines a bootstrapping service 418 for IoT. They propose the transport of EAP over CoAP [RFC7252] for 419 the constrained link, and communication with AAA infrastructures in 420 the non-constrained link to provide scalability among other 421 characteristics. Upon a successful authentication, key material is 422 derived to protect CoAP messages exchanged between the smart object 423 and the authenticator. They discuss the use of EAP-PSK in the draft, 424 but state that, since they are specifying a new EAP lower layer, any 425 EAP method that results in generation of cryptographic material is 426 suitable. 428 Protocol for Carrying Authentication for Network Access (PANA) 429 [RFC5191] is a network layer protocol with which a node can 430 authenticate itself to gain access to the network. PANA does not 431 define a new authentication protocol and rather uses EAP over User 432 Datagram Protocol (UDP) for authentication. Colin O'Flynn 433 [I-D.oflynn-core-bootstrapping] proposes the use of PANA for secure 434 bootstrapping of resource constrained devices. He demonstrates how a 435 6LowPAN Border Router (PANA Authentication Agent (PAA)) can 436 authenticate the identity of a joining constrained device (PANA 437 Client). Once the constrained device has been successfully 438 authenticated, the border router can also provide network and 439 security parameters to the joining device. Hernandez-Ramos et al. 440 [panaiot] also use EAP-TLS over PANA for secure bootstrapping of 441 smart objects. They also extend their bootstrapping scheme for 442 configuring additional keys that are used for secure group 443 communication. 445 When a device is not a direct neighbor of the authenticator, its 446 parent node MUST act as relay. Different EAP encapsulation protocols 447 have different mechanisms for the relay function, such as the PANA 448 Relay Element (PRE). 450 After a successful bootstrapping, the device runs neighbor discovery 451 protocol to get an IPv6 address assigned [RFC6775]. Data transfer 452 can be secured using DTLS or IPSec. Keys derived from EAP TLS are 453 used in either generating DTLS ciphering keys after a successful DTLS 454 handshake or IPSec ESP ciphering keys after a successful IKEv2 455 handshake. 457 Generic Bootstrapping Architecture (GBA) is another bootstrapping 458 method that falls in centralized category. GBA is part of the 3GPP 459 standard [TS33220] and is based on 3GPP Authentication and Key 460 Agreement (3GPP AKA). GBA is an application independent mechanism to 461 provide a client application (running on the User equipment (UE)) and 462 any application server with a shared session secret. This shared 463 session secret can subsequently be used to authenticate and protect 464 the communication between the client application and the application 465 server. GBA authentication is based on the permanent secret shared 466 between the UE's Universal Integrated Circuit Card (UICC), for 467 example SIM card, and the corresponding profile information stored 468 within the cellular network operator's Home Subscriber System (HSS) 469 database. [I-D.sethi-gba-constrained] describes a resource- 470 constrained adaptation of GBA to IoT applications. 472 The four bootstrapping modes specified by the Open Mobile Alliance 473 (OMA) Light-weight M2M (LwM2M) standard require some sort of pre- 474 provisioned credentials on the device. All the four modes are 475 examples of managed bootstrapping methods. 477 The Kerberos protocol [RFC4120] is a network authentication protocol 478 that allows several endpoints to communicate over an insecure 479 network. Kerberos relies on a symmetric cryptography scheme and 480 requires a trusted third party, that guarantees the identities of the 481 various actors. It relies on the use of "tickets" for nodes to prove 482 identity to one another in a secure manner. There has been research 483 work on using Kerberos for IoT devices [kerberosiot]. 485 It is also important to mention some of the work done on implicit 486 certificates and identity-based cryptographic schemes [himmo], 487 [implicit]. While these are interesting and novel schemes that can 488 be a part of securely bootstrapping devices, at this point, it is 489 hard to speculate on whether such schemes would see large-scale 490 deployment in the future. 492 7.1.1. Bootstrapping in LPWAN 494 Low Power Wide Area Network (LPWAN) encompasses a wide variety of 495 technologies, generally, with severe constraints in the link in 496 comparison with other typical IoT technologies such as Bluetooth or 497 IEEE 802.15.4. LPWAN typically presents a star topology with support 498 for thousands of devices per antenna. 500 Among the wide variety of technologies considered as part of LPWAN, 501 we highlight the ones mentioned in the LPWAN overview document of the 502 LPWAN working group [RFC8376]: LoRaWAN, Narrowband IoT (NB-IoT), 503 SIGFOX and Wi-SUN Alliance Field Area Network (FAN). Each technology 504 has different methods to provide security for the communications. 505 Bootstrapping is not directly tackled by all of them, having in some 506 cases proprietary solutions that are not publicly accessible and in 507 other cases key distribution is not even considered. Among the 508 previous LPWAN technologies, bootstrapping is considered in Wi-SUN 509 Alliance Field Area Network (FAN) and LoRaWAN provides Joining 510 process to derive key material based on some previous key material 511 installed in the device. 513 Following the definition in Section 6 we find that they all fall into 514 the managed classification. This is because in one way or another, a 515 previous trust relationship has been established and authentication 516 credentials have been installed in the devices. 518 o LoRaWAN [LoRaWAN] describes its own protocol to authenticate their 519 nodes and incorporate them into their network. This process is 520 called the Joining Procedure and it is based on pre-shared keys. 521 The Joining procedure entails one exchange where the node that 522 intends to join the network sends its identity along with other 523 information to authenticate against a network server which 524 interacts with an entity that knows the pre-shared key (called 525 AppKey) and derives the necessary key material for its nominal 526 operation. There is some variation regarding the pre-installed 527 key material on version 1.0 and 1.1, but the Joining Process is 528 very similar in both cases. The Joining Process consists of an 529 exchange of two messages, the Join-request message (sent from the 530 node) where information about the identity of the node is provided 531 and the Join-accept message (received by the node). In this last 532 message the node receives the necessary information to derive the 533 key material to secure the communications To this process there 534 are adaptations to use AAA infrastructures to enhance the joining 535 process with AAA features such as identity federation. Since 536 there are pre-established trust relationships and authentication 537 credentials, LoRaWAN falls into the managed category. 539 o Wi-SUN Alliance Field Area Network (FAN) uses an EAP lower layer 540 (IEEE 802.1X) and the EAP-TLS method for network access 541 authentication and performs the 4-way handshake to establish a 542 security association similarly to a WPA2-Enterprise deployment. 543 Since it uses on the authentication protocols which are used to 544 exemplify the managed methods (EAP-TLS), WI-SUN falls in the 545 managed category as well. 547 o NB-IoT also falls into the category of managed methods, since they 548 present a pre-established trust relationship. For instance, they 549 have support for EAP-AKA. 551 o Sigfox provides security to the communications using a unique 552 device ID and an cryptographic keys that are independent for each 553 device. As stated in [RFC8376] algorithms and keying details for 554 are not published, but what we can see is that the establishment 555 of the keys are subject to a pre-established trust relationship 556 with the Sigfox network, hence having also a managed method. 558 In short, LPWANs are still under development, and as it is identified 559 in [RFC8376], due to the characteristics of these technologies, they 560 are prime candidates to benefit from a standardized Authentication, 561 Accounting, and Authorization (AAA) infrastructure [RFC2904] as a way 562 of offering a scalable solution for some of the security and 563 management issues that are present in LPWANs. 565 7.2. Peer to Peer or Adhoc Methods 567 While managed methods are viable for many IoT devices, they may not 568 be suitable or desirable in all scenarios. All the managed methods 569 assume that some credentials are provisioned into the device. These 570 credentials may be in the device micro-controller or in a replaceable 571 smart card such as a SIM card. The methods also sometimes assume 572 that the manufacturer embeds these credentials during the device 573 manufacture on the factory floor. However, in many cases the 574 manufacturer may not have sufficient incentive to do this. In other 575 scenarios, it may be hard to completely trust and rely on the device 576 manufacturer to securely perform this task. Therefore, many times, 577 P2P or Adhoc methods of bootstrapping are used. We discuss a few 578 example next. 580 P2P or ad-hoc bootstrapping methods are used for establishing keys 581 and credential information for secure communication without any pre- 582 provisioned information. These bootstrapping mechanisms typically 583 rely on an out-of-band (OOB) channel in order to prevent man-in-the- 584 middle (MitM) attacks. P2P and ad-hoc methods have typically been 585 used for securely pairing personal computing devices such as smart 586 phones. [devicepairing] provides a survey of such secure device 587 pairing methods. Many original pairing schemes required the user to 588 enter the same key string or authentication code to both devices or 589 to compare and approve codes displayed by the devices. While these 590 methods can provide reasonable security, they require user 591 interaction that is relatively unnatural and often considered a 592 nuisance. Thus, there is ongoing research for more natural ways of 593 pairing devices. To reduce the amount of user-interaction required 594 in the pairing process, several proposals use contextual or location- 595 dependent information, or natural user input such as sound or 596 movement, for device pairing [proximate]. 598 The local association created between two devices may later be used 599 for connecting/introducing one of the devices to a centralized 600 server. Such methods would however be classified as hybrids. 602 EAP-NOOB [I-D.aura-eap-noob] is an example of P2P and ad-hoc 603 bootstrapping method that establishes a security association between 604 an IoT device (node) and an online server (unlike pairing two devices 605 for local connections over WiFi or Bluetooth). 607 EAP-NOOB defines an EAP method where the authentication is based on a 608 user-assisted out-of-band (OOB) channel between the server and peer. 609 It is intended as a generic bootstrapping solution for Internet-of- 610 Things devices which have no pre-configured authentication 611 credentials and which are not yet registered on the authentication 612 server. This method claims to be more generic than most ad-hoc 613 bootstrapping solutions in that it supports many types of OOB 614 channels. The exact in-band messages and OOB message contents are 615 specified and not the OOB channel details. Also, EAP-NOOB supports 616 IoT devices with only output (e.g. display) or only input (e.g. 617 camera). It makes combined use of both secrecy and integrity of the 618 OOB channel for more robust security than the ad-hoc solutions. 620 Thread Group commissioning [threadcommissioning] introduces a two 621 phased process i.e. Petitioning and Joining. Entities involved are 622 Leader, Joiner, Commissioner, Joiner Router and Border Router. 623 Leader is the first device in Thread Network that must be 624 commissioned using out-of-band process and is used to inject correct 625 user generated Commissioning Credentials (can be changed later) into 626 Thread Network. Joiner is the node that intends to get authenticated 627 and authorized on Thread Network. Commissioner is either within the 628 Thread Network (Native) or connected with Thread Network via a WLAN 629 (External). 631 Under some topologies, Joiner Router and Border Router facilitate the 632 Joiner node to reach Native and External Commissioner, respectively. 633 Petitioning begins before Joining process and is used to grant sole 634 commissioning authority to a Commissioner. After an authorized 635 Commissioner is designated, eligible thread devices can join network. 636 Pair-wise key is shared between Commissioner and Joiner, network 637 parameters (Network Name, Security Policy, Steering Data, 638 Commissioning Data Timestamp, Commissioning Credential, Network 639 Master Key, Network Key Sequence, Network Mesh-Local ULA, Border 640 Router Locator, Commissioner Session ID, XPANID, PANID and Channel) 641 are sent out securely (using pair-wise key) by Joiner Router to 642 Joiner for letting Joiner to join the Thread Network. Entities 643 involved in Joining process depends on system topology i.e. location 644 of Commissioner and Joiner. 646 Thread networks only operates using IPv6. Thread devices can devise 647 GUAs (Global Unicast Addresses) [RFC4291]. Provision also exist via 648 Border Router, for Thread device to acquire individual global address 649 by means of DHCPv6 or using SLAAC (Stateless Address 650 Autoconfiguration) address derived with advertised network prefix. 652 DPP bootstrapping explained earlier is an example of ad-hoc 653 bootstrapping method. 655 7.3. Leap-of-faith/Opportunistic Methods 657 Next, we look at a leap-of-faith/opportunistic bootstrapping method 658 for IoT devices. 660 Bergmann et al. [simplekey] develop a secure bootstrapping mechanism 661 that does not rely on pre-provisioned credentials using resurrecting- 662 duckling imprinting scheme. Their bootstrapping protocol involves 663 three distinct phases: discover (the duckling node searches for 664 network nodes that can act as mother node), imprint (the mother node 665 imprints a shared secret establishing a secure channel once a 666 positive response is received for the imprinting request) and 667 configure (additional configuration information such as network 668 prefix and default gateway are configured). In this model for 669 bootstrapping, a small initial vulnerability window is acceptable and 670 can be mitigated using techniques such as a Faraday Cage (securing 671 the communication physically) to protect the environment of the 672 mother and duck nodes, though this may be inconvenient for the user. 674 [RFC7250] defines how raw public keys can be used to authenticate 675 constrained devices for mutual authentication using EAP-TLS or DTLS. 676 Raw public key TLS/DTLS extension simplifies client_certificate_type 677 and server_certificate_type to carry only SubjectPublicKeyInfo 678 structure with the raw public key instead of many other parameters 679 found in the certificates. The device and the authentication server 680 (AS) exchange client_hello and server_hello messages and send their 681 raw public keys. The device and AS validate the keys by comparing 682 the pre-configured values [I-D.sarikaya-6lo-bootstrapping-solution]. 683 This bootstrapping method can be seen as a hybrid. This is because 684 it generally requires an out-of-band (OOB) step (P2P/Ad-hoc) where 685 the raw public keys [RFC7250] are provided to the authenticating 686 entities, after which the actual authentication occurs online 687 (managed). Raw public key approach when used with DTLS offers a 688 simple secure bootstrapping solution especially for smart energy and 689 building automation applications. It can be easily integrated with 690 the Constrained Application Protocol (CoAP). 692 8. Security Considerations 694 Bootstrapping protocols that do not rely on a pre-shared key for peer 695 authentication generally rely on an online or offline third-party 696 (e.g., an authentication server, a key distribution center in 697 Kerberos, a certification authority in PKI, a private key generator 698 in ID-based cryptography and so on) to prevent man-in-the-middle 699 attacks during bootstrapping. Depending on use cases, a resource- 700 constrained device may not always have access to an online third- 701 party for bootstrapping. Some bootstrapping methods therefore rely 702 on a configuration tool (such as a smartphone) that assists the 703 bootstrapping process by providing temporary reachability to the 704 online server. 706 Depending on use cases, a bootstrapping protocol may deal with 707 authorization separately from authentication in terms of timing and 708 signaling path. For example, two resource-constrained devices A and 709 B may perform mutual authentication using authentication credentials 710 provided by an offline third-party X whereas resource-constrained 711 device A obtains authorization for running a particular application 712 with resource-constrained device B from an online third-party Y 713 before or after the authentication. In some use cases, 714 authentication and authorization are tightly coupled, e.g., 715 successful authentication also means successful authorization. 717 If authorization information communicated includes cryptographic 718 keys, care must be taken for provisioning the keys, e.g., guidelines 719 for AAA-based key management are described in [RFC4962]. Re- 720 bootstrapping of IoT devices may required and therefore there must be 721 adequate provisions for revocation and re-bootstrapping of 722 authentication/authorization credentials. Re-bootstrapping must be 723 as secure as the initial bootstrapping regardless of whether this re- 724 bootstrapping is done manually or automatically over the network. 726 If resource-constrained devices use a multicast group key for 727 authentications of peers that belong to the group, or for message 728 authentication/encryption, the group key must be securely distributed 729 to the current members of the group. Protocols designed for group 730 key management [RFC4046] may be used for group key distribution after 731 the initial bootstrapping. Alternatively, key wrap attributes for 732 securely encapsulating group key may be defined in network access 733 authentication protocols such as PANA. Those protocols use an end- 734 to-end, point-to-point communication channel with a pair-wise 735 security association between a key distribution center and each key 736 recipient. Further considerations may be needed for more efficient 737 group key management to support a large number of resource- 738 constrained devices. 740 9. IANA Considerations 742 There are no IANA considerations for this document. 744 10. Acknowledgements 746 We would like to thank Tuomas Aura, Hannes Tschofenig, and Michael 747 Richardson for providing extensive feedback as well as Rafa Marin for 748 his support. 750 11. Informative References 752 [devicepairing] 753 Mirzadeh, S., Cruickshank, H., and R. Tafazolli, "Secure 754 Device Pairing: A Survey", IEEE Communications Surveys and 755 Tutorials , pp. 17-40, 2014. 757 [dh] Diffie, W. and M. Hellman, "New directions in 758 cryptography", IEEE Transactions on Information Theory , 759 vol. 22, no. 6, pp. 644-654, 1976. 761 [dpp] Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol 762 (DPP)", Wi-Fi Alliance , 2018, . 766 [himmo] Garcia-Morchon, O., Rietman, R., Sharma, S., Tolhuizen, 767 L., and J. Torre-Arce, "DTLS-HIMMO: Efficiently Securing a 768 Post-Quantum World with a Fully-Collusion Resistant KPS", 769 Submitted to NIST Workshop on Cybersecurity in a Post- 770 Quantum World , version 20141225:065757, December 2014, 771 . 773 [I-D.aura-eap-noob] 774 Aura, T. and M. Sethi, "Nimble out-of-band authentication 775 for EAP (EAP-NOOB)", draft-aura-eap-noob-07 (work in 776 progress), October 2019. 778 [I-D.ietf-anima-bootstrapping-keyinfra] 779 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 780 and K. Watsen, "Bootstrapping Remote Secure Key 781 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 782 keyinfra-35 (work in progress), February 2020. 784 [I-D.marin-ace-wg-coap-eap] 785 Lopez, R. and D. Garcia, "EAP-based Authentication Service 786 for CoAP", draft-marin-ace-wg-coap-eap-06 (work in 787 progress), October 2017. 789 [I-D.oflynn-core-bootstrapping] 790 Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security 791 Bootstrapping of Resource-Constrained Devices", draft- 792 oflynn-core-bootstrapping-03 (work in progress), November 793 2010. 795 [I-D.sarikaya-6lo-bootstrapping-solution] 796 Sarikaya, B., "Secure Bootstrapping Solution for Resource- 797 Constrained Devices", draft-sarikaya-6lo-bootstrapping- 798 solution-00 (work in progress), June 2013. 800 [I-D.sethi-gba-constrained] 801 Sethi, M., Lehtovirta, V., and P. Salmela, "Using Generic 802 Bootstrapping Architecture with Constrained Devices", 803 draft-sethi-gba-constrained-01 (work in progress), 804 February 2014. 806 [IEEE802.15.4] 807 "IEEE Std. 802.15.4-2015", April 2016, 808 . 811 [implicit] 812 Porambage, P., Schmitt, C., Kumar, P., Gurtov, A., and M. 813 Ylianttila, "Pauthkey: A pervasive authentication protocol 814 and key establishment scheme for wireless sensor networks 815 in distributed iot applications", International Journal of 816 Distributed Sensor Networks , Hindawi Publishing 817 Corporation , 2014. 819 [iotwork] European Commission FP7, "IoT@Work bootstrapping 820 architecture Deliverable D2.2", June 2011. 822 [kerberosiot] 823 Hardjono, T., "Kerberos for Internet-of-Things", February 824 2014, . 827 [LoRaWAN] Sornin, N., Luis, M., Eirich, T., and T. Kramp, "LoRa 828 Specification V1.0", January 2015, . 832 [ocf] Open Connectivity Foundation, "OCF Security 833 Specification", Open Connectivitiy Foundation , June 2017, 834 . 837 [oma] Open Mobile Alliance, "Lightweight Machine to Machine 838 Technical Specification: Core", Open Mobile Alliance , 839 June 2019, 840 . 844 [panaiot] Hernandez-Ramos, J., Carrillo, D., Marin-Lopez, R., and A. 845 Skarmeta, "Dynamic Security Credentials PANA-based 846 Provisioning for IoT Smart Objects", 2nd World Forum on 847 Internet of Things (WF-IoT) , IEEE , 2015. 849 [proximate] 850 Mathur, S., Miller, R., Varshavsky, A., Trappe, W., and N. 851 Mandayam, "Proximate: proximity-based secure pairing using 852 ambient wireless signals.", Proceedings of MobiSys 853 International Conference , pp. 211-224, June 2011. 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, 857 DOI 10.17487/RFC2119, March 1997, 858 . 860 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 861 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 862 D. Spence, "AAA Authorization Framework", RFC 2904, 863 DOI 10.17487/RFC2904, August 2000, 864 . 866 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 867 Levkowetz, Ed., "Extensible Authentication Protocol 868 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 869 . 871 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 872 "SEcure Neighbor Discovery (SEND)", RFC 3971, 873 DOI 10.17487/RFC3971, March 2005, 874 . 876 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 877 RFC 3972, DOI 10.17487/RFC3972, March 2005, 878 . 880 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 881 "Multicast Security (MSEC) Group Key Management 882 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 883 . 885 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 886 Kerberos Network Authentication Service (V5)", RFC 4120, 887 DOI 10.17487/RFC4120, July 2005, 888 . 890 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 891 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 892 January 2006, . 894 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 895 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 896 2006, . 898 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 899 Pre-Shared Key Extensible Authentication Protocol (EAP) 900 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 901 . 903 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 904 Authorization, and Accounting (AAA) Key Management", 905 BCP 132, RFC 4962, DOI 10.17487/RFC4962, July 2007, 906 . 908 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 909 and A. Yegin, "Protocol for Carrying Authentication for 910 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 911 May 2008, . 913 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 914 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 915 March 2008, . 917 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 918 and A. Bierman, Ed., "Network Configuration Protocol 919 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 920 . 922 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 923 Bormann, "Neighbor Discovery Optimization for IPv6 over 924 Low-Power Wireless Personal Area Networks (6LoWPANs)", 925 RFC 6775, DOI 10.17487/RFC6775, November 2012, 926 . 928 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 929 "Enrollment over Secure Transport", RFC 7030, 930 DOI 10.17487/RFC7030, October 2013, 931 . 933 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 934 Constrained-Node Networks", RFC 7228, 935 DOI 10.17487/RFC7228, May 2014, 936 . 938 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 939 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 940 Transport Layer Security (TLS) and Datagram Transport 941 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 942 June 2014, . 944 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 945 Application Protocol (CoAP)", RFC 7252, 946 DOI 10.17487/RFC7252, June 2014, 947 . 949 [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 950 Architecture for Network Roaming", RFC 7593, 951 DOI 10.17487/RFC7593, September 2015, 952 . 954 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 955 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 956 . 958 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 959 "A Voucher Artifact for Bootstrapping Protocols", 960 RFC 8366, DOI 10.17487/RFC8366, May 2018, 961 . 963 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 964 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 965 . 967 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 968 Touch Provisioning (SZTP)", RFC 8572, 969 DOI 10.17487/RFC8572, April 2019, 970 . 972 [SEP2.0] ZigBee Alliance, "ZigBee IP Specification", March 2014, 973 . 976 [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure 977 Bootstrapping of Cloud-Managed Ubiquitous Displays", 978 Proceedings of ACM International Joint Conference on 979 Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 980 739-750, Seattle, USA , September 2014, 981 . 983 [simpleconn] 984 Wi-Fi Alliance, "Wi-Fi Simple Configuration", Wi-Fi 985 Alliance , 2019, 988 . 990 [simplekey] 991 Bergmann, O., Gerdes, S., and C. Bormann, "Simple Keys for 992 Simple Smart Objects", Smart Object Security Workshop, 993 IETF 83 , March 2012. 995 [SimplePairing] 996 Bluetooth, SIG, "Simple pairing whitepaper", Technical 997 report , 2007. 999 [threadcommissioning] 1000 Thread Group, "Thread Commissioning", Thread Group, Inc. , 1001 2015. 1003 [TS33220] 3GPP, "3rd Generation Partnership Project; Technical 1004 Specification Group Services and System Aspects; Generic 1005 Authentication Architecture (GAA); Generic Bootstrapping 1006 Architecture (GBA) (Release 14)", December 2016, 1007 . 1009 [vendorcert] 1010 IEEE std. 802.1ar-2009, "Standard for local and 1011 metropolitan area networks - secure device identity", 1012 December 2009. 1014 [vermillard] 1015 Vermillard, J., "Bootstrapping device security with 1016 lightweight M2M", Appeared on blog at medium.com , 1017 February 2015. 1019 [wps] Wi-Fi Alliance, "Wi-fi protected setup", Wi-Fi Alliance , 1020 2007. 1022 Authors' Addresses 1024 Mohit Sethi 1025 Ericsson 1026 Hirsalantie 11 1027 Jorvas 02420 1028 Finland 1030 Email: mohit@piuha.net 1032 Behcet Sarikaya 1033 Denpel Informatique 1035 Email: sarikaya@ieee.org 1036 Dan Garcia-Carrillo 1037 Odin Solutions 1038 Murcia 30820 1039 Spain 1041 Email: dgarcia@odins.es