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]