Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Behcet Sarikaya
Last updated 2016-03-21
Replaced by draft-irtf-t2trg-security-setup-iot-devices, draft-irtf-t2trg-secure-bootstrapping
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-sarikaya-t2trg-sbootstrapping-00
Network Working Group                                        B. Sarikaya
Internet-Draft                                                     Y. Li
Intended status: Informational                                    Huawei
Expires: September 22, 2016                                     M. Sethi
                                                                Ericsson
                                                               R. Cragie
                                                                     ARM
                                                          March 21, 2016

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

Abstract

   This document presents a survey of secure bootstrapping mechanisms
   available for smart objects that are part of an Internet of Things
   (IoT) network.  It aims to provide a structured classification of the
   available mechanisms.  The document does not prescribe any one secure
   bootstrapping 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 http://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 22, 2016.

Copyright Notice

   Copyright (c) 2016 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

Sarikaya, et al.       Expires September 22, 2016               [Page 1]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

   (http://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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Analysis of available mechanisms  . . . . . . . . . . . . . .   3
     3.1.  Managed/Centralized . . . . . . . . . . . . . . . . . . .   4
     3.2.  P2P/Adhoc . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Miscellaneous . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   An Internet of Things (IoT) network is composed of connected things
   that cooperate together to accomplish tasks such as smart buildings,
   smart environment monitoring system, and intelligent transport
   systems.  The size of an IoT network varies from a couple of devices
   to tens of thousands depending on the application.  A smart object,
   or a things, or a device in an IoT network is typically produced by a
   variety of vendors and they are normally heterogeneous in terms of
   the constraints on their power supply, communication capability,
   computation capacity and memory available.

   Before classifying and describing the various methods of
   bootstrapping, it is important define what is meant by the term
   security bootstrapping.  There have been several varying definitions
   that have been used in different drafts and research papers.  For the
   purpose of this document, we define Security bootstrapping as
   follows: "it is the process by which a thing/device/smart object in
   an IoT network securely becomes operational at a given location and
   point of time."  This definition is broad on purpose since the term
   IoT itself represents a very diverse spectrum of application
   scenarios.  So for example, pairing of phones over bluetooth to
   exchange files, and securely connecting IEEE 802.15.4 sensors in a
   factory to the backend both require some form of secure bootstrapping

Sarikaya, et al.       Expires September 22, 2016               [Page 2]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

   to become operational.  Secure bootstrapping must result in either
   delivery or generation of some keying material for secure operation.
   This is different form simply joining a network with DHCP to
   communicate.

   It is also important to note that a device which simply connects to a
   service or entity using certificates and TLS/DTLS is not considered
   as bootstrapping and rather authentication.  This no different than
   using your laptop browser and connecting to an online service over
   HTTPS.  For the purpose of this draft, the focus is on secure
   bootstrapping rather than secure authentication.

   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].

2.  Terminology

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

3.  Analysis of available mechanisms

   We classify available bootstrapping solutions into the following
   three major categories:

   o  Managed/Centralized/AAA: These mechanisms rely on a centralized
      node or server for bootstrapping the IoT devices.  There is
      generally an implicit assumption that the devices being
      bootstrapped have some connectivity to the server or node that is
      responsible for bootstrapping the device.

   o  P2P/Adhoc: These mechanisms are traditionally used for
      establishing secure communication between two devices for ad-hoc
      communication, such as pairing two smart phones.  These methods do
      not rely on centralized server for bootstrapping.

   o  Miscellaneous: These methods rely on some components from both
      centralized and P2P mechanisms.  For example, they may use Public-
      keys and certificates but instead of relying on a centralized
      server, the devices being bootstrapped might simply exchange their
      public-key over an out-of-band channel to then derive share-
      secrets for further secure communication.

Sarikaya, et al.       Expires September 22, 2016               [Page 3]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

3.1.  Managed/Centralized

   This section provides some examples of centralized methods.

   Extensible Authentication Protocol (EAP) is an authentication
   framework that supports multiple authentication methods.  EAP is
   designed for use in network access authentication and typically runs
   directly over data link layers without IP.  Several EAP methods have
   been standardized for different purposes.  One widely used method is
   the EAP-TLS [RFC7250] which enables mutual authentication and
   distribute keying material to secure subsequent communications.
   However it only supports certificate-based mutual authentication,
   thus public key infrastructure is required.  The ZigBee Alliance has
   specified an IPv6 stack aimed at IEEE 802.15.4 devices mainly used in
   smart meters developed primarily for SEP 2.0 (Smart Energy Profile)
   application layer traffic [SEP2.0].  For secure bootstrapping, ZigBee
   IP uses EAP-TLS.

   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.

   EAP-IKEv2 [RFC5106] is an EAP method based on IKEv2.  It provides
   mutual authentication and session key establishment between an EAP
   peer and an EAP server.  It supports authentication techniques that
   are based on different credentials including asymmetric key pairs,
   symmetric keys and passwords.  Besides, it is possible to use a
   different authentication credential in each direction.  For example,
   the EAP server authenticates itself using public/private key pair and
   the EAP peer using symmetric key.  As a result different combinations
   of credentials are expected to be used in practice.  Compared with
   EAP-TLS and EAP-PSK, EAP-IKEv2 supports mobility and different
   authentication techniques.

   Generic Bootstrapping Architecture (GBA) is another bootstrapping
   method that falls in centralized category.  GBA is part of the 3GPP
   standard [3gppts33220] 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)

Sarikaya, et al.       Expires September 22, 2016               [Page 4]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

   database.  [I-D.sethi-gba-constrained] describes a resource-
   constrained implementation of GBA for IoT applications.

   Open Mobile Alliance (OMA) Light-weight M2M standard also defines
   secure bootstrapping for resource-constrained IoT devices with a
   centralized Bootstrapping Server (BS).  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.

   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 Kereberos for IoT devices[kerberosiot].

   ANIMA bootstrapping: TBD

3.2.  P2P/Adhoc

   P2P or adhoc methods are used for bootstrapping typically for
   creating local associations.  These local associations may later be
   used for connecting an IoT device to a centralized server.  These
   bootstrapping mechanisms typically rely on an out-of-band (OOB)
   channel in order to prevent man-in-the-middle (MitM) attacks.
   Contextual and location-dependent information on the OOB channel is
   assumed to be secret from anyone not present at the location where

Sarikaya, et al.       Expires September 22, 2016               [Page 5]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

   the bootstrapping takes place.Based on how the OOB channel is used,
   the P2P methods can be further classified into two sub categories:

   o  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.

   o  Key confirmation: A Diffie-Hellman key exchange occurs over the
      insecure network and the established key is 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.

   P2P/Adhoc methods might use a discrete OOB channel, such as Bluetooth
   simple pairing that relies on pin codes.  Alternatively these secure
   bootstrapping methods might rely on noisy sensory inputs such as
   audio.  These protocols have to cope with a fuzzy secret, i.e. noisy
   secret input that differs between the devices being bootstrapped.

3.3.  Miscellaneous

   As stated earlier, some secure bootstrapping methods rely on
   components from both adhoc and centralized categories.  We discuss
   some examples in this section.

   [I-D.kumar-6lo-selective-bootstrap] presents a selective
   bootstrapping/commissioning method by introducing the concept of
   Commissioning Tool (CT).  In this method the devices are let to
   connect to the network and execute 6LowPAN neighbor discovery
   protocol and have an IPv6 address before they are authenticated.
   Then the devices are selected one by one in some order to communicate
   with the CT via untrusted constructed route.  Once the ID of joining
   device is authenticated, CT sends the layer-2 key material to the
   device via secured channel, which is established by DTLS by
   exchanging credential material installed during manufacturing.

   Raw Public Key

   [RFC7250] defines how raw public keys can be used to authenticate
   constrained devices or in 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

Sarikaya, et al.       Expires September 22, 2016               [Page 6]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

   the keys by comparing the pre-configured values
   [I-D.sarikaya-6lo-bootstrapping-solution].

   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) where there is already a CoAP
   server which can also be the authentication server.

4.  Discussion

   It is evident that there are many different methods of secure
   bootstrapping available.  The choice on of the method is constrained
   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 categories might be suitable.  In this
   section we discuss some general guidelines that would help in
   selecting the right bootstrapping method.  TBD

5.  Security Considerations

   The whole draft deals with security considerations.

6.  Acknowledgements

   TBD

7.  References

7.1.  Normative References

   [IEEE802.15.4]
              IEEE Standard, , "IEEE Std. 802.15.4-2011", October 2011,
              <http://standards.ieee.org/findstds/
              standard/802.15.4-2011.html>.

   [IEEE802.15.9]
              IEEE P802.15.9/D01, "IEEE Draft Recommended Practice for
              transport of key management protocol (KMP) datagrams",
              November 2014,
              <http://grouper.ieee.org/groups/802/15/private/
              members_area.html>.

   [IEEE802.1x]
              IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network
              Access Control", February 2010,
              <http://standards.ieee.org/getieee802/
              download/802.1X-2010.pdf>.

Sarikaya, et al.       Expires September 22, 2016               [Page 7]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

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

   [proximate]
              Mathur, , Miller, , Varshavsky, , Trappe, , and Mandayam,
              "Proximate: proximity-based secure pairing using ambient
              wireless signals.", June 2011.

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

   [RFC3561]  Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
              Demand Distance Vector (AODV) Routing", RFC 3561,
              DOI 10.17487/RFC3561, July 2003,
              <http://www.rfc-editor.org/info/rfc3561>.

   [RFC3626]  Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
              State Routing Protocol (OLSR)", RFC 3626,
              DOI 10.17487/RFC3626, October 2003,
              <http://www.rfc-editor.org/info/rfc3626>.

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

   [RFC4728]  Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source
              Routing Protocol (DSR) for Mobile Ad Hoc Networks for
              IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007,
              <http://www.rfc-editor.org/info/rfc4728>.

   [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,
              <http://www.rfc-editor.org/info/rfc4764>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

Sarikaya, et al.       Expires September 22, 2016               [Page 8]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, DOI 10.17487/RFC4919, August 2007,
              <http://www.rfc-editor.org/info/rfc4919>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <http://www.rfc-editor.org/info/rfc4944>.

   [RFC5106]  Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y.,
              and F. Bersani, "The Extensible Authentication Protocol-
              Internet Key Exchange Protocol version 2 (EAP-IKEv2)
              Method", RFC 5106, DOI 10.17487/RFC5106, February 2008,
              <http://www.rfc-editor.org/info/rfc5106>.

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

   [RFC5487]  Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-
              256/384 and AES Galois Counter Mode", RFC 5487,
              DOI 10.17487/RFC5487, March 2009,
              <http://www.rfc-editor.org/info/rfc5487>.

   [RFC6345]  Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and
              A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA) Relay Element", RFC 6345,
              DOI 10.17487/RFC6345, August 2011,
              <http://www.rfc-editor.org/info/rfc6345>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <http://www.rfc-editor.org/info/rfc6550>.

   [RFC6786]  Yegin, A. and R. Cragie, "Encrypting the Protocol for
              Carrying Authentication for Network Access (PANA)
              Attribute-Value Pairs", RFC 6786, DOI 10.17487/RFC6786,
              November 2012, <http://www.rfc-editor.org/info/rfc6786>.

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

Sarikaya, et al.       Expires September 22, 2016               [Page 9]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

   [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, <http://www.rfc-editor.org/info/rfc7250>.

   [RFC7251]  McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
              CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
              TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
              <http://www.rfc-editor.org/info/rfc7251>.

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

   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
              2014, <http://www.rfc-editor.org/info/rfc7400>.

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

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

7.2.  Informative References

   [I-D.garcia-core-security]
              Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
              R. Struik, "Security Considerations in the IP-based
              Internet of Things", draft-garcia-core-security-06 (work
              in progress), September 2013.

   [I-D.he-iot-security-bootstrapping]
              ana.hedanping@huawei.com, a. and B. Sarikaya, "Security
              Bootstrapping of IEEE 802.15.4 based Internet of Things",
              draft-he-iot-security-bootstrapping-01 (work in progress),
              May 2015.

   [I-D.kumar-6lo-selective-bootstrap]
              Kumar, S. and P. Stok, "Security Bootstrapping over IEEE
              802.15.4 in selective order", draft-kumar-6lo-selective-
              bootstrap-00 (work in progress), March 2015.

Sarikaya, et al.       Expires September 22, 2016              [Page 10]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

   [I-D.kwatsen-netconf-zerotouch]
              Watsen, K., Hanna, S., Clarke, J., and M. Abrahamsson,
              "Zero Touch Provisioning for NETCONF Call Home
              (ZeroTouch)", draft-kwatsen-netconf-zerotouch-01 (work in
              progress), February 2014.

   [I-D.nikander-esp-beet-mode]
              Nikander, P. and J. Melen, "A Bound End-to-End Tunnel
              (BEET) mode for ESP", draft-nikander-esp-beet-mode-09
              (work in progress), August 2008.

   [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.pritikin-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., and S.
              Bjarnason, "Bootstrapping Key Infrastructures", draft-
              pritikin-anima-bootstrapping-keyinfra-02 (work in
              progress), July 2015.

   [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.

   [I-D.struik-6tisch-security-considerations]
              Struik, R., "6TiSCH Security Architectural
              Considerations", draft-struik-6tisch-security-
              considerations-01 (work in progress), January 2015.

   [MIT2014]  Herder, C., Farinaz Koushanfar, F., and S. Srinivas
              Devadas, "Physical Unclonable Functions and Applications:
              A Tutorial", Proceedings of the IEEE , vol. 102, no. 8,
              pp. 1126-1141, August 2014.

Sarikaya, et al.       Expires September 22, 2016              [Page 11]
Internet-Draft         IoT Bootstrapping Analysis             March 2016

Authors' Addresses

   Behcet Sarikaya
   Huawei
   5340 Legacy Dr. Building 3
   Plano, TX  75024
   USA

   Email: sarikaya@ieee.org

   Yizhou Li
   Huawei
   101 Software Avenue
   Nanjing  210012
   China

   Email: sarikaya@ieee.org

   Mohit Sethi
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: sarikaya@ieee.org

   Robert Cragie
   ARM
   110 Fulbourn Road
   Cambridge  CB1 9NJ
   UK

   Email: sarikaya@ieee.org

Sarikaya, et al.       Expires September 22, 2016              [Page 12]