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