Secure IoT Bootstrapping: A Survey
draft-sarikaya-t2trg-sbootstrapping-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Behcet Sarikaya , Mohit Sethi , Dan Garcia-Carillo | ||
| Last updated | 2018-09-19 | ||
| Replaced by | draft-irtf-t2trg-security-setup-iot-devices, draft-irtf-t2trg-secure-bootstrapping | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sarikaya-t2trg-sbootstrapping-05
Network Working Group B. Sarikaya
Internet-Draft Denpel Informatique
Intended status: Informational M. Sethi
Expires: March 23, 2019 Ericsson
D. Garcia-Carillo
Odin Solutions, S.L
September 19, 2018
Secure IoT Bootstrapping: A Survey
draft-sarikaya-t2trg-sbootstrapping-05
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 23, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
Sarikaya, et al. Expires March 23, 2019 [Page 1]
Internet-Draft IoT Bootstrapping Analysis September 2018
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Classification of available mechanisms . . . . . . . . . . . 5
4. IoT Device Bootstrapping Methods . . . . . . . . . . . . . . 6
4.1. Managed Methods . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Bootstrapping in LPWAN . . . . . . . . . . . . . . . 10
4.2. Peer to Peer or Adhoc Methods . . . . . . . . . . . . . . 11
4.3. Leap-of-faith/Opportunistic Methods . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 to 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 from
other entities". Dick Hardt (an advocate of identity 2.0 concept) 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" [identity2.0]. In addition to human beings, other
Sarikaya, et al. Expires March 23, 2019 [Page 2]
Internet-Draft IoT Bootstrapping Analysis September 2018
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
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.
We 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
Sarikaya, et al. Expires March 23, 2019 [Page 3]
Internet-Draft IoT Bootstrapping Analysis September 2018
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
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.
Sarikaya, et al. Expires March 23, 2019 [Page 4]
Internet-Draft IoT Bootstrapping Analysis September 2018
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. Classification of available mechanisms
While some bootstrapping approaches are more user-intensive and
require extensive user-involvement by scanning QR codes or entering
passwords; others maybe more automated, such as those that rely on
mobile networks [I-D.sethi-gba-constrained]. We classify available
bootstrapping solutions into the following major categories:
o Managed methods: These bootstrapping methods rely on pre-
established trust relations and authentication credentials. They
typically utilize centralized servers for authentication, although
several such servers may join to form a distributed federation.
Example methods include Extensible Authentication Protocol (EAP)
[RFC3748], Generic Bootstrapping Architecture (GBA) [TS33220],
Kerberos [RFC4120], 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 nimble out-
of-band authentication for EAP. Based on how the OOB channel is
used, the P2P methods can be further classified into two sub
categories:
* Key derivation: Contextual information received over the OOB
channel is used for shared key derivation. For example,
[proximate] relies on the common radio environment of the
devices being paired to derive the shared secret which would
then be used for secure communication.
Sarikaya, et al. Expires March 23, 2019 [Page 5]
Internet-Draft IoT Bootstrapping Analysis September 2018
* Key confirmation: A Diffie-Hellman key exchange occurs over the
insecure network and the established key is used to
authenticate with the help of the OOB channel. For example,
Bluetooth simple pairing [SimplePairing] use the OOB channel to
ask the user to compare pins and approve the completed
exchange.
o Opportunistic and leap-of-faith methods: In these bootstrapping
methods, rather than verifying the initial authentication, the
continuity of the initial identity or connection is verified.
Some of these methods assume that the attacker is not present
during the initial setup. Example methods include Secure Neighbor
Discovery (SEND) [RFC3971] and Cryptographically Generated
Addresses (CGA) [RFC3972], Wifi Protected Setup (WPS) push button
[wps], and Secure Shell (SSH) [RFC4253]. 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.
Sarikaya, et al. Expires March 23, 2019 [Page 6]
Internet-Draft IoT Bootstrapping Analysis September 2018
4.1. Managed Methods
We first discuss some examples of managed bootstrapping methods.
EAP-TLS is a widely used EAP method for network access authentication
[RFC7250]. It allows mutual authentication and distributes the
keying material for secure subsequent communications. However it
only supports certificate-based mutual authentication, and therefore
a public key infrastructure is required. The ZigBee Alliance has
specified an IPv6 stack aimed at IEEE 802.15.4 [IEEE802.15.4] devices
mainly used in smart meters developed primarily for SEP 2.0 (Smart
Energy Profile) application layer traffic [SEP2.0]. The ZigBee IP
stack uses EAP-TLS for secure bootstrapping of devices.
EAP-PSK [RFC4764] is another EAP method. It realizes mutual
authentication and session key derivation using a Pre-Shared Key
(PSK). Normally four messages are exchanged in the authentication
process. Once the authentication is successful, EAP-PSK provides a
protected communication channel. Given the light-weight nature of
EAP-PSK, it can often be a good choice on constrained devices.
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 O'Flynn
[I-D.oflynn-core-bootstrapping]proposes the use of PANA for secure
bootstrapping of resource constrained devices. He demonstrates how a
6LowPAN Border Router (PANA Authentication Agent (PAA)) can
authenticate the identity of a joining constrained device (PANA
Client). Once the constrained device has been successfully
authenticated, the border router can also provide network and
security parameters to the joining device. Hernandez-Ramos et al.
[panaiot] also use EAP-TLS over PANA for secure bootstrapping of
smart objects. They also extend their bootstrapping scheme for
configuring additional keys that are used for secure group
communication.
When a device is not a direct neighbor of the authenticator, its
parent node MUST act as relay. Different EAP encapsulation protocols
Sarikaya, et al. Expires March 23, 2019 [Page 7]
Internet-Draft IoT Bootstrapping Analysis September 2018
have different mechanisms for the relay function, such as the PANA
Relay Element (PRE).
After a successful bootstrapping, the device runs neighbor discovery
protocol to get an IPv6 address assigned [RFC6775]. Data transfer
can be secured using DTLS or IPSec. Keys derived from EAP TLS are
used in either generating DTLS ciphering keys after a successful DTLS
handshake or IPSec ESP ciphering keys after a successful IKEv2
handshake.
Generic Bootstrapping Architecture (GBA) is another bootstrapping
method that falls in centralized category. GBA is part of the 3GPP
standard [TS33220] and is based on 3GPP Authentication and Key
Agreement (3GPP AKA). GBA is an application independent mechanism to
provide a client application (running on the User equipment (UE)) and
any application server with a shared session secret. This shared
session secret can subsequently be used to authenticate and protect
the communication between the client application and the application
server. GBA authentication is based on the permanent secret shared
between the UE's Universal Integrated Circuit Card (UICC), for
example SIM card, and the corresponding profile information stored
within the cellular network operator's Home Subscriber System (HSS)
database. [I-D.sethi-gba-constrained] describes a resource-
constrained adaptation of GBA to IoT applications.
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.
Sarikaya, et al. Expires March 23, 2019 [Page 8]
Internet-Draft IoT Bootstrapping Analysis September 2018
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] called
Bootstrapping Remote Secure Key Infrastructures (BRSKI). 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 document
highlights that the described solution is aimed in general at non-
constrained (i.e. class 2+ defined in [RFC7228]) devices operating in
a non-Challenged network. It claims to scale to thousands of devices
located in hostile environments, such as ISP provided CPE devices
which are drop-shipped to the end user.
[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 left 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 configured with trust
anchors in the form of X.509 certificates.
Sarikaya, et al. Expires March 23, 2019 [Page 9]
Internet-Draft IoT Bootstrapping Analysis September 2018
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.
4.1.1. Bootstrapping in LPWAN
Low Power Wide Area Network (LPWAN) encompasses a wide variety of
technologies, generally, with severe constraints in the link in
comparison with other typical IoT technologies such as Bluetooth or
IEEE 802.15.4. LPWAN typically presents a star topology with support
for thousands of devices per antenna.
Among the wide variety of technologies considered as LPWAN, we
highlight the ones mentioned in the LPWAN overview document of the
LPWAN working group [RFC8376]: LoRaWAN, Narrowband IoT (NB-IoT),
SIGFOX and Wi-SUN Alliance Field Area Network (FAN). Each technology
has different methods to provide security for the communications.
Bootstrapping is not directly tackled by all of them, having in some
cases proprietary solutions that are not publicly accessible and in
other cases key distribution is not even considered. Among the
previous LPWAN technologies, bootstrapping is discussed in LoRaWAN
and Wi-SUN Alliance Field Area Network (FAN) standards and use
managed bootstrapping methods.
LoRaWAN describes its own protocol to authenticate their nodes and
incorporate them into their network. This process is called the
Joining Procedure and it is based on pre-shared keys. The Joining
procedure entails one exchange where the node that intends to join
the network sends its identity along with other information to
authenticate against a network server which interacts with an entity
that knows the pre-shared key (called AppKey) and derives the
necessary key material for its nominal operation. There is some
variation regarding the pre-installed key material on version 1.0 and
1.1, but the Joining Process is very similar in both cases.
The Joining Process consists of an exchange of two messages, the
Join-request message (sent from the node) where information about the
identity of the node is provided and the Join-accept message
(received by the node). In this last message the node receives the
necessary information to derive the key material to secure the
communications. To this process there are adaptations to use AAA
infrastructures to enhance the joining process with AAA features such
as identity federation.
Sarikaya, et al. Expires March 23, 2019 [Page 10]
Internet-Draft IoT Bootstrapping Analysis September 2018
Wi-SUN Alliance Field Area Network (FAN) uses an EAP lower layer
(IEEE 802.1X) and the EAP-TLS method for network access
authentication and performs the 4-way handshake to establish a
security association similarly to a WPA2-Enterprise deployment.
The other technologies mentioned in [RFC8376] either do not
explicitly mention bootstrapping or is not considered as we
understand it in this document. NB-IoT for instance uses EAP-AKA to
authenticate the node before accessing the core network. Sigfox
assumes pre-shared key material directly to protect the
communications.
In short, LPWANs are still under development, and as it is identified
in [RFC8376], due to the characteristics of these technologies, they
are prime candidates to benefit from a standardized Authentication,
Accounting, and Authorization (AAA) infrastructure [RFC2904] as a way
of offering a scalable solution for some of the security and
management issues that are present in LPWANs.
4.2. Peer to Peer or Adhoc Methods
While managed methods are viable for many IoT devices, they may not
be suitable or desirable in all scenarios. All the managed methods
assume that some credentials are provisioned into the device. These
credentials may be in the device micro-controller or in a replaceable
smart card such as a SIM card. The methods also sometimes assume
that the manufacturer embeds these credentials during the device
manufacture on the factory floor. However, in many cases the
manufacturer may not have sufficient incentive to do this. In other
scenarios, it may be hard to completely trust and rely on the device
manufacturer to securely perform this task. Therefore, many times,
P2P or Adhoc methods of bootstrapping are used. We discuss a few
example next.
P2P or ad-hoc bootstrapping methods are used for establishing keys
and credential information for secure communication without any pre-
provisioned information. These bootstrapping mechanisms typically
rely on an out-of-band (OOB) channel in order to prevent man-in-the-
middle (MitM) attacks. P2P and ad-hoc methods have typically been
used for securely pairing personal computing devices such as smart
phones. [devicepairing] provides a survey of such secure device
pairing methods. Many original pairing schemes required the user to
enter the same key string or authentication code to both devices or
to compare and approve codes displayed by the devices. While these
methods can provide reasonable security, they require user
interaction that is relatively unnatural and often considered a
nuisance. Thus, there is ongoing research for more natural ways of
pairing devices. To reduce the amount of user-interaction required
Sarikaya, et al. Expires March 23, 2019 [Page 11]
Internet-Draft IoT Bootstrapping Analysis September 2018
in the pairing process, several proposals use contextual or location-
dependent information, or natural user input such as sound or
movement, for device pairing [proximate].
The local association created between two devices may later be used
for connecting/introducing one of the devices to a centralized
server. Such methods would however be classified as hybrids.
EAP-NOOB [I-D.aura-eap-noob] is an example of P2P and ad-hoc
bootstrapping method that establishes a security association between
an IoT device (node) and an online server (unlike pairing two devices
for local connections over WiFi or Bluetooth).
EAP-NOOB defines an EAP method where the authentication is based on a
user-assisted out-of-band (OOB) channel between the server and peer.
It is intended as a generic bootstrapping solution for Internet-of-
Things devices which have no pre-configured authentication
credentials and which are not yet registered on the authentication
server. This method claims to be more generic than most ad-hoc
bootstrapping solutions in that it supports many types of OOB
channels. The exact in-band messages and OOB message contents are
specified and not the OOB channel details. Also, EAP-NOOB supports
IoT devices with only output (e.g. display) or only input (e.g.
camera). It makes combined use of both secrecy and integrity of the
OOB channel for more robust security than the ad-hoc solutions.
Thread Group commissioning [threadcommissioning] introduces a two
phased process i.e. Petitioning and Joining. Entities involved are
Leader, Joiner, Commissioner, Joiner Router and Border Router.
Leader is the first device in Thread Network that must be
commissioned using out-of-band process and is used to inject correct
user generated Commissioning Credentials (can be changed later) into
Thread Network. Joiner is the node that intends to get authenticated
and authorized on Thread Network. Commissioner is either within the
Thread Network (Native) or connected with Thread Network via a WLAN
(External).
Under some topologies, Joiner Router and Border Router facilitate the
Joiner node to reach Native and External Commissioner, respectively.
Petitioning begins before Joining process and is used to grant sole
commissioning authority to a Commissioner. After an authorized
Commissioner is designated, eligible thread devices can join network.
Pair-wise key is shared between Commissioner and Joiner, network
parameters (Network Name, Security Policy, Steering Data,
Commissioning Data Timestamp, Commissioning Credential, Network
Master Key, Network Key Sequence, Network Mesh-Local ULA, Border
Router Locator, Commissioner Session ID, XPANID, PANID and Channel)
are sent out securely (using pair-wise key) by Joiner Router to
Sarikaya, et al. Expires March 23, 2019 [Page 12]
Internet-Draft IoT Bootstrapping Analysis September 2018
Joiner for letting Joiner to join the Thread Network. Entities
involved in Joining process depends on system topology i.e. location
of Commissioner and Joiner.
Thread networks only operates using IPv6. Thread devices can devise
GUAs (Global Unicast Addresses) [RFC4291]. Provision also exist via
Border Router, for Thread device to acquire individual global address
by means of DHCPv6 or using SLAAC (Stateless Address
Autoconfiguration) address derived with advertised network prefix.
DPP (Device Provisioning Protocol) [dpp] is a 3 message
authentication protocol currently being standardized by the WiFi
Alliance for devices that rely on IEEE 802.11 link-layer for
communication. The current DPP specification is only aimed at
networks that use WPA2-PSK (also known as WPA2-Home) for network
access authentication. Authentication Request, Response and Confirm
are 3 messages types based on [IEEE802.11] format. It provides
authentication and key establishment between an initiator and a
responder. Out of band mechanisms i.e. QR code, USB, NFC, Bluetooth
or proof of shared code/phrase/word is used to acquire bootstrapping
key [dpptech]. Afterwards, authentication and configuration exchange
takes place. Bootstrap trust in public key can be only for
responder's public key or for both parties in mutual authentication
manner. The role of initiator and responder as either enrollee or
configurator is decided during initial exchange of DPP Authentication
frames. Configurator's protocol key is always a one-time-used
(ephemeral) key but enrollee's protocol key always becomes its
network access provisioning key.
4.3. Leap-of-faith/Opportunistic Methods
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 (securing
the communication physically) to protect the environment of the
mother and duck nodes, though this may be inconvenient for the user.
Sarikaya, et al. Expires March 23, 2019 [Page 13]
Internet-Draft IoT Bootstrapping Analysis September 2018
[RFC7250] defines how raw public keys can be used to authenticate
constrained devices for mutual authentication using EAP-TLS or DTLS.
Raw public key TLS/DTLS extension simplifies client_certificate_type
and server_certificate_type to carry only SubjectPublicKeyInfo
structure with the raw public key instead of many other parameters
found in the certificates. The device and the authentication server
(AS) exchange client_hello and server_hello messages and send their
raw public keys. The device and AS validate the keys by comparing
the pre-configured values [I-D.sarikaya-6lo-bootstrapping-solution].
This bootstrapping method can be seen as a hybrid. This is because
it generally requires an out-of-band (OOB) step (P2P/Ad-hoc) where
the raw public keys [RFC7250] are provided to the authenticating
entities, after which the actual authentication occurs online
(managed). Raw public key approach when used with DTLS offers a
simple secure bootstrapping solution especially for smart energy and
building automation applications. It can be easily integrated with
the Constrained Application Protocol (CoAP).
5. Security Considerations
Bootstrapping protocols that do not rely on a pre-shared key for peer
authentication generally rely on an online or offline third-party
(e.g., an authentication server, a key distribution center in
Kerberos, a certification authority in PKI, a private key generator
in ID-based cryptography and so on) to prevent man-in-the-middle
attacks during bootstrapping. Depending on use cases, a resource-
constrained device may not always have access to an online third-
party for bootstrapping. Some bootstrapping methods therefore rely
on a configuration tool (such as a smartphone) that assists the
bootstrapping process by providing temporary reachability to the
online server.
Depending on use cases, a bootstrapping protocol may deal with
authorization separately from authentication in terms of timing and
signaling path. For example, two resource-constrained devices A and
B may perform mutual authentication using authentication credentials
provided by an offline third-party X whereas resource-constrained
device A obtains authorization for running a particular application
with resource-constrained device B from an online third-party Y
before or after the authentication. In some use cases,
authentication and authorization are tightly coupled, e.g.,
successful authentication also means successful authorization.
If authorization information communicated includes cryptographic
keys, care must be taken for provisioning the keys, e.g., guidelines
for AAA-based key management are described in [RFC4962]. Re-
bootstrapping of IoT devices may required and therefore there must be
adequate provisions for revocation and re-bootstrapping of
Sarikaya, et al. Expires March 23, 2019 [Page 14]
Internet-Draft IoT Bootstrapping Analysis September 2018
authentication/authorization credentials. Re-bootstrapping must be
as secure as the initial bootstrapping regardless of whether this re-
bootstrapping is done manually or automatically over the network.
If resource-constrained devices use a multicast group key for
authentications of peers that belong to the group, or for message
authentication/encryption, the group key must be securely distributed
to the current members of the group. Protocols designed for group
key management [RFC4046] may be used for group key distribution after
the initial bootstrapping. Alternatively, key wrap attributes for
securely encapsulating group key may be defined in network access
authentication protocols such as PANA. Those protocols use an end-
to-end, point-to-point communication channel with a pair-wise
security association between a key distribution center and each key
recipient. Further considerations may be needed for more efficient
group key management to support a large number of resource-
constrained devices.
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 and Rafa Marin for support.
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.
[dpp] Overview Document, "Wi-Fi Device Provisioning Protocol
(DPP)", Wi-Fi Alliance , 2016.
[dpptech] Technical Specification, "Technical Specification Draft
for DPP", Wi-Fi Alliance , 2016.
Sarikaya, et al. Expires March 23, 2019 [Page 15]
Internet-Draft IoT Bootstrapping Analysis September 2018
[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-03 (work in
progress), July 2018.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-16 (work in progress), June 2018.
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-18 (work in
progress), October 2016.
[I-D.ietf-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch
Provisioning for Networking Devices", draft-ietf-netconf-
zerotouch-25 (work in progress), September 2018.
[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]
Lopez, R. and D. Garcia, "EAP-based Authentication Service
for CoAP", draft-marin-ace-wg-coap-eap-06 (work in
progress), October 2017.
[I-D.oflynn-core-bootstrapping]
Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security
Bootstrapping of Resource-Constrained Devices", draft-
oflynn-core-bootstrapping-03 (work in progress), November
2010.
[I-D.sarikaya-6lo-bootstrapping-solution]
Sarikaya, B., "Secure Bootstrapping Solution for Resource-
Constrained Devices", draft-sarikaya-6lo-bootstrapping-
solution-00 (work in progress), June 2013.
Sarikaya, et al. Expires March 23, 2019 [Page 16]
Internet-Draft IoT Bootstrapping Analysis September 2018
[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.
[identity2.0]
Hardt, D., "Identity 2.0", O'Reilly Open Source Convention
(OSCON) , 2005.
[IEEE802.11]
IEEE Standard, "IEEE Std. 802.11-2016", December 2016,
<https://standards.ieee.org/findstds/
standard/802.11-2016.html>.
[IEEE802.15.4]
IEEE Standard, "IEEE Std. 802.15.4-2015", April 2016,
<http://standards.ieee.org/findstds/
standard/802.15.4-2015.html>.
[implicit]
Porambage, P., Schmitt, C., Kumar, P., Gurtov, A., and M.
Ylianttila, "Pauthkey: A pervasive authentication protocol
and key establishment scheme for wireless sensor networks
in distributed iot applications", International Journal of
Distributed Sensor Networks , Hindawi Publishing
Corporation , 2014.
[iotwork] European Commission FP7, "IoT@Work bootstrapping
architecture Deliverable D2.2", June 2011.
[kerberosiot]
Hardjono, "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.", Proceedings of MobiSys International
Conference , pp. 211-224, June 2011.
Sarikaya, et al. Expires March 23, 2019 [Page 17]
Internet-Draft IoT Bootstrapping Analysis September 2018
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000,
<https://www.rfc-editor.org/info/rfc2904>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005,
<https://www.rfc-editor.org/info/rfc4046>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005,
<https://www.rfc-editor.org/info/rfc4120>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4640] Patel, A., Ed. and G. Giaretta, Ed., "Problem Statement
for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
DOI 10.17487/RFC4640, September 2006,
<https://www.rfc-editor.org/info/rfc4640>.
Sarikaya, et al. Expires March 23, 2019 [Page 18]
Internet-Draft IoT Bootstrapping Analysis September 2018
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,
<https://www.rfc-editor.org/info/rfc4764>.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, DOI 10.17487/RFC4962, July 2007,
<https://www.rfc-editor.org/info/rfc4962>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
Sarikaya, et al. Expires March 23, 2019 [Page 19]
Internet-Draft IoT Bootstrapping Analysis September 2018
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/info/rfc7593>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
[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.
[threadcommissioning]
White Paper, "Thread Commissioning", Thread Group, Inc. ,
2015.
[TS33220] 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; Generic
Authentication Architecture (GAA); Generic Bootstrapping
Architecture (GBA) (Release 14)", December 2016,
<http://www.3gpp.org/DynaReport/33220.htm>.
[vendorcert]
IEEE std. 802.1ar-2009, "Standard for local and
metropolitan area networks - secure device identity",
December 2009.
[vermillard]
Vermillard, J., "Bootstrapping device security with
lightweight M2M", Appeared on blog at medium.com ,
February 2015.
[wps] IEEE Standard, "Wi-fi protected setup", Wi-Fi Alliance ,
2007.
Sarikaya, et al. Expires March 23, 2019 [Page 20]
Internet-Draft IoT Bootstrapping Analysis September 2018
Authors' Addresses
Behcet Sarikaya
Denpel Informatique
Email: sarikaya@ieee.org
Mohit Sethi
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: mohit@piuha.net
Dan Garcia-Carillo
Odin Solutions, S.L
Murcia 30820
Spain
Email: dgarcia@odins.es
Sarikaya, et al. Expires March 23, 2019 [Page 21]