[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                         A. He, Ed.
Internet-Draft                                                    Huawei
Intended status: Informational                          B. Sarikaya, Ed.
Expires: September 10, 2015                                   Huawei USA
                                                           March 9, 2015

      IoT Security Bootstrapping: Survey and Design Considerations


   This document presents the importance of security bootstrapping for
   IoT networks, analyzes the state-of-the-art works in standard
   organizations and discusses what should be considered when designing
   the secure bootstrapping mechanism.

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 10, 2015.

Copyright Notice

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

He & Sarikaya          Expires September 10, 2015               [Page 1]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Analysis of Related State-of-the-art Works  . . . . . . . . .   3
     3.1.  Security bootstrapping  . . . . . . . . . . . . . . . . .   3
       3.1.1.  Authentication framework  . . . . . . . . . . . . . .   4
       3.1.2.  Credential Material and Architecture  . . . . . . . .   7
     3.2.  Higher Layer Protocol Use After/During Bootstrapping  . .   9
   4.  Role of IoT Security Bootstrapping  . . . . . . . . . . . . .  10
   5.  Design Considerations . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Able to clearly define security dependency and trust
           domains . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Cross-layer design  . . . . . . . . . . . . . . . . . . .  12
     5.3.   Reduce human interaction to the minimum  . . . . . . . .  12
     5.4.  Able to resist attacks  . . . . . . . . . . . . . . . . .  13
     5.5.  Low computation cost and communication overhead . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

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, intelligent transport system,
   etc.  The size of IoT varies from tens to thousands depending on the
   application, and things in an IoT network might be produced by
   different vendors and they are normally heterogeneous with various
   constraints e.g. power supply, communication capability, CPU and

   IEEE 802.15.4 specifies the physical layer and media access control
   for low-rate wireless personal area networks (LR-WPANs).  It is
   widely used in wireless sensor networks nowadays and is foreseen as
   the most used lower layer protocol for low rate IoT networks with
   resource constrained devices.  In IETF, 6LoWPAN (concluded) developed
   RFC 4944 [RFC4944] to describe how to transmit IPv6 packets over
   802.15.4, and support mesh routing in LR-WPANs. 6lo defines generic
   IPv6 packet header compression method [RFC7400] for LR-WPANs.  6tisch
   tries to build adaptation protocols for IEEE 802.15.4e specification.
   Roll develops routing protocol RPL [RFC6550] for IPv6 based low power
   and lossy networks.  Note that IEEE 802.15.4 can be applied to mobile
   nodes, routing protocols such as AODV [RFC3561], DSL [RFC4728], OLSR
   [RFC3626] by MANET group are also widely used.  CoAP [RFC7252] from

He & Sarikaya          Expires September 10, 2015               [Page 2]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   CoRE defines a UDP based web transfer protocol for machine- to-
   machine (M2M) applications such as smart energy and building

   The above mentioned protocols provide different selections of IoT
   protocol stacks to fulfill specific tasks based on IEEE 802.15.4.  At
   the start-up phase of a network or after the provisioned
   communications have failed, bootstrapping is typically required to
   configure nodes at all layers, including anything from link-layer
   information (i.e., wireless channels, link-layer encryption keys) to
   application-layer information (i.e., network names, application
   encryption keys).  It can be realized either manually via user
   interface or automatically via interaction between nodes.

   Traditional bootstrapping approaches tend to impose configuration
   burdens upon users.  For example, users need to follow a series of
   instruction steps for configuration.  Configuring IoT devices becomes
   more complicated since they don't always provide user interface to
   input all necessary information, and the scale of the IoT network can
   be large, dynamic or error prone.  As a result, human intervention is
   expensive and not efficient in those situations.  This motivates the
   need for self-organization and automatic self-bootstrapping in IoT.
   Enabling a plug & play framework not only reduces human efforts in
   configuring IoT but also improve the scalability and flexibility.
   This draft presents a survey of the state-of-the-art works on
   bootstrapping/networking in IETF, ZigBee Alliance, IEEE and Thread
   group, and the design considerations for security bootstrapping are

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in

3.  Analysis of Related State-of-the-art Works

   Bootstrapping is required at all layers, where different conditions
   and information should be transferred for different protocols.  This
   section provides analysis on the existing bootstrapping works in
   standard organizations and summarizes the concerns.

3.1.  Security bootstrapping

   Security bootstrapping includes the authentication of devices to
   establish trust relationships in a network, as well as transferring
   security parameters and keying materials.  Security bootstrapping is

He & Sarikaya          Expires September 10, 2015               [Page 3]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   believed as the fundamental part of bootstrapping, because once
   secure and authentic channels are established, the bootstrapping of
   all other information can be conducted as ordinary secured
   communications.  Accordingly, many works focus on security
   bootstrapping and device authentication.  In IETF,
   [I-D.pritikin-anima-bootstrapping-keyinfra] is proposed in Anima,
   [I-D.sarikaya-6lo-bootstrapping-solution] is proposed in 6lo,
   [I-D.struik-6tisch-security-considerations] is in 6tisch,
   [I-D.kwatsen-netconf-zerotouch] is in Netconf, and
   [I-D.he-iot-security-bootstrapping] is proposed for bootstrapping
   IEEE 802.15.4 based IoT networks.  ZigBee IP stack is developed by
   ZigBee Alliance and it supports EAP-TLS and PANA as authentication
   protocols.  In Thread Group, a networking solution is developed.  The
   devices are authenticated through pre-installed codes.  IEEE 802.15.4
   also defines two-step mechanism for nodes joining network with layer
   2 authentication without considering IP infrastructure.

3.1.1.  Authentication framework

   The arguments on authentication framework focus on EAP, PANA, HIP-
   DEX, 802.1X via EAPOL, and IKEv2.

   [I-D.oflynn-core-bootstrapping] relates the aforementioned
   authentication frameworks into IEEE 802.15.4 and requirements in
   order to use them for bootstrapping procedure.

   o  If PANA is used, a new entity called PANA Relay Element should be
      added in the architecture and behavior of PANA RE needs to be
      defined [RFC6345]; New AVPs needed for PANA Relay Element
      operation for relaying messages from the client to the
      authenticator and vice versa are required to be specified.  If
      PANA is used to securely distribute group key [RFC6786] from the
      PANA Authentication Agent to the PANA Client using AES Key Wrap
      with padding algorithm, an extension to PANA needs to be defined.

   o  If HIP-DEX is used, the initiator should be able to get the IP
      address of the responder, either using DNS infrastructure or local

   o  If 802.1X is used, a special value in the Frame Type subfield of
      the Frame Control Field of IEEE 802.15.4 MAC header should be
      assigned to indicate the type of the payload.  Group addresses for
      802.15.4 corresponding to EAPOL Group Address Assignments defined
      in Table 11.1 of [IEEE802.1x] are required, especially for EAPOL-
      Start packet.  The mapping of MAC frames and security level to
      different types should be defined, for instance: which MAC frames
      of beacon, data, acknowledgment and MAC command as defined in
      [IEEE802.15.4] with what security levels are mapped to controlled

He & Sarikaya          Expires September 10, 2015               [Page 4]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

      port, which MAC frames with what security levels are mapped to
      uncontrolled port and which MAC frames are never mapped to any of
      controlled/uncontrolled port (i.e., the payload of those frames
      are used by the MAC-layer itself and never used by upper layers).

   [I-D.garcia-core-security] discusses about using Internet Key
   Exchange protocol version 2 (IKEv2) as authentication method.  It
   summarizes that IKEv2 can perform key exchanges and the setup of
   security associations without online connections to a trust center.
   It provides end-to-end security, and supports host mobility with
   MOBIKE extension.  However, MOBIKE mandates the use of IPsec tunnel
   mode which requires to transmit an additional IP header in each
   packet.  This additional overhead could be alleviated by using header
   compression methods or the Bound End-to-End Tunnel (BEET) mode
   [I-D.nikander-esp-beet-mode], a hybrid of tunnel and transport mode
   with smaller packet headers.

   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 and
   fragmentation is needed when using IEEE 802.15.4 to exchange
   authentication messages.

   ZigBee Alliance 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].  This
   specification assumes Class 2 devices which have 50 KiB of RAM and
   250 KiB of flash memory [RFC7228].  Some devices in such systems have
   more resources and processing power (e.g.  ARM9 core, MiBs RAM/
   Flash).  For security bootstrapping, ZigBee IP uses EAP-TLS.

   Authentication that is not based on certificates reduces cost of
   certificate management and fewer messages are needed to be exchanged
   between client and server.  [I-D.sarikaya-6lo-bootstrapping-solution]
   proposes to use raw public keys via EAP-TLS, thus extension to EAP-
   TLS is indicated.  Note that EAP requires exchanging the device
   identity in plain text at the beginning, but how to protect the
   privacy information indicated in the device ID is out of concern of
   EAP methods.

   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.

He & Sarikaya          Expires September 10, 2015               [Page 5]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   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.

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

   The bootstrapping method in [I-D.kumar-6lo-selective-bootstrap]
   creates security risks for the network by

   1.  letting the devices have IP addresses for layer3 communication
       before authentication.

   2.  constructing routing topology before devices are authenticated.

   3.  establishing transport layer security before layer-2 security.

   However, such a protocol could be justified in some application
   domains like lightning control systems.

   There is work going on in the IEEE 802.15.9 task group which
   specifies a way to transport existing key management protocols (KMP)
   over the 802.15.4 frames.  The new feature would allow running IKEv2,
   EAP,PANA, 802.1X, HIP and Dragonfly over the IEEE 802.15.4 and
   generate keys for 802.15.4 security and protect all messages between
   the two nodes [IEEE802.15.9].  It would be desired if the security
   bootstrapping procedure reuses the KMPs that supported by lower
   layers to reduce cost.

   Table 1 summarizes the authentication frameworks and credential
   materials of the aforementioned solutions.

He & Sarikaya          Expires September 10, 2015               [Page 6]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   | Referenced solution                 | Authentication | Credential |
   |                                     | method         | material   |
   | [I-D.pritikin-anima-bootstrapping-k | 802.1x-EAPOL,  | 802.1AR ce |
   | eyinfra]                            | EAP-TLS, EAP-  | rtificate  |
   |                                     | IKEv2          |            |
   | [I-D.sarikaya-6lo-bootstrapping-sol | EAP-TLS        | Raw public |
   | ution]                              | (modified)     | key        |
   | [I-D.struik-6tisch-security-conside | Joining        | Certificat |
   | rations]                            | Protocol       | e          |
   |                                     | (undefined)    |            |
   | [I-D.kwatsen-netconf-zerotouch]     | Unspecified    | X.509 cert |
   |                                     | (EAP-TLS might | ificate    |
   |                                     | be used)       |            |
   | [I-D.he-iot-security-bootstrapping] | EAP, PANA      | Unspecifie |
   |                                     |                | d          |
   | [I-D.kumar-6lo-selective-bootstrap] | Selected by    | PSK        |
   |                                     | Commissioner   | defined in |
   |                                     | with CT        | CT         |
   | ZigBee IP stack based Smart Energy  | EAP-TLS, PANA  | Certificat |
   |                                     |                | e          |
   | Thread networking                   | Unknown        | Product    |
   |                                     |                | install    |
   |                                     |                | codes      |

                                  Table 1

3.1.2.  Credential Material and Architecture

   The trust relationship can be established by exchanging credential
   materials, which can be asymmetric with user authentication or with
   certificate authority, or symmetric pre-shared key configured by
   network developer.  In certificate authority (CA), a typical public
   key infrastructure (PKI) is used, meaning that a set of hardware,
   software, people, policies, and procedures are needed to create,
   manage, distribute, use, store, and revoke digital certificates.  The
   public keys are obtained in PKI containers, and both ends are
   validated using trust anchors based on a certification authority
   (CA).  [I-D.pritikin-anima-bootstrapping-keyinfra] uses 802.1AR
   certificate, [I-D.kwatsen-netconf-zerotouch] uses X.509 certificate.
   Certificate mechanism provides high security however it can add a
   complicated trust relationship that is difficult to validate.  When
   it comes to large scale IoT networks, certificate management and
   distribution will raise scalability and flexibility issue.  Besides,
   the time spent and CPU occupied by the cryptographic operations is
   non-trivial when this mechanism is implemented on computational

He & Sarikaya          Expires September 10, 2015               [Page 7]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   constraint devices.  Since some IEEE802.15.4 technologies including
   802.15.4e only allows 127 Octets maximum payload, fragmentation is
   unavoidable, which indicates that a large amount of data is
   transmitted and communication overhead is heavy.  The public-key
   based handshake process of EAP-TLS is part of the bottleneck that
   significantly degrades the performance.  Designers are forced to use
   highly efficient protocols for the sake of ensuring the computational
   complexity of security algorithms as low as possible.

   In today's IoT, most common architectures are fully centralized in a
   sense that all the security relationships within a segment are
   handled by a central party.

   The 802.1x framework, the architecture proposed in
   [I-D.pritikin-anima-bootstrapping-keyinfra] and the ZigBee IP smart
   energy solution are centralized.  A centralized authentication
   architecture allows for central management of devices and keying
   materials as well as for the backup of cryptographic keys.  As a
   result there is no high requirement on network devices in a
   centralized architecture.  However it also represents a single point
   of failure and is more suitable for static network where the route to
   the trust center/AAA server is stable.

   The self-signed certificates are commonly used in smaller deployments
   where they are distributed to all involved protocol endpoints out-of-
   band, thus CA and certificate management are not required.  This
   practice does, however, still require the overhead of the certificate
   generation even though none of the information found in the
   certificate is actually used.

   The raw public key method is proposed to generate light weight
   certificate, which can significantly reduce overhead.  However, the
   self-signed certificate and raw public key only prove the possession
   of the private-public key pair and are unable to prove whether the
   owner is legitimate.

   The pre-shared key based mechanisms are more suitable for constrained
   environments, e.g. wireless communications, and limited CPU power
   devices.  It enables mutual authentication, meanwhile requires less
   cryptographic operations and less communication overhead compared
   with certificate based mechanism.  However, traditional approaches of
   key generation/distribution tend to impose configuration burdens upon
   users.  For example, users need to follow a series of instruction
   steps for WiFi Protected Access 2, Pre-shared key (WPA2-PSK)
   configuration, even though the pre-shared key mode is the simplest
   option for using WPA.  Establishing security among IoT devices
   becomes more complicated since they don't always provide user
   interface to input necessary security information.

He & Sarikaya          Expires September 10, 2015               [Page 8]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   As discussed, the authentication of self-signed certificate and pre-
   shared key mechanisms are distributed.  Distributed architecture
   allows creating ad-hoc security domains that might not require a
   single online management entity and are operative in a much more
   stand-alone manner.  In this case, hardware should be configured to
   be able to authenticate and verify other peers.

   In today's IoT, most common architectures are fully centralized in a
   sense that all the security relationships within a segment are
   handled by a central party.

   The Thread protocol is expected to use product install codes as
   authentication material.  Currently not enough details are available
   on the Thread protocol.

   Physical unclonable function (PUF) arises as a promising
   authentication technology.  PUF is a physical entity that is embodied
   in a physical structure and is easy to evaluate but hard to predict.
   Further, an individual PUF device must be easy to make but
   practically impossible to duplicate, even given the exact
   manufacturing process that produced it.  In this respect it is the
   hardware analog of a one-way function.  PUFs can serve as a root of
   the trust and can provide a key which cannot be easily reverse
   engineered.  Temperature and aging have been given special attention
   on developing reliable PUF [MIT2014].

3.2.  Higher Layer Protocol Use After/During Bootstrapping

   Configurations of parameters for other protocols are important as
   well to ensure a successful networking.  Those parameters are
   transferred upon a successful security bootstrapping.

   The IP address configuration is a major issue which must be solved
   before any other higher layer service can start.  It can be locally
   pre-configured, auto-configured or managed from a third party tool.

   o  Pre-configured: is mainly what is done today.  No further network
      service is needed, the assignment is done from a planning/
      commissioning tool instead.  This method requires human
      interaction, devices with IP configured are trusted by default.
      scalability and flexibility cannot be satisfied in this case.

   o  Auto-configuration: the device creates its IP address itself,
      applying one of the algorithms specified in the relevant
      standards, e.g.  ZigBee IP solved this problem by using SLAAC IPv6
      addresses based on the EUI-64;
      [I-D.pritikin-anima-bootstrapping-keyinfra] suggests to obtain an
      IP address using existing methods, such as SLAAC or DHCPv6.  RPL

He & Sarikaya          Expires September 10, 2015               [Page 9]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

      [RFC6550] is a special routing protocol that generates for each
      device an IP prefix based on the constructed routing topology,
      thus special attention should be paid as chicken/egg issue arises
      when relay of authentication is needed by the network level
      bootstrapping.  The auto-configured IP address may need to perform
      a check for duplicates (i.e.  APIPA17).  Encoding of semantics
      into the address may need information from lower layer (see above)
      or from network service.  Note, this only works for so-called link
      local-addresses which are valid only in one Ethernet domain.

   o  Managed: pre-planned addresses are assigned by means of a third
      party database, such as DHCP, a central server.

4.  Role of IoT Security Bootstrapping

   Figure 1 shows a network life cycle: after IoT devices being deployed
   in field, the security bootstrapping starts.  Devices are
   authenticated, keying materials are exchanged for securing subsequent
   configuration/data exchange messages.  The device gets an IP address
   and joins the network.

    |          Device deployment           |
                     |             ------------+
    +----------------+---------------------+   |
    |    Network access authentication     |   |
    +----------------+---------------------+   |
                     |                         +->Security Bootstrapping
    +----------------+---------------------+   |
    |    Secured channel keying material   |   |
    +----------------+---------------------+   |
                     |             ------------+
    |    Secure communication in the network   |

                         Figure 1: IoT Life Cycle

5.  Design Considerations

   IoT can be deployed in different environments for different
   applications, which calls for protocols with options where a set of
   options is selected to construct a protocol stack that fits for a
   given environment, e.g. home, enterprise or industrial.  The
   deployment and configurations can also be divided into two types, one
   is for static network, and the other is for dynamic network.

He & Sarikaya          Expires September 10, 2015              [Page 10]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   IoT developed in buildings, homes, or industrial areas are often
   static.  A general approach is that a network engineer plans the
   locations for each device and determines topology of network based on
   deployment environment and channel estimation.  Then the key devices
   (e.g. sink nodes, or parent nodes of a routing protocol) are
   installed before deploying other devices.  Upon successful
   installation, the device is plugged and security bootstrapping is run
   in either centralized or distributed manner with pre-configured
   credential material.  The device is at work after all the protocols
   are successfully bootstrapped.  When a new device joins an existing
   network, the joining device bootstrapping procedure is triggered by

   In a dynamic network where devices come and go, their IPv6 addresses
   might also change.  Bootstrapping/re-commissioning at network level
   is more frequently required than that in static network, hence
   minimum human interaction is highly preferred.  Reducing
   communication overhead will improve the efficiency of networking, and
   this is especially useful for low bandwidth and low rate IEEE

   Mains-powered devices can stay continuously connected to the network.
   Normally-off power strategy can be used for battery powered devices
   where the devices sleep long periods of time and stay disconnected
   and reattach to the network after it is woken up.  Between these two
   extremes, there is low-power device mode where the devices need to be
   able to communicate on a relatively frequent basis
   [RFC7228].Bootstrapping protocol needs to be able to take into
   consideration these power levels in the design.

   The order of bootstrapping is another concern in designing the
   bootstrapping protocol.  The devices could arbitrarily be
   bootstrapped as they join the network, especially in dynamic
   topologies.  In static topologies the order could be completely
   installation and installer dependent and could be optimized to lower
   cost and could be independent of network topology
   [I-D.kumar-6lo-selective-bootstrap].  The order is also dependent on
   the architecture of authentication.  For centralized architecture,
   incremental approach is recommended by
   [I-D.he-iot-security-bootstrapping] , [I-D.garcia-core-security] and
   [I-D.sarikaya-6lo-bootstrapping-solution], whereas a selective order
   can be specified by CT [I-D.kumar-6lo-selective-bootstrap] and
   special attention should be paid on the secured channel establishment
   via untrusted route.  For decentralized architecture, the mutual-
   authentication is realized between equal peers in pure mesh topology
   without any preferred order and network keys can be distributed by
   cluster heads once clusters are formed.

He & Sarikaya          Expires September 10, 2015              [Page 11]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   Some mandatory considerations can be derived from different
   applications for IoT security bootstrapping mechanism:

5.1.  Able to clearly define security dependency and trust domains

   Things of IoT are more related to private data, thus trust increases
   its importance.  It is easy to introduce a new node in a deployed IoT
   to capture and analyze the data traffic.  As a result,

   a.  Security dependencies between different devices must be
       clarified.  Circular dependencies must be avoided.

   b.  The designed protocol should enable mutual authentication between
       devices running the security bootstrapping protocol.  Proper
       authentication material and mechanism should be chosen.

   c.  The security bootstrapping protocol processing devices should
       agree upon the security associations (e.g. key materials,
       algorithms etc.) for securing their communications before
       exchanging any protocol packets.

5.2.  Cross-layer design

   The security bootstrapping method should take into account the
   features and requirements of full stack protocols that are selected
   for an IoT network.  Security bootstrapping in collaboration with
   other networking protocols is likely to produce a comprehensive

   Cooperative communication and scheduling among neighboring things at
   lower layer will reduce the possibility of network congestion and
   assist finishing bootstrapping efficiently.  Different power modes
   should be considered by the designed protocol.

   As discussed in Section 3.2, higher layer protocols impact the
   procedure of bootstrapping.  During network start-up, link local IP
   address should be assigned in order to run PANA/TLS to forward
   authentication messages by IoT routing protocols such as AODV and DSR
   in MANET.  However, the RPL for LLN configures IP addresses for all
   the devices during/ at the end of routing procedure, which may create
   a chicken/egg issue when PANA/TLS are also used. 802.1X uses link
   layer address so no IP address is needed.

5.3.  Reduce human interaction to the minimum

   Configuring IoT devices can be complicated since they don't always
   provide user interface to input all necessary information, and the
   scale of the IoT network can be large, dynamic or error prone.

He & Sarikaya          Expires September 10, 2015              [Page 12]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   Besides, IoT network users usually do not have expertise in
   networking, this motivates self-organizing IoT network protocol that
   start from security bootstrapping.  As a result, the design of
   bootstrapping protocol should be able to reduce human interaction to
   the minimum.

5.4.  Able to resist attacks

   The designed bootstrapping protocol should be able to resist attacks
   and protect CIA triad.  Typical threat modeling approaches (e.g.
   STRIDE) should be used to guide the design of bootstrapping
   architecture and procedure.  STRIDE categorizes attack into spoofing,
   Tampering with data, Repudiation, Information disclosure, Denial of
   service and Elevation of privilege.

5.5.  Low computation cost and communication overhead

   The amount of transmitted data and the complexity of data processing
   should be optimized to the minimum to save computation and
   communication cost.

6.  Security Considerations


7.  Acknowledgements


8.  References

8.1.  Normative References

              IEEE Standard, , "IEEE Std. 802.15.4-2011", October 2011,

              IEEE P802.15.9/D01, "IEEE Draft Recommended Practice for
              transport of key management protocol (KMP) datagrams",
              November 2014,

He & Sarikaya          Expires September 10, 2015              [Page 13]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

              IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network
              Access Control", February 2010,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3561]  Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
              Demand Distance Vector (AODV) Routing", RFC 3561, July

   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol (OLSR)", RFC 3626, October 2003.

   [RFC4728]  Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source
              Routing Protocol (DSR) for Mobile Ad Hoc Networks for
              IPv4", RFC 4728, February 2007.

   [RFC4764]  Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
              Pre-Shared Key Extensible Authentication Protocol (EAP)
              Method", RFC 4764, January 2007.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [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, August 2007.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

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

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, March 2008.

   [RFC5487]  Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-
              256/384 and AES Galois Counter Mode", RFC 5487, March

He & Sarikaya          Expires September 10, 2015              [Page 14]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

   [RFC6345]  Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA) Relay Element", RFC 6345, August 2011.

   [RFC6550]  Winter, T., Thubert, P., 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, March 2012.

   [RFC6786]  Yegin, A. and R. Cragie, "Encrypting the Protocol for
              Carrying Authentication for Network Access (PANA)
              Attribute-Value Pairs", RFC 6786, November 2012.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228, May 2014.

   [RFC7250]  Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
              T. Kivinen, "Using Raw Public Keys in Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", RFC 7250, June 2014.

   [RFC7251]  McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
              CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
              TLS", RFC 7251, June 2014.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, November 2014.

   [SEP2.0]   ZigBee Alliance, "ZigBee IP Specification", March 2014,

8.2.  Informative References

              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.

He & Sarikaya          Expires September 10, 2015              [Page 15]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

              ana.hedanping@huawei.com, a., "Security Bootstrapping of
              IEEE 802.15.4 based Internet of Things", draft-he-iot-
              security-bootstrapping-00 (work in progress), January

              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.

              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.

              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.

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

              Pritikin, M., Behringer, M., and S. Bjarnason,
              "Bootstrapping Key Infrastructures", draft-pritikin-anima-
              bootstrapping-keyinfra-01 (work in progress), February

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

              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.

He & Sarikaya          Expires September 10, 2015              [Page 16]

Internet-Draft         IoT Bootstrapping Analysis             March 2015

Authors' Addresses

   Ana(Danping) He (editor)
   Building Q14, 156 Beiqing Road
   Beijing  100095

   Email: ana.hedanping@huawei.com

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

   Email: sarikaya@ieee.org

He & Sarikaya          Expires September 10, 2015              [Page 17]