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

Versions: 00 01 02 03 04 05 06

Network Working Group                                        B. Sarikaya
Internet-Draft                                                    Huawei
Intended status: Informational                                  M. Sethi
Expires: January 2, 2017                                        Ericsson
                                                            July 1, 2016


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

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 January 2, 2017.

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
   (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



Sarikaya & Sethi         Expires January 2, 2017                [Page 1]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


   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.  Classification of available mechanisms  . . . . . . . . . . .   5
   4.  IoT Device Bootstrapping Methods  . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   An Internet of Things (IoT) network consists 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 thing,
   or a device in an IoT network is typically produced by a variety of
   vendors and are typically heterogeneous in terms of the constraints
   on their power supply, communication capability, computation capacity
   and memory available.  Due to this heterogeneity, a wide variety of
   bootstrapping mechanisms are proposed and used for these smart
   objects.

   Before classifying and describing the various methods of
   bootstrapping, it is important discuss what is meant by the term
   bootstrapping.  In order to understand the term bootstrapping, we
   need to discuss some important preliminaries first.  We start by
   discussing the meaning of identity and identifiers.  The dictionary
   defines identity as "something that distinguishes an entity form
   other entities".  Dick Hardt in his keynote talk on identity
   describes human identity as "who you are, what you like, what you say
   about yourself and what others say about you" [dickhardt].  In
   addition to human beings, other entities in our physical environment
   such as the electronic devices we use, our pets and wildlife also
   have identities.

   Just as in the real world, humans also have identities in the digital
   world.  For example, a digital identity may be used by online service
   to verify the identity of a registered user and provide it with
   secure personalized service.  This process of identity verification



Sarikaya & Sethi         Expires January 2, 2017                [Page 2]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


   is also known as authentication.  An attribute that can be used to
   identify and distinguish one entity from another is referred to as an
   identifier.  The passport number of a citizen is an example of an
   real-world identifier.  Similarly, an email address is an example of
   a digital identifier.  Often the digital identifier of a human user
   and the digital identifier of its electronic devices are used
   interchangeably and one may subsume the other for authentication
   purposes.  For instance, when performing network access
   authentication, the user may enter its identity credentials on the
   device that should connect to the network.  In this case, the device
   assumes the user identity on its behalf and authenticates to obtain
   network access.  Ubiquitous computing devices increasingly interact
   with each other without human intervention.  This essentially
   requires the devices to have their own identifiers for authentication
   and secure communication.

   With these preliminaries in mind, we try to decipher the meaning of
   bootstrapping.  The term itself has often been used in many different
   contexts.  For instance, [RFC4640] describes bootstrapping as the
   process by which a mobile IPv6 node obtains information about the
   home address, the home agent address, and a security association.
   The IoT@Work project defines bootstrapping in the context of Internet
   of Things (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].  [I-D.oflynn-core-bootstrapping] also
   discusses the problem of secure bootstrapping for resource-
   constrained devices and highlights the role of IETF in defining
   suitable solutions.  The authors of this document define
   bootstrapping as any process that is required before the resource-
   constrained device network can operate.  Similarly, Vermillard
   [vermillard] describes bootstrapping as the procedure by which an IoT
   device gets the secret keys and URL for reaching the necessary
   servers.  Vermillard notes that this procedure is also useful for re-
   keying, upgrading the security schemes and for redirecting the
   devices to other servers.  The term device onboarding refers to
   similar ideas and is often used interchangeably with the term
   bootstrapping.  As an example, the AllSeen Alliance [allseen] defines
   onboarding as a service that provides a common and simple way for new
   devices to be brought onto an existing WiFi network.  Some solutions
   and standards organizations distinguish the processes involved in
   bootstrapping into the following sub-processes:

   a.  initial establishment of keys and configuration information

   b.  subsequent provisioning of keys and configuration information

   The Open Connectivity Foundation (OCF), for example, uses the term
   onboarding for (a) and bootstrapping for (b).  Some specifications



Sarikaya & Sethi         Expires January 2, 2017                [Page 3]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


   consider (a) out of scope and assume that this information is
   manufacturer provisioned.  However, in many cases the two processes
   are interdependent and may require business agreements and/or
   protocols to ensure security for both the sub-processes.  Instead of
   providing yet another definition of bootstrapping, here we list the
   different goals that bootstrapping may be used to fulfill:

   o  Authentication of a pre-established identity or creation of a new
      identity: To illustrate this with an example, consider the case
      where a user wishes to use one of the many free online mail
      services.  The user in this case needs to first register and
      create a unique identifier (email address) for its identity.
      Thereafter, the user will use this email address along with the
      password to authenticate and access the mails.  Both these
      processes can be considered as a part of bootstrapping.

   o  Authorization for network access that may include configuration of
      communication parameters: Bootstrapping also includes the process
      by which a device authenticates to the network and receives
      authorization and credentials for subsequent secure communication.

   o  Registration or joining a domain or group: The process by which a
      windows device joins a windows domain can also be seen as
      bootstrapping.

   o  Pairing with a specific node, or connecting to a cloud service:
      Securely pairing two personal computing devices that have no
      a-priori information about each other, and securely connecting a
      device to an online cloud service are both different forms of
      bootstrapping.

   It is evident that bootstrapping maybe used in many diverse scenarios
   to fulfill different goals.  Thus, it is not surprising that there
   are many different bootstrapping protocols and methods available.
   Rather than trying to achieve the impossible target of enlisting all
   the different bootstrapping solutions, we instead classify them into
   the following categories in section 3.

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







Sarikaya & Sethi         Expires January 2, 2017                [Page 4]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


3.  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) [gba],
      Kerberos [RFC4120], and vendor certificates [vendorcert].  EAP
      Transport Layer Security EAP-TLS [RFC5216] for instance assumes
      that both the client and the server have certificates to
      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  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 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 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.

   o  Opportunistic and leap-of-faith methods: In these bootstrapping
      methods, rather than verifying the initial authentication, the



Sarikaya & Sethi         Expires January 2, 2017                [Page 5]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


      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].  Additionally, various
      online services such as Gmail and Facebook allow anyone to create
      a new identity during the initial setup and later only verify the
      continuity of the same identity.

   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.

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

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

   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.




Sarikaya & Sethi         Expires January 2, 2017                [Page 6]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


   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.

   EAP-COAP [I-D.marin-ace-wg-coap-eap] uses EAP transported over CoAP
   [RFC7252] messages for authenticating two CoAP endpoints and
   configuring key material to protect CoAP messages exchanged between
   them.  They discuss the use of EAP-PSK in the draft, but state that
   any 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
   [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.

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



Sarikaya & Sethi         Expires January 2, 2017                [Page 7]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


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

   The ANIMA working group is also working on a bootstrapping solution
   for resource-constrained devices that relies on 802.1AR vendor
   certificates [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
   address.  When a vendor provides an Internet based service, devices
   can be forced to join only specific domains.  The draft 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.

   [I-D.kumar-6lo-selective-bootstrap] presents a selective
   bootstrapping/commissioning method by introducing the concept of



Sarikaya & Sethi         Expires January 2, 2017                [Page 8]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


   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, the CT sends the layer-2 key material to the
   device via secured channel.  This secure channel is established with
   DTLS with credential material that has to be installed onto the
   device during its manufacture.

   [I-D.ietf-netconf-zerotouch] 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 [I-D.ietf-netconf-restconf] connection to the
   deployment specific network management system (NMS).  This
   bootstrapping method requires the devices to be manufactured with
   trust anchors in the form of X.509 certificates.

   Before closing the discussion on managed methods, 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.

   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.  This
   credentials may be in the device micro-controller or in a replaceable
   smart cards 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



Sarikaya & Sethi         Expires January 2, 2017                [Page 9]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


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

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

   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 to protect
   the environment of the mother and duck nodes, though this may be
   inconvenient for the user.




Sarikaya & Sethi         Expires January 2, 2017               [Page 10]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


   [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) band step (P2P/Ad-hoc)
   where the raw public keys 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).

5.  Security Considerations

   The whole draft deals with security considerations.

6.  IANA Considerations

   There are no IANA considerations for this document.

7.  Acknowledgements

   We would like to thank Tuomas Aura and Hannes Tschofenig for
   providing extensive feedback.

8.  Informative References

   [allseen]  AllSeen Alliance, "Onboarding service",
              <https://allseenalliance.org/framework/documentation/
              learn/base-services/onboarding>.

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

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

   [dickhardt]
              Hardt, D., "Identity 2.0", OSCON , 2005.



Sarikaya & Sethi         Expires January 2, 2017               [Page 11]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


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

   [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-00 (work in
              progress), February 2016.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., and S.
              Bjarnason, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-03 (work in progress), June 2016.

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-14 (work in
              progress), June 2016.

   [I-D.ietf-netconf-zerotouch]
              Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning
              for NETCONF or RESTCONF based Management", draft-ietf-
              netconf-zerotouch-08 (work in progress), April 2016.

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

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








Sarikaya & Sethi         Expires January 2, 2017               [Page 12]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


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

   [IEEE802.15.4]
              IEEE Standard, , "IEEE Std. 802.15.4-2011", October 2011,
              <http://standards.ieee.org/findstds/
              standard/802.15.4-2011.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 Commision FP7, "IoT@Work bootstrapping
              architecture Deliverable D2.2", June 2011.

   [kerberosiot]
              Hardjono, , "Kerberos for Internet-of-Things", February
              2014, <https://kit.mit.edu/sites/default/files/documents/
              Kerberos_Internet_of%20Things.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, , Miller, , Varshavsky, , Trappe, , and Mandayam,
              "Proximate: proximity-based secure pairing using ambient
              wireless signals.", June 2011.




Sarikaya & Sethi         Expires January 2, 2017               [Page 13]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


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

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

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

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

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

   [RFC4640]  Patel, A., Ed. and G. Giaretta, Ed., "Problem Statement
              for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
              DOI 10.17487/RFC4640, September 2006,
              <http://www.rfc-editor.org/info/rfc4640>.

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

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





Sarikaya & Sethi         Expires January 2, 2017               [Page 14]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


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

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

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

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

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

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

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

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

   [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", February 2015.




Sarikaya & Sethi         Expires January 2, 2017               [Page 15]


Internet-Draft         IoT Bootstrapping Analysis              July 2016


   [wps]      IEEE Standard, , "Wi-fi protected setup", 2007.

Authors' Addresses

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

   Email: sarikaya@ieee.org


   Mohit Sethi
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: mohit@piuha.net































Sarikaya & Sethi         Expires January 2, 2017               [Page 16]


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