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