[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                           M. Sethi
Internet-Draft                                                  Ericsson
Intended status: Informational                               B. Sarikaya
Expires: September 10, 2020                          Denpel Informatique
                                                      D. Garcia-Carrillo
                                                          Odin Solutions
                                                           March 9, 2020


                   Secure IoT Bootstrapping: A Survey
                 draft-sarikaya-t2trg-sbootstrapping-08

Abstract

   This draft provides an overview of the various terms that are used
   when discussing bootstrapping of devices.  We document terms that
   have been used within the IETF as well as other standards bodies.  We
   investigate if the terms refer to the same phenomena or have subtle
   differences.  We provide recommendations on the applicability of
   terms in different contexts.  Finally, this document presents a
   survey of secure bootstrapping mechanisms available for smart objects
   that are part of an Internet of Things (IoT) network.  The survey
   does not prescribe any one mechanism and rather presents IoT
   developers with different options to choose from, depending on their
   use-case, security requirements, and the user interface available on
   their smart objects.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2020.








Sethi, et al.          Expires September 10, 2020               [Page 1]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Usage of terms  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Device Provisioning Protocol  . . . . . . . . . . . . . .   4
     3.2.  Open Mobile Alliance (OMA) Lightweight M2M (LwM2M)  . . .   5
     3.3.  Open Connectivity Foundation  . . . . . . . . . . . . . .   5
     3.4.  Internet Engineering Task Force . . . . . . . . . . . . .   6
       3.4.1.  Enrollment over Secure Transport (EST)  . . . . . . .   6
       3.4.2.  Bootstrapping Remote Secure Key Infrastructures
               (BRSKI) . . . . . . . . . . . . . . . . . . . . . . .   6
       3.4.3.  Secure Zero Touch Provisioning  . . . . . . . . . . .   7
   4.  Comparsion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Classification of available mechanisms  . . . . . . . . . . .   7
   7.  IoT Device Bootstrapping Methods  . . . . . . . . . . . . . .   9
     7.1.  Managed Methods . . . . . . . . . . . . . . . . . . . . .   9
       7.1.1.  Bootstrapping in LPWAN  . . . . . . . . . . . . . . .  11
     7.2.  Peer to Peer or Adhoc Methods . . . . . . . . . . . . . .  13
     7.3.  Leap-of-faith/Opportunistic Methods . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   11. Informative References  . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   We informally define bootstrapping as "any process that takes place
   before a device can become operational".  While bootstrapping is
   necessary for all computing devices, until recently, most of our
   devices typically had sufficient computing power and user interface



Sethi, et al.          Expires September 10, 2020               [Page 2]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   (UI) for ensuring somewhat smooth operation.  For example, a typical
   laptop device required the user to setup a username/password as well
   as enter network settings for Internet connectivity.  Following these
   steps ensured that the laptop was fully operational.

   The problem of bootstrapping is however exacerbated for Internet of
   Things (IoT) networks.  The size of an IoT network varies from a
   couple of devices to tens of thousands, depending on the application.
   Smart objects/things/devices in IoT networks are produced by a
   variety of vendors and are typically heterogeneous in terms of the
   constraints on their power supply, communication capability,
   computation capacity, and user interfaces available.  This problem of
   bootstrapping in IoT was identified by Sethi et al.  [Sethi14] while
   developing a bootstrapping solution for smart displays.  Although
   this document focuses on bootstrapping terminology and methods for
   IoT devices, we do not exclude bootstrapping related terminology used
   in other contexts.

   Bootstrapping devices typically also involves providing them with
   some sort of network connectivity.  Indeed, the functionality of a
   disconnected device is rather limited.  Ipso facto, bootstrapping
   assumes that some network has been setup a-priori.  Setting up a
   network itself is challenging.  For example, the Wi-Fi Alliance
   Simple Configuration specification [simpleconn] helps users setup
   home networks.  This document is only focused on terminology
   associated with bootstrapping devices and excludes any discussion on
   setting up networks.

   In addition to our informal definition, it is helpful to look at
   other definitions of bootstrapping.  The IoT@Work project defines
   bootstrapping in the context of IoT as "the process by which the
   state of a device, a subsystem, a network, or an application changes
   from not operational to operational" [iotwork].  Vermillard
   [vermillard] , on the other hand, describes bootstrapping as the
   procedure by which an IoT device gets the URLs and secret keys for
   reaching the necessary servers.  Vermillard notes that the same
   process is useful for re-keying, upgrading the security schemes, and
   for redirecting the IoT devices to new servers.

   There are several terms that have often been used in the context of
   bootstrapping:

   o  Bootstrapping

   o  Provisioning

   o  Onboarding




Sethi, et al.          Expires September 10, 2020               [Page 3]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   o  Enrollment

   o  Commissioning

   o  Initialization

   o  Configuration

   o  Registration

   We attempt to find out whether all these terms refer to the same
   phenomena.  We begin by looking at how these terms have been used in
   various standards and standardization bodies in Section 3.  We then
   summarize our understanding in Section 4, and provide our
   recommendations on their usage in Section 5.  Section 6 provides a
   taxonomy of bootstrapping methods and Section 7 categorizes methods
   according to the taxonomy.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Usage of terms

3.1.  Device Provisioning Protocol

   Device provisioning protocol (DPP) [dpp] describes itself as a
   standardized protocol for providing user friendly Wi-Fi setup while
   maintaining or increasing the security.  DPP relies on a
   configurator, e.g. a smartphone application, for setting up all all
   other devices, called enrollees, in the network.  DPP has the
   following three phases/sub-protocols:

   o  Bootstrapping: The configurator obtains bootstrapping information
      from the enrollee using an out-of-band channel such as scanning a
      QR code or tapping NFC.  The bootstrapping information includes
      the public-key of the device and metadata such as the radio
      channel on which the device is listening.

   o  Authentication: In DPP, either the configurator or the enrollee
      can initiate the authentication protocol.  The side initiating the
      authentication protocol is called as the initiator while the other
      side is called the responder.  The authentication sub-protocol
      provides authentication of the responder to an initiator.  It can
      optionally authenticate the initiator to the responder (only if




Sethi, et al.          Expires September 10, 2020               [Page 4]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


      the bootstrapping information was exchange out-of-band in both
      directions).

   o  Configuration: Using the key established from the authentication
      protocol, the enrollee asks the configurator for network
      information such as the SSID and passphrase of the access point.

3.2.  Open Mobile Alliance (OMA) Lightweight M2M (LwM2M)

   The OMA LWM2M specification [oma] defines an architecture where a new
   device (LWM2M client) contacts a Bootstrap-server which is
   responsible for "provisioning" essential information such as
   credentials.  After receiving this essential information, the LwM2M
   client device "registers" itself with one or more LwM2M Servers which
   will manage the device during its lifecycle.  The current standard
   defines the following four bootstrapping modes:

   o  Factory Bootstrap: An IoT device in this case is configured with
      all the necessary bootstrap information during manufacturing and
      prior to its deployment.

   o  Bootstrap from Smartcard: An IoT device retrieves and processes
      all the necessary bootstrap data from a Smartcard.

   o  Client Initiated Bootstrap: This mode provides a mechanism for an
      IoT client device to retrieve the bootstrap information from a
      Bootstrap Server.  This requires the client device to have an
      account at the Bootstrap Server and credentials to obtain the
      necessary information securely.

   o  Server Initiated Bootstrap: In this bootstrapping mode, the
      bootstrapping server configures all the bootstrap information on
      the IoT device without receiving a request from the client.  This
      means that the bootstrap server needs to know if a client IoT
      Device is ready for bootstrapping before it can be configured.
      For example, a network may inform the bootstrap server of a new
      connecting IoT client device.

3.3.  Open Connectivity Foundation

   The Open Connectivitiy Foundation [ocf] defines the process before a
   device is operational as onboarding.  The first step of this
   onboarding process is "configuring" the ownership, i.e., establishing
   a legitimate user that owns the device.  For this, the user is
   supposed to use an Onboarding tool (OBT) and an Owner Transfer
   Methods (OTM).





Sethi, et al.          Expires September 10, 2020               [Page 5]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   The Onboarding tool (OBT) is described as a logical entity that may
   be implemented on a single or multiple entities such as a home
   gateway, a device management tool, etc.  OCF lists several optional
   Owner Transfer Methods (OTMs).  At the end of the execution of an
   OTM, the Onboarding tool must have "provisioned" an Owner Credential
   onto the device.  The following owner transfer methods are specified:

   o  Just works: Performs an un-authenticated Diffie-Hellman key
      exchange over DTLS.  The key exchange results in a symmetric
      session key which is later used for provisioning.  Naturally, this
      mode is vulnerable to Man-in-The-Middle (MiTM) attackers.

   o  Random PIN: The device generates a PIN code that is entered into
      the onboarding tool by the user.  This pin code is used together
      with TLS-PSK ciphersuites for establishing a symmetric session
      key.  OCF recommends PIN codes to have an entropy of 40 bits.

   o  Manufacturer certificate: An onboarding tool authenticates the
      device by verifying a manufacturer installed certificate.
      Similarly, the device may authenticate the onboarding tool by
      verifying its signature.  Fo

   o  Vendor specific: Vendors implement their own transfer method that
      accommodates any specific device constraints.

   Once the onboarding tool and the new device have authenticated and
   established secure communication, the onboarding tool
   "provisions"/"configures" the device with Owner credentials.  Owner
   credentials may consist of certificates, shared keys, or Kerberos
   tickets for example.

   The OBT will ....

3.4.  Internet Engineering Task Force

3.4.1.  Enrollment over Secure Transport (EST)

   [RFC7030]

3.4.2.  Bootstrapping Remote Secure Key Infrastructures (BRSKI)

   The ANIMA working group is working on a bootstrapping solution for
   devices that relies on 802.1AR vendor certificates called
   Bootstrapping Remote Secure Key Infrastructures (BRSKI)
   [I-D.ietf-anima-bootstrapping-keyinfra].  In addition to vendor
   installed IEEE 802.1AR certificates, a vendor based service on the
   Internet is required.  Before being authenticated, a new device only
   needs link-local connectivity, and does not require a routable



Sethi, et al.          Expires September 10, 2020               [Page 6]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   address.  When a vendor provides an Internet based service, devices
   can be forced to join only specific domains.  The document highlights
   that the described solution is aimed in general at non-constrained
   (i.e. class 2+ defined in [RFC7228]) devices operating in a non-
   challenged network.  It claims to scale to thousands of devices
   located in hostile environments, such as ISP provided CPE devices
   which are drop-shipped to the end user.

3.4.3.  Secure Zero Touch Provisioning

   [RFC8572] defines a bootstrapping strategy for enabling devices to
   securely obtain all the configuration information with no installer
   input, beyond the actual physical placement and connection of cables.
   Their goal is to enable a secure NETCONF [RFC6241] or RESTCONF
   [RFC8040] connection to the deployment specific network management
   system (NMS).  This bootstrapping method requires the devices to be
   configured with trust anchors in the form of X.509 certificates.
   [RFC8572] is similar to BRSKI based on [RFC8366], but using a
   different set of assumptions ....

4.  Comparsion

   There are several stages before a device becomes fully operational.
   This typically involves establishing some initial trust after which
   credentials and other parameter.

5.  Recommendations

   TBD

6.  Classification of available mechanisms

   While some bootstrapping approaches are more user-intensive and
   require extensive user-involvement by scanning QR codes or entering
   passwords; others maybe more automated, such as those that rely on
   mobile networks [I-D.sethi-gba-constrained].  We classify available
   bootstrapping solutions into the following major categories:

   o  Managed methods: These bootstrapping methods rely on pre-
      established trust relations and authentication credentials.  They
      typically utilize centralized servers for authentication, although
      several such servers may join to form a distributed federation.
      Example methods include Extensible Authentication Protocol (EAP)
      [RFC3748], Generic Bootstrapping Architecture (GBA) [TS33220],
      Kerberos [RFC4120], Bootstrapping Remote Secure Key
      Infrastructures (BRSKI) and vendor certificates [vendorcert].  EAP
      Transport Layer Security EAP-TLS [RFC5216] for instance assumes
      that both the client and the server have certificates to



Sethi, et al.          Expires September 10, 2020               [Page 7]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


      authenticate each other.  Based on this authentication, the server
      would then authorize the client for network access.  The Eduroam
      federation [RFC7593] uses a network of such servers to support
      roaming clients.

   o  Opportunistic and leap-of-faith methods: In these bootstrapping
      methods, rather than verifying the initial authentication, the
      continuity of the initial identity or connection is verified.
      Some of these methods assume that the attacker is not present
      during the initial setup.  Example methods include Secure Neighbor
      Discovery (SEND) [RFC3971] and Cryptographically Generated
      Addresses (CGA) [RFC3972], Wifi Protected Setup (WPS) push button
      [wps], and Secure Shell (SSH) [RFC4253].

   o  Hybrid methods: Most deployed methods are hybrid and use
      components from both managed and ad-hoc methods.  For instance,
      central management may be used for devices after they have been
      registered with the server using ad-hoc registration methods.

   o  Peer-to-Peer (P2P) and Ad-hoc methods: These bootstrapping methods
      do not rely on any pre-established credentials.  Instead, the
      bootstrapping protocol results in credentials being established
      for subsequent secure communication.  Such bootstrapping methods
      typically perform an unauthenticated Diffie-Hellman exchange [dh]
      and then use an out-of-band (OOB) communication channel to prevent
      a man-in-the-middle attack (MitM).  Various secure device pairing
      protocols fall in this category.  Another example P2P or Ad-hoc
      method is EAP-NOOB [I-D.aura-eap-noob] that specifies nimble out-
      of-band authentication for EAP.  Based on how the OOB channel is
      used, the P2P methods can be further classified into two sub
      categories:

      *  Key derivation: Contextual information received over the OOB
         channel is used for shared key derivation.  For example,
         [proximate] relies on the common radio environment of the
         devices being paired to derive the shared secret which would
         then be used for secure communication.

      *  Key confirmation: A Diffie-Hellman key exchange occurs over the
         insecure network and the established key is used to
         authenticate with the help of the OOB channel.  For example,
         Bluetooth simple pairing [SimplePairing] use the OOB channel to
         ask the user to compare pins and approve the completed
         exchange.

   It is important to note here that categorization of different
   bootstrapping methods is not always easy or clear.  For example, all
   the opportunistic and leap-of-faith methods become managed methods



Sethi, et al.          Expires September 10, 2020               [Page 8]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   after the initial vulnerability window.  The choice of bootstrapping
   method used for devices depends heavily on the business case.
   Questions that may govern the choice include: What third parties are
   available?  Who wants to retain control or avoid work?  In each
   category, there are many different methods of secure bootstrapping
   available.  The choice of the method may also be governed by the type
   of device being bootstrapped.  Depending on the link-layer technology
   used, and the User Interface (UI) available, one or more of the above
   mentioned methods might be suitable.

7.  IoT Device Bootstrapping Methods

   In this section we look at some of the recent bootstrapping proposals
   for IoT devices both at the IETF and elsewhere.  Needless to say, if
   the devices are capable in terms of their computation power and UI
   available, they can always rely on many existing methods such as
   username and password combinations and various EAP methods.

7.1.  Managed Methods

   We first discuss some examples of managed bootstrapping methods.

   EAP-TLS is a widely used EAP method for network access authentication
   [RFC7250].  It allows mutual authentication and distributes the
   keying material for secure subsequent communications.  However it
   only supports certificate-based mutual authentication, and therefore
   a public key infrastructure is required.  The ZigBee Alliance has
   specified an IPv6 stack aimed at IEEE 802.15.4 [IEEE802.15.4] devices
   mainly used in smart meters developed primarily for SEP 2.0 (Smart
   Energy Profile) application layer traffic [SEP2.0].  The ZigBee IP
   stack uses EAP-TLS for secure bootstrapping of devices.

   EAP-PSK [RFC4764] is another EAP method.  It realizes mutual
   authentication and session key derivation using a Pre-Shared Key
   (PSK).  Normally four messages are exchanged in the authentication
   process.  Once the authentication is successful, EAP-PSK provides a
   protected communication channel.  Given the light-weight nature of
   EAP-PSK, it can often be a good choice on constrained devices.

   CoAP-EAP [I-D.marin-ace-wg-coap-eap] defines a bootstrapping service
   for IoT.  They propose the transport of EAP over CoAP [RFC7252] for
   the constrained link, and communication with AAA infrastructures in
   the non-constrained link to provide scalability among other
   characteristics.  Upon a successful authentication, key material is
   derived to protect CoAP messages exchanged between the smart object
   and the authenticator.  They discuss the use of EAP-PSK in the draft,
   but state that, since they are specifying a new EAP lower layer, any




Sethi, et al.          Expires September 10, 2020               [Page 9]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   EAP method that results in generation of cryptographic material is
   suitable.

   Protocol for Carrying Authentication for Network Access (PANA)
   [RFC5191] is a network layer protocol with which a node can
   authenticate itself to gain access to the network.  PANA does not
   define a new authentication protocol and rather uses EAP over User
   Datagram Protocol (UDP) for authentication.  Colin O'Flynn
   [I-D.oflynn-core-bootstrapping] proposes the use of PANA for secure
   bootstrapping of resource constrained devices.  He demonstrates how a
   6LowPAN Border Router (PANA Authentication Agent (PAA)) can
   authenticate the identity of a joining constrained device (PANA
   Client).  Once the constrained device has been successfully
   authenticated, the border router can also provide network and
   security parameters to the joining device.  Hernandez-Ramos et al.
   [panaiot] also use EAP-TLS over PANA for secure bootstrapping of
   smart objects.  They also extend their bootstrapping scheme for
   configuring additional keys that are used for secure group
   communication.

   When a device is not a direct neighbor of the authenticator, its
   parent node MUST act as relay.  Different EAP encapsulation protocols
   have different mechanisms for the relay function, such as the PANA
   Relay Element (PRE).

   After a successful bootstrapping, the device runs neighbor discovery
   protocol to get an IPv6 address assigned [RFC6775].  Data transfer
   can be secured using DTLS or IPSec.  Keys derived from EAP TLS are
   used in either generating DTLS ciphering keys after a successful DTLS
   handshake or IPSec ESP ciphering keys after a successful IKEv2
   handshake.

   Generic Bootstrapping Architecture (GBA) is another bootstrapping
   method that falls in centralized category.  GBA is part of the 3GPP
   standard [TS33220] and is based on 3GPP Authentication and Key
   Agreement (3GPP AKA).  GBA is an application independent mechanism to
   provide a client application (running on the User equipment (UE)) and
   any application server with a shared session secret.  This shared
   session secret can subsequently be used to authenticate and protect
   the communication between the client application and the application
   server.  GBA authentication is based on the permanent secret shared
   between the UE's Universal Integrated Circuit Card (UICC), for
   example SIM card, and the corresponding profile information stored
   within the cellular network operator's Home Subscriber System (HSS)
   database.  [I-D.sethi-gba-constrained] describes a resource-
   constrained adaptation of GBA to IoT applications.





Sethi, et al.          Expires September 10, 2020              [Page 10]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   The four bootstrapping modes specified by the Open Mobile Alliance
   (OMA) Light-weight M2M (LwM2M) standard require some sort of pre-
   provisioned credentials on the device.  All the four modes are
   examples of managed bootstrapping methods.

   The Kerberos protocol [RFC4120] is a network authentication protocol
   that allows several endpoints to communicate over an insecure
   network.  Kerberos relies on a symmetric cryptography scheme and
   requires a trusted third party, that guarantees the identities of the
   various actors.  It relies on the use of "tickets" for nodes to prove
   identity to one another in a secure manner.  There has been research
   work on using Kerberos for IoT devices [kerberosiot].

   It is also important to mention some of the work done on implicit
   certificates and identity-based cryptographic schemes [himmo],
   [implicit].  While these are interesting and novel schemes that can
   be a part of securely bootstrapping devices, at this point, it is
   hard to speculate on whether such schemes would see large-scale
   deployment in the future.

7.1.1.  Bootstrapping in LPWAN

   Low Power Wide Area Network (LPWAN) encompasses a wide variety of
   technologies, generally, with severe constraints in the link in
   comparison with other typical IoT technologies such as Bluetooth or
   IEEE 802.15.4.  LPWAN typically presents a star topology with support
   for thousands of devices per antenna.

   Among the wide variety of technologies considered as part of LPWAN,
   we highlight the ones mentioned in the LPWAN overview document of the
   LPWAN working group [RFC8376]: LoRaWAN, Narrowband IoT (NB-IoT),
   SIGFOX and Wi-SUN Alliance Field Area Network (FAN).  Each technology
   has different methods to provide security for the communications.
   Bootstrapping is not directly tackled by all of them, having in some
   cases proprietary solutions that are not publicly accessible and in
   other cases key distribution is not even considered.  Among the
   previous LPWAN technologies, bootstrapping is considered in Wi-SUN
   Alliance Field Area Network (FAN) and LoRaWAN provides Joining
   process to derive key material based on some previous key material
   installed in the device.

   Following the definition in Section 6 we find that they all fall into
   the managed classification.  This is because in one way or another, a
   previous trust relationship has been established and authentication
   credentials have been installed in the devices.

   o  LoRaWAN [LoRaWAN] describes its own protocol to authenticate their
      nodes and incorporate them into their network.  This process is



Sethi, et al.          Expires September 10, 2020              [Page 11]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


      called the Joining Procedure and it is based on pre-shared keys.
      The Joining procedure entails one exchange where the node that
      intends to join the network sends its identity along with other
      information to authenticate against a network server which
      interacts with an entity that knows the pre-shared key (called
      AppKey) and derives the necessary key material for its nominal
      operation.  There is some variation regarding the pre-installed
      key material on version 1.0 and 1.1, but the Joining Process is
      very similar in both cases.  The Joining Process consists of an
      exchange of two messages, the Join-request message (sent from the
      node) where information about the identity of the node is provided
      and the Join-accept message (received by the node).  In this last
      message the node receives the necessary information to derive the
      key material to secure the communications To this process there
      are adaptations to use AAA infrastructures to enhance the joining
      process with AAA features such as identity federation.  Since
      there are pre-established trust relationships and authentication
      credentials, LoRaWAN falls into the managed category.

   o  Wi-SUN Alliance Field Area Network (FAN) uses an EAP lower layer
      (IEEE 802.1X) and the EAP-TLS method for network access
      authentication and performs the 4-way handshake to establish a
      security association similarly to a WPA2-Enterprise deployment.
      Since it uses on the authentication protocols which are used to
      exemplify the managed methods (EAP-TLS), WI-SUN falls in the
      managed category as well.

   o  NB-IoT also falls into the category of managed methods, since they
      present a pre-established trust relationship.  For instance, they
      have support for EAP-AKA.

   o  Sigfox provides security to the communications using a unique
      device ID and an cryptographic keys that are independent for each
      device.  As stated in [RFC8376] algorithms and keying details for
      are not published, but what we can see is that the establishment
      of the keys are subject to a pre-established trust relationship
      with the Sigfox network, hence having also a managed method.

   In short, LPWANs are still under development, and as it is identified
   in [RFC8376], due to the characteristics of these technologies, they
   are prime candidates to benefit from a standardized Authentication,
   Accounting, and Authorization (AAA) infrastructure [RFC2904] as a way
   of offering a scalable solution for some of the security and
   management issues that are present in LPWANs.







Sethi, et al.          Expires September 10, 2020              [Page 12]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


7.2.  Peer to Peer or Adhoc Methods

   While managed methods are viable for many IoT devices, they may not
   be suitable or desirable in all scenarios.  All the managed methods
   assume that some credentials are provisioned into the device.  These
   credentials may be in the device micro-controller or in a replaceable
   smart card such as a SIM card.  The methods also sometimes assume
   that the manufacturer embeds these credentials during the device
   manufacture on the factory floor.  However, in many cases the
   manufacturer may not have sufficient incentive to do this.  In other
   scenarios, it may be hard to completely trust and rely on the device
   manufacturer to securely perform this task.  Therefore, many times,
   P2P or Adhoc methods of bootstrapping are used.  We discuss a few
   example next.

   P2P or ad-hoc bootstrapping methods are used for establishing keys
   and credential information for secure communication without any pre-
   provisioned information.  These bootstrapping mechanisms typically
   rely on an out-of-band (OOB) channel in order to prevent man-in-the-
   middle (MitM) attacks.  P2P and ad-hoc methods have typically been
   used for securely pairing personal computing devices such as smart
   phones. [devicepairing] provides a survey of such secure device
   pairing methods.  Many original pairing schemes required the user to
   enter the same key string or authentication code to both devices or
   to compare and approve codes displayed by the devices.  While these
   methods can provide reasonable security, they require user
   interaction that is relatively unnatural and often considered a
   nuisance.  Thus, there is ongoing research for more natural ways of
   pairing devices.  To reduce the amount of user-interaction required
   in the pairing process, several proposals use contextual or location-
   dependent information, or natural user input such as sound or
   movement, for device pairing [proximate].

   The local association created between two devices may later be used
   for connecting/introducing one of the devices to a centralized
   server.  Such methods would however be classified as hybrids.

   EAP-NOOB [I-D.aura-eap-noob] is an example of P2P and ad-hoc
   bootstrapping method that establishes a security association between
   an IoT device (node) and an online server (unlike pairing two devices
   for local connections over WiFi or Bluetooth).

   EAP-NOOB defines an EAP method where the authentication is based on a
   user-assisted out-of-band (OOB) channel between the server and peer.
   It is intended as a generic bootstrapping solution for Internet-of-
   Things devices which have no pre-configured authentication
   credentials and which are not yet registered on the authentication
   server.  This method claims to be more generic than most ad-hoc



Sethi, et al.          Expires September 10, 2020              [Page 13]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   bootstrapping solutions in that it supports many types of OOB
   channels.  The exact in-band messages and OOB message contents are
   specified and not the OOB channel details.  Also, EAP-NOOB supports
   IoT devices with only output (e.g. display) or only input (e.g.
   camera).  It makes combined use of both secrecy and integrity of the
   OOB channel for more robust security than the ad-hoc solutions.

   Thread Group commissioning [threadcommissioning] introduces a two
   phased process i.e. Petitioning and Joining.  Entities involved are
   Leader, Joiner, Commissioner, Joiner Router and Border Router.
   Leader is the first device in Thread Network that must be
   commissioned using out-of-band process and is used to inject correct
   user generated Commissioning Credentials (can be changed later) into
   Thread Network.  Joiner is the node that intends to get authenticated
   and authorized on Thread Network.  Commissioner is either within the
   Thread Network (Native) or connected with Thread Network via a WLAN
   (External).

   Under some topologies, Joiner Router and Border Router facilitate the
   Joiner node to reach Native and External Commissioner, respectively.
   Petitioning begins before Joining process and is used to grant sole
   commissioning authority to a Commissioner.  After an authorized
   Commissioner is designated, eligible thread devices can join network.
   Pair-wise key is shared between Commissioner and Joiner, network
   parameters (Network Name, Security Policy, Steering Data,
   Commissioning Data Timestamp, Commissioning Credential, Network
   Master Key, Network Key Sequence, Network Mesh-Local ULA, Border
   Router Locator, Commissioner Session ID, XPANID, PANID and Channel)
   are sent out securely (using pair-wise key) by Joiner Router to
   Joiner for letting Joiner to join the Thread Network.  Entities
   involved in Joining process depends on system topology i.e. location
   of Commissioner and Joiner.

   Thread networks only operates using IPv6.  Thread devices can devise
   GUAs (Global Unicast Addresses) [RFC4291].  Provision also exist via
   Border Router, for Thread device to acquire individual global address
   by means of DHCPv6 or using SLAAC (Stateless Address
   Autoconfiguration) address derived with advertised network prefix.

   DPP bootstrapping explained earlier is an example of ad-hoc
   bootstrapping method.

7.3.  Leap-of-faith/Opportunistic Methods

   Next, we look at a leap-of-faith/opportunistic bootstrapping method
   for IoT devices.





Sethi, et al.          Expires September 10, 2020              [Page 14]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   Bergmann et al. [simplekey] develop a secure bootstrapping mechanism
   that does not rely on pre-provisioned credentials using resurrecting-
   duckling imprinting scheme.  Their bootstrapping protocol involves
   three distinct phases: discover (the duckling node searches for
   network nodes that can act as mother node), imprint (the mother node
   imprints a shared secret establishing a secure channel once a
   positive response is received for the imprinting request) and
   configure (additional configuration information such as network
   prefix and default gateway are configured).  In this model for
   bootstrapping, a small initial vulnerability window is acceptable and
   can be mitigated using techniques such as a Faraday Cage (securing
   the communication physically) to protect the environment of the
   mother and duck nodes, though this may be inconvenient for the user.

   [RFC7250] defines how raw public keys can be used to authenticate
   constrained devices for mutual authentication using EAP-TLS or DTLS.
   Raw public key TLS/DTLS extension simplifies client_certificate_type
   and server_certificate_type to carry only SubjectPublicKeyInfo
   structure with the raw public key instead of many other parameters
   found in the certificates.  The device and the authentication server
   (AS) exchange client_hello and server_hello messages and send their
   raw public keys.  The device and AS validate the keys by comparing
   the pre-configured values [I-D.sarikaya-6lo-bootstrapping-solution].
   This bootstrapping method can be seen as a hybrid.  This is because
   it generally requires an out-of-band (OOB) step (P2P/Ad-hoc) where
   the raw public keys [RFC7250] are provided to the authenticating
   entities, after which the actual authentication occurs online
   (managed).  Raw public key approach when used with DTLS offers a
   simple secure bootstrapping solution especially for smart energy and
   building automation applications.  It can be easily integrated with
   the Constrained Application Protocol (CoAP).

8.  Security Considerations

   Bootstrapping protocols that do not rely on a pre-shared key for peer
   authentication generally rely on an online or offline third-party
   (e.g., an authentication server, a key distribution center in
   Kerberos, a certification authority in PKI, a private key generator
   in ID-based cryptography and so on) to prevent man-in-the-middle
   attacks during bootstrapping.  Depending on use cases, a resource-
   constrained device may not always have access to an online third-
   party for bootstrapping.  Some bootstrapping methods therefore rely
   on a configuration tool (such as a smartphone) that assists the
   bootstrapping process by providing temporary reachability to the
   online server.

   Depending on use cases, a bootstrapping protocol may deal with
   authorization separately from authentication in terms of timing and



Sethi, et al.          Expires September 10, 2020              [Page 15]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   signaling path.  For example, two resource-constrained devices A and
   B may perform mutual authentication using authentication credentials
   provided by an offline third-party X whereas resource-constrained
   device A obtains authorization for running a particular application
   with resource-constrained device B from an online third-party Y
   before or after the authentication.  In some use cases,
   authentication and authorization are tightly coupled, e.g.,
   successful authentication also means successful authorization.

   If authorization information communicated includes cryptographic
   keys, care must be taken for provisioning the keys, e.g., guidelines
   for AAA-based key management are described in [RFC4962].  Re-
   bootstrapping of IoT devices may required and therefore there must be
   adequate provisions for revocation and re-bootstrapping of
   authentication/authorization credentials.  Re-bootstrapping must be
   as secure as the initial bootstrapping regardless of whether this re-
   bootstrapping is done manually or automatically over the network.

   If resource-constrained devices use a multicast group key for
   authentications of peers that belong to the group, or for message
   authentication/encryption, the group key must be securely distributed
   to the current members of the group.  Protocols designed for group
   key management [RFC4046] may be used for group key distribution after
   the initial bootstrapping.  Alternatively, key wrap attributes for
   securely encapsulating group key may be defined in network access
   authentication protocols such as PANA.  Those protocols use an end-
   to-end, point-to-point communication channel with a pair-wise
   security association between a key distribution center and each key
   recipient.  Further considerations may be needed for more efficient
   group key management to support a large number of resource-
   constrained devices.

9.  IANA Considerations

   There are no IANA considerations for this document.

10.  Acknowledgements

   We would like to thank Tuomas Aura, Hannes Tschofenig, and Michael
   Richardson for providing extensive feedback as well as Rafa Marin for
   his support.

11.  Informative References

   [devicepairing]
              Mirzadeh, S., Cruickshank, H., and R. Tafazolli, "Secure
              Device Pairing: A Survey", IEEE Communications Surveys and
              Tutorials , pp. 17-40, 2014.



Sethi, et al.          Expires September 10, 2020              [Page 16]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   [dh]       Diffie, W. and M. Hellman, "New directions in
              cryptography", IEEE Transactions on Information Theory ,
              vol. 22, no. 6, pp. 644-654, 1976.

   [dpp]      Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol
              (DPP)", Wi-Fi Alliance , 2018, <https://www.wi-
              fi.org/download.php?file=/sites/default/files/private/
              Device_Provisioning_Protocol_Specification_v1.1_1.pdf>.

   [himmo]    Garcia-Morchon, O., Rietman, R., Sharma, S., Tolhuizen,
              L., and J. Torre-Arce, "DTLS-HIMMO: Efficiently Securing a
              Post-Quantum World with a Fully-Collusion Resistant KPS",
              Submitted to NIST Workshop on Cybersecurity in a Post-
              Quantum World , version 20141225:065757, December 2014,
              <https://eprint.iacr.org/2014/1008>.

   [I-D.aura-eap-noob]
              Aura, T. and M. Sethi, "Nimble out-of-band authentication
              for EAP (EAP-NOOB)", draft-aura-eap-noob-07 (work in
              progress), October 2019.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-35 (work in progress), February 2020.

   [I-D.marin-ace-wg-coap-eap]
              Lopez, R. and D. Garcia, "EAP-based Authentication Service
              for CoAP", draft-marin-ace-wg-coap-eap-06 (work in
              progress), October 2017.

   [I-D.oflynn-core-bootstrapping]
              Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security
              Bootstrapping of Resource-Constrained Devices", draft-
              oflynn-core-bootstrapping-03 (work in progress), November
              2010.

   [I-D.sarikaya-6lo-bootstrapping-solution]
              Sarikaya, B., "Secure Bootstrapping Solution for Resource-
              Constrained Devices", draft-sarikaya-6lo-bootstrapping-
              solution-00 (work in progress), June 2013.

   [I-D.sethi-gba-constrained]
              Sethi, M., Lehtovirta, V., and P. Salmela, "Using Generic
              Bootstrapping Architecture with Constrained Devices",
              draft-sethi-gba-constrained-01 (work in progress),
              February 2014.



Sethi, et al.          Expires September 10, 2020              [Page 17]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   [IEEE802.15.4]
              "IEEE Std. 802.15.4-2015", April 2016,
              <http://standards.ieee.org/findstds/
              standard/802.15.4-2015.html>.

   [implicit]
              Porambage, P., Schmitt, C., Kumar, P., Gurtov, A., and M.
              Ylianttila, "Pauthkey: A pervasive authentication protocol
              and key establishment scheme for wireless sensor networks
              in distributed iot applications", International Journal of
              Distributed Sensor Networks , Hindawi Publishing
              Corporation , 2014.

   [iotwork]  European Commission FP7, "IoT@Work bootstrapping
              architecture Deliverable D2.2", June 2011.

   [kerberosiot]
              Hardjono, T., "Kerberos for Internet-of-Things", February
              2014, <https://kit.mit.edu/sites/default/files/documents/
              Kerberos_Internet_of%20Things.pdf>.

   [LoRaWAN]  Sornin, N., Luis, M., Eirich, T., and T. Kramp, "LoRa
              Specification V1.0", January 2015, <https://www.lora-
              alliance.org/portals/0/specs/
              LoRaWAN%20Specification%201R0.pdf>.

   [ocf]      Open Connectivity Foundation, "OCF Security
              Specification", Open Connectivitiy Foundation , June 2017,
              <https://openconnectivity.org/specs/
              OCF_Security_Specification_v1.0.0.pdf>.

   [oma]      Open Mobile Alliance, "Lightweight Machine to Machine
              Technical Specification: Core", Open Mobile Alliance ,
              June 2019,
              <http://www.openmobilealliance.org/release/LightweightM2M/
              V1_1_1-20190617-A/OMA-TS-LightweightM2M_Core-
              V1_1_1-20190617-A.pdf>.

   [panaiot]  Hernandez-Ramos, J., Carrillo, D., Marin-Lopez, R., and A.
              Skarmeta, "Dynamic Security Credentials PANA-based
              Provisioning for IoT Smart Objects", 2nd World Forum on
              Internet of Things (WF-IoT) , IEEE , 2015.

   [proximate]
              Mathur, S., Miller, R., Varshavsky, A., Trappe, W., and N.
              Mandayam, "Proximate: proximity-based secure pairing using
              ambient wireless signals.", Proceedings of MobiSys
              International Conference , pp. 211-224, June 2011.



Sethi, et al.          Expires September 10, 2020              [Page 18]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2904]  Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
              Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
              D. Spence, "AAA Authorization Framework", RFC 2904,
              DOI 10.17487/RFC2904, August 2000,
              <https://www.rfc-editor.org/info/rfc2904>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <https://www.rfc-editor.org/info/rfc3748>.

   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971,
              DOI 10.17487/RFC3971, March 2005,
              <https://www.rfc-editor.org/info/rfc3971>.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005,
              <https://www.rfc-editor.org/info/rfc3972>.

   [RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
              "Multicast Security (MSEC) Group Key Management
              Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005,
              <https://www.rfc-editor.org/info/rfc4046>.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              DOI 10.17487/RFC4120, July 2005,
              <https://www.rfc-editor.org/info/rfc4120>.

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
              January 2006, <https://www.rfc-editor.org/info/rfc4253>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4764]  Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
              Pre-Shared Key Extensible Authentication Protocol (EAP)
              Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,
              <https://www.rfc-editor.org/info/rfc4764>.




Sethi, et al.          Expires September 10, 2020              [Page 19]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
              Authorization, and Accounting (AAA) Key Management",
              BCP 132, RFC 4962, DOI 10.17487/RFC4962, July 2007,
              <https://www.rfc-editor.org/info/rfc4962>.

   [RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
              and A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
              May 2008, <https://www.rfc-editor.org/info/rfc5191>.

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <https://www.rfc-editor.org/info/rfc5216>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <https://www.rfc-editor.org/info/rfc7250>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.






Sethi, et al.          Expires September 10, 2020              [Page 20]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   [RFC7593]  Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
              Architecture for Network Roaming", RFC 7593,
              DOI 10.17487/RFC7593, September 2015,
              <https://www.rfc-editor.org/info/rfc7593>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              <https://www.rfc-editor.org/info/rfc8366>.

   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
              <https://www.rfc-editor.org/info/rfc8376>.

   [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
              Touch Provisioning (SZTP)", RFC 8572,
              DOI 10.17487/RFC8572, April 2019,
              <https://www.rfc-editor.org/info/rfc8572>.

   [SEP2.0]   ZigBee Alliance, "ZigBee IP Specification", March 2014,
              <hhttp://www.zigbee.org/non-menu-pages/zigbee-ip-
              download/>.

   [Sethi14]  Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure
              Bootstrapping of Cloud-Managed Ubiquitous Displays",
              Proceedings of ACM International Joint Conference on
              Pervasive and Ubiquitous Computing (UbiComp 2014), pp.
              739-750, Seattle, USA , September 2014,
              <http://dx.doi.org/10.1145/2632048.2632049>.

   [simpleconn]
              Wi-Fi Alliance, "Wi-Fi Simple Configuration", Wi-Fi
              Alliance , 2019, <https://www.wi-
              fi.org/download.php?file=/sites/default/files/private/Wi-F
              i_Simple_Configuration_Technical_Specification_v2.0.7.pdf>
              .

   [simplekey]
              Bergmann, O., Gerdes, S., and C. Bormann, "Simple Keys for
              Simple Smart Objects", Smart Object Security Workshop,
              IETF 83 , March 2012.






Sethi, et al.          Expires September 10, 2020              [Page 21]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   [SimplePairing]
              Bluetooth, SIG, "Simple pairing whitepaper", Technical
              report , 2007.

   [threadcommissioning]
              Thread Group, "Thread Commissioning", Thread Group, Inc. ,
              2015.

   [TS33220]  3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; Generic
              Authentication Architecture (GAA); Generic Bootstrapping
              Architecture (GBA) (Release 14)", December 2016,
              <http://www.3gpp.org/DynaReport/33220.htm>.

   [vendorcert]
              IEEE std. 802.1ar-2009, "Standard for local and
              metropolitan area networks - secure device identity",
              December 2009.

   [vermillard]
              Vermillard, J., "Bootstrapping device security with
              lightweight M2M", Appeared on blog at medium.com ,
              February 2015.

   [wps]      Wi-Fi Alliance, "Wi-fi protected setup", Wi-Fi Alliance ,
              2007.

Authors' Addresses

   Mohit Sethi
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: mohit@piuha.net


   Behcet Sarikaya
   Denpel Informatique

   Email: sarikaya@ieee.org









Sethi, et al.          Expires September 10, 2020              [Page 22]


Internet-Draft         IoT Bootstrapping Analysis             March 2020


   Dan Garcia-Carrillo
   Odin Solutions
   Murcia  30820
   Spain

   Email: dgarcia@odins.es













































Sethi, et al.          Expires September 10, 2020              [Page 23]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/