< draft-irtf-t2trg-secure-bootstrapping-00.txt   draft-irtf-t2trg-secure-bootstrapping-01.txt >
Network Working Group M. Sethi Network Working Group M. Sethi
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational B. Sarikaya Intended status: Informational B. Sarikaya
Expires: October 9, 2021 Denpel Informatique Expires: 26 April 2022 Denpel Informatique
D. Garcia-Carrillo D. Garcia-Carrillo
University of Oviedo University of Oviedo
April 07, 2021 23 October 2021
Secure IoT Bootstrapping: A Survey Terminology and processes for initial security setup of IoT devices
draft-irtf-t2trg-secure-bootstrapping-00 draft-irtf-t2trg-secure-bootstrapping-01
Abstract Abstract
This draft provides an overview of the various terms that are used This document provides an overview of terms that are commonly used
when discussing bootstrapping of IoT devices. We document terms that when discussing the initial security setup of Internet of Things
have been used within the IETF as well as other standards bodies. We (IoT) devices. This document also presents a brief but illustrative
investigate if the terms refer to the same phenomena or have subtle survey of protocols and standards available for initial security
differences. We provide recommendations on the applicability of setup of IoT devices. For each protocol, we identify the terminology
terms in different contexts. Finally, this document presents a used, the entities involved, the initial assumptions, the processes
survey of secure bootstrapping mechanisms available for smart objects necessary for completetion, and the knowledge imparted to the IoT
that are part of an Internet of Things (IoT) network. The survey devices after the setup is complete.
does not prescribe any one 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 IoT devices.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 9, 2021. This Internet-Draft will expire on 26 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect Please review these documents carefully, as they describe your rights
to this document. Code Components extracted from this document must and restrictions with respect to this document. Code Components
include Simplified BSD License text as described in Section 4.e of extracted from this document must include Simplified BSD License text
the Trust Legal Provisions and are provided without warranty as as described in Section 4.e of the Trust Legal Provisions and are
described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Standards and Protocols . . . . . . . . . . . . . . . . . . . 4
3. Usage of bootstrapping terminology in standards . . . . . . . 4 2.1. Device Provisioning Protocol (DPP) . . . . . . . . . . . 4
3.1. Device Provisioning Protocol (DPP) . . . . . . . . . . . 4 2.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) . . . 5
3.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) . . . 5 2.3. Open Connectivity Foundation (OCF) . . . . . . . . . . . 6
3.3. Open Connectivity Foundation (OCF) . . . . . . . . . . . 6 2.4. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Fast IDentity Online (FIDO) alliance . . . . . . . . . . 9
3.5. Fast IDentity Online (FIDO) alliance . . . . . . . . . . 7 2.6. Fast IDentity Online (FIDO) alliance . . . . . . . . . . 9
3.6. Internet Engineering Task Force (IETF) . . . . . . . . . 8 2.7. Enrollment over Secure Transport (EST) . . . . . . . . . 10
3.6.1. Enrollment over Secure Transport (EST) . . . . . . . 8 2.8. Bootstrapping Remote Secure Key Infrastructures
3.6.2. Bootstrapping Remote Secure Key Infrastructures (BRSKI) . . . . . . . . . . . . . . . . . . . . . . . . 10
(BRSKI) . . . . . . . . . . . . . . . . . . . . . . . 8 2.9. Secure Zero Touch Provisioning . . . . . . . . . . . . . 11
3.6.3. Secure Zero Touch Provisioning . . . . . . . . . . . 9 2.10. Nimble out-of-band authentication for EAP (EAP-NOOB) . . 12
3.6.4. Nimble out-of-band authentication for EAP (EAP-NOOB) 9 2.11. LPWAN . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.12. Thread . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 10 3. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Classification of available mechanisms . . . . . . . . . . . 10 4. Comparison of terminology . . . . . . . . . . . . . . . . . . 15
7. IoT Device Bootstrapping Methods . . . . . . . . . . . . . . 11 5. Comparison of players . . . . . . . . . . . . . . . . . . . . 15
7.1. Managed Methods . . . . . . . . . . . . . . . . . . . . . 12 6. Comparison of initial beliefs . . . . . . . . . . . . . . . . 15
7.1.1. Bootstrapping in LPWAN . . . . . . . . . . . . . . . 13 7. Comparison of processes . . . . . . . . . . . . . . . . . . . 15
7.2. Peer-to-Peer or Ad-hoc Methods . . . . . . . . . . . . . 14 8. Comparison of knowledge imparted to the device . . . . . . . 15
7.3. Leap-of-faith/Opportunistic Methods . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.4. Hybrid Methods . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. Informative References . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
11. Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
We informally define bootstrapping as "any process that takes place Initial security setup for a device refers to any process that takes
before a device can become operational". While bootstrapping is place before a device can become operational. The phrase "initial
necessary for all computing devices, until recently, most of our security setup" intentionally includes the term "security" as setup
devices typically had sufficient computing power and user interface of devices without adequate security or with insecure processes is no
(UI) for ensuring somewhat smooth operation. For example, a typical longer acceptable. The initial security setup process, among other
laptop device required the user to setup a username/password as well things, involves network discovery and selection, access
as enter network settings for Internet connectivity. Following these authentication, configuration of necessary credentials and
steps ensured that the laptop was fully operational. parameters.
The problem of bootstrapping is however exacerbated for Internet of Initial security setup for IoT devices is challenging because the
Things (IoT) networks. The size of an IoT network varies from a size of an IoT network varies from a couple of devices to tens of
couple of devices to tens of thousands, depending on the application. thousands, depending on the application. Moreover, devices in IoT
Smart objects/things/devices in IoT networks are produced by a networks are produced by a variety of vendors and are typically
variety of vendors and are typically heterogeneous in terms of the heterogeneous in terms of the constraints on their power supply,
constraints on their power supply, communication capability, communication capability, computation capacity, and user interfaces
computation capacity, and user interfaces available. This problem of available. This challenge of initial security setup in IoT was
bootstrapping in IoT was identified by Sethi et al. [Sethi14] while identified by Sethi et al. [Sethi14] while developing a solution for
developing a bootstrapping solution for smart displays. Although smart displays.
this document focuses on bootstrapping terminology and methods for
IoT devices, we do not exclude bootstrapping related terminology used
in other contexts.
Bootstrapping devices typically also involves providing them with Initial security setup of devices typically also involves providing
some sort of network connectivity. Indeed, the functionality of a them with some sort of network connectivity. The functionality of a
disconnected device is rather limited. Bootstrapping devices often disconnected device is rather limited. Initial security setup of
assumes that some network has been setup a-priori. Setting up and devices often assumes that some network has been setup a-priori.
maintaining a network itself is challenging. For example, users may Setting up and maintaining a network itself is challenging. For
need to configure the network name (called as Service Set Identifier example, users may need to configure the network name (called as
(SSID) in Wi-Fi networks) and passpharse before new devices can be Service Set Identifier (SSID) in Wi-Fi networks) and passpharse
bootstrapped. Specifications such as the Wi-Fi Alliance Simple before new devices can be setup. Specifications such as the Wi-Fi
Configuration [simpleconn] help users setup networks. However, this Alliance Simple Configuration [simpleconn] help users setup networks.
document is only focused on terminology and processes associated with However, this document is only focused on terminology and processes
bootstrapping devices and excludes any discussion on setting up associated with initial security setup of devices and excludes any
networks before devices can be bootstrapped. discussion on setting up networks.
In addition to our informal definition, it is helpful to look at There are several terms that are used in the context of initial
other definitions of bootstrapping. The IoT@Work project defines security setup of devices:
bootstrapping in the context of 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]. Vermillard
[vermillard], on the other hand, describes bootstrapping as the
procedure by which an IoT device gets the URLs and secret keys for
reaching the necessary servers. Vermillard notes that the same
process is useful for re-keying, upgrading the security schemes, and
for redirecting the IoT devices to new servers.
There are several terms that have often been used in the context of * Bootstrapping
bootstrapping:
o Bootstrapping * Provisioning
o Provisioning * Onboarding
o Onboarding * Enrollment
o Enrollment * Commissioning
o Commissioning * Initialization
o Initialization * Configuration
o Configuration * Registration
o Registration * Discovery
o Discovery In addition to using a variety of different terms, initial security
setup mechanisms can rely on a number of entities. For example, a
companion smartphone device maybe necessary for some initial security
setup mechanisms. Moreover, security setup procedures have diverese
initial assumptions about the device being setup. As an example, an
initial security setup mechanism may assume that the device is
provisioned with a pre-shared key and a list of trusted network
identifiers. Finally, initial security setup mechanisms impart
different information to the device after completion. For example,
some mechanisms may only provide a key for use with an authorization
server, while others may configure elaborate access control lists
directly.
We attempt to find out whether all these terms refer to the same The next section provides an overview of some standards and protocols
phenomena. We begin by looking at how these terms have been used in for initial security setup of IoT devices. For each mechanism, the
various standards and standardization bodies in Section 3. We then following are explicitly identified:
summarize our understanding in Section 4, and provide our
recommendations on their usage in Section 5. Section 6 provides a
taxonomy of bootstrapping methods and Section 7 categorizes methods
according to the taxonomy.
2. Terminology * Terminology used
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", * Entities or "players" involved
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14
[RFC2119][RFC8174].
3. Usage of bootstrapping terminology in standards * Initial assumptions about the device
To better understand bootstrapping related terminology, let us first * Processes necessary for completetion
look at the terms used by some existing specifications:
3.1. Device Provisioning Protocol (DPP) * Knowledge imparted to the device after completion
2. Standards and Protocols
2.1. Device Provisioning Protocol (DPP)
The Wi-Fi Alliance Device provisioning protocol (DPP) [dpp] describes The Wi-Fi Alliance Device provisioning protocol (DPP) [dpp] describes
itself as a standardized protocol for providing user friendly Wi-Fi itself as a standardized protocol for providing user friendly Wi-Fi
setup while maintaining or increasing the security. DPP relies on a setup while maintaining or increasing the security. DPP relies on a
configurator, e.g. a smartphone application, for setting up all other configurator, e.g. a smartphone application, for setting up all other
devices, called enrollees, in the network. DPP has the following devices, called enrollees, in the network. DPP has the following
three phases/sub-protocols: three phases/sub-protocols:
o Bootstrapping: The configurator obtains bootstrapping information * Bootstrapping: The configurator obtains bootstrapping information
from the enrollee using an out-of-band channel such as scanning a from the enrollee using an out-of-band channel such as scanning a
QR code or tapping NFC. The bootstrapping information includes QR code or tapping NFC. The bootstrapping information includes
the public-key of the device and metadata such as the radio the public-key of the device and metadata such as the radio
channel on which the device is listening. channel on which the device is listening.
o Authentication: In DPP, either the configurator or the enrollee * Authentication: In DPP, either the configurator or the enrollee
can initiate the authentication protocol. The side initiating the can initiate the authentication protocol. The side initiating the
authentication protocol is called as the initiator while the other authentication protocol is called as the initiator while the other
side is called the responder. The authentication sub-protocol side is called the responder. The authentication sub-protocol
provides authentication of the responder to an initiator. It can provides authentication of the responder to an initiator. It can
optionally authenticate the initiator to the responder (only if optionally authenticate the initiator to the responder (only if
the bootstrapping information was exchange out-of-band in both the bootstrapping information was exchange out-of-band in both
directions). directions).
o Configuration: Using the key established from the authentication * Configuration: Using the key established from the authentication
protocol, the enrollee asks the configurator for network protocol, the enrollee asks the configurator for network
information such as the SSID and passphrase of the access point. information such as the SSID and passphrase of the access point.
3.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) DPP has the following characteristics:
* Terms: Bootstrapping, configuration, discovery, enrollment,
provisioning.
* Players: Authenticator, Bootstrap Server, Client, Configurator,
Device, Initiator, Manager, Manufacturer, Owner, Peer, Peer,
Persona, Responder, Server, User
* Initial beliefs assumed in the device:
* Processes:
* Beliefs imparted to the device after protocol execution:
2.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M)
The OMA LwM2M specification [oma] defines an architecture where a new The OMA LwM2M specification [oma] defines an architecture where a new
device (LwM2M client) contacts a Bootstrap-server which is device (LwM2M client) contacts a Bootstrap-server which is
responsible for "provisioning" essential information such as responsible for provisioning essential information such as
credentials. After receiving this essential information, the LwM2M credentials. After receiving this essential information, the LwM2M
client device "registers" itself with one or more LwM2M Servers which client device registers itself with one or more LwM2M Servers which
will manage the device during its lifecycle. The current standard will manage the device during its lifecycle. The current standard
defines the following four bootstrapping modes: defines the following four bootstrapping modes:
o Factory Bootstrap: An IoT device in this case is configured with * Factory Bootstrap: An IoT device in this case is configured with
all the necessary bootstrap information during manufacturing and all the necessary bootstrap information during manufacturing and
prior to its deployment. prior to its deployment.
o Bootstrap from Smartcard: An IoT device retrieves and processes * Bootstrap from Smartcard: An IoT device retrieves and processes
all the necessary bootstrap data from a Smartcard. all the necessary bootstrap data from a Smartcard.
o Client Initiated Bootstrap: This mode provides a mechanism for an * Client Initiated Bootstrap: This mode provides a mechanism for an
IoT client device to retrieve the bootstrap information from a IoT client device to retrieve the bootstrap information from a
Bootstrap Server. This requires the client device to have an Bootstrap Server. This requires the client device to have an
account at the Bootstrap Server and credentials to obtain the account at the Bootstrap Server and credentials to obtain the
necessary information securely. necessary information securely.
o Server Initiated Bootstrap: In this bootstrapping mode, the * Server Initiated Bootstrap: In this bootstrapping mode, the
bootstrapping server configures all the bootstrap information on bootstrapping server configures all the bootstrap information on
the IoT device without receiving a request from the client. This the IoT device without receiving a request from the client. This
means that the bootstrap server needs to know if a client IoT means that the bootstrap server needs to know if a client IoT
Device is ready for bootstrapping before it can be configured. Device is ready for bootstrapping before it can be configured.
For example, a network may inform the bootstrap server of a new For example, a network may inform the bootstrap server of a new
connecting IoT client device. connecting IoT client device.
3.3. Open Connectivity Foundation (OCF) OMA has the following characteristics:
* Terms: Bootstrapping, provisioning, intialization, configuration,
registration.
* Players: Bootstrap Server, Client, Device, Manufacturer, Owner,
Server, User
* Initial beliefs assumed in the device:
* Processes:
* Beliefs imparted to the device after protocol execution:
2.3. Open Connectivity Foundation (OCF)
The Open Connectivity Foundation (OCF) [ocf] defines the process The Open Connectivity Foundation (OCF) [ocf] defines the process
before a device is operational as onboarding. The first step of this before a device is operational as onboarding. The first step of this
onboarding process is "configuring" the ownership, i.e., establishing onboarding process is configuring the ownership, i.e., establishing a
a legitimate user that owns the device. For this, the user is legitimate user that owns the device. For this, the user is supposed
supposed to use an Onboarding tool (OBT) and an Owner Transfer to use an Onboarding tool (OBT) and an Owner Transfer Method (OTM).
Methods (OTM).
The OBT is described as a logical entity that may be implemented on a The OBT is described as a logical entity that may be implemented on a
single or multiple entities such as a home gateway, a device single or multiple entities such as a home gateway, a device
management tool, etc. OCF lists several optional OTMs. At the end management tool, etc. OCF lists several optional OTMs. At the end
of the execution of an OTM, the onboarding tool must have of the execution of an OTM, the onboarding tool must have provisioned
"provisioned" an Owner Credential onto the device. The following an Owner Credential onto the device. The following owner transfer
owner transfer methods are specified: methods are specified:
o Just works: Performs an un-authenticated Diffie-Hellman key * Just works: Performs an un-authenticated Diffie-Hellman key
exchange over Datagram Transport Layer Security (DTLS). The key exchange over Datagram Transport Layer Security (DTLS). The key
exchange results in a symmetric session key which is later used exchange results in a symmetric session key which is later used
for provisioning. Naturally, this mode is vulnerable to Man-in- for provisioning. Naturally, this mode is vulnerable to on-path
The-Middle (MiTM) attackers. attackers.
o Random PIN: The device generates a PIN code that is entered into * Random PIN: The device generates a PIN code that is entered into
the onboarding tool by the user. This pin code is used together the onboarding tool by the user. This pin code is used together
with TLS-PSK ciphersuites for establishing a symmetric session with TLS-PSK ciphersuites for establishing a symmetric session
key. OCF recommends PIN codes to have an entropy of 40 bits. key. OCF recommends PIN codes to have an entropy of 40 bits.
o Manufacturer certificate: An onboarding tool authenticates the * Manufacturer certificate: An onboarding tool authenticates the
device by verifying a manufacturer installed certificate. device by verifying a manufacturer installed certificate.
Similarly, the device may authenticate the onboarding tool by Similarly, the device may authenticate the onboarding tool by
verifying its signature. verifying its signature.
o Vendor specific: Vendors implement their own transfer method that * Vendor specific: Vendors implement their own transfer method that
accommodates any specific device constraints. accommodates any specific device constraints.
Once the onboarding tool and the new device have authenticated and Once the onboarding tool and the new device have authenticated and
established secure communication, the onboarding tool established secure communication, the onboarding tool provisions/
"provisions"/"configures" the device with Owner credentials. Owner configures the device with Owner credentials. Owner credentials may
credentials may consist of certificates, shared keys, or Kerberos consist of certificates, shared keys, or Kerberos tickets for
tickets for example. example.
The OBT additionally configures/provisions information about the The OBT additionally configures/provisions information about the
Access Management Service (AMS), the Credential Management Service Access Management Service (AMS), the Credential Management Service
(CMS), and the credentials for interacting with them. The AMS is (CMS), and the credentials for interacting with them. The AMS is
responsible for provisioning access control entries, while the CMS responsible for provisioning access control entries, while the CMS
provisions security credentials necessary for device operation. provisions security credentials necessary for device operation.
3.4. Bluetooth OCF has the following characteristics:
Bluetooth mesh provisioning. Beacons for discovery. Public-key * Terms: Configuration, discovery, enrollment, onboarding,
exchange followed by authentication. Finally provisioning of the provisioning, registration,
network key and unicast address. To be expanded.
3.5. Fast IDentity Online (FIDO) alliance * Players: Client, Device, Manager, Manufacturer, Owner, Peer,
Responder, Server, User
* Initial beliefs assumed in the device:
* Processes:
* Beliefs imparted to the device after protocol execution:
2.4. Bluetooth
Bluetooth mesh specifies a provisioning protocol. The goal of the
provisioning phase is to securely incorporate a new Bluetooth mesh
node, by completing two critical tasks. First, to authenticate the
unprovisioned device and second, to create a secure link with said
device to share information.
The provisioning process is divided into five distinct stages
summarize next:
* Beaconing for discover: The new unprovisioned device is discovered
by the provisioner
* Negotiation: The unprovisioned device indicates to the provisioner
a set of capabilities such as the security algorithms supported,
the availability of its public key using an Out-of-Band (OOB)
channel and the input/output interfaces supported
* Public-key exchange: The authentication method is selected by the
provisioner and both devices exchange Elliptic-curve Diffie-
Hellman (ECDH) public keys. These keys may be static or
ephemeral. Their exchange can be done in two ways, either via
Out-of-Band or directly through a Bluetooth link. Each device
then generates a symmetric key, named ECDHSecret, by combining its
own private key and the public key of the peer device. The
EDCHSecret is used to protect communication between the two
devices.
* Authentication: During this phase, the ECDH key exchange is
authenticated. The authentication method can be Output OOB, Input
OOB, static OOB, or No OOB. With Output OOB, the unprovisioned
device chooses a random number and outputs that number in manner
consistent with its capabilities. The provisioner then inputs
this number. Then, a check confirmation value operation is
performed. This involves a cryptographic exchange regarding (in
this case) the random number to complete the authentication. With
Input OOB, the roles are reversed, being the provisioner the
entity that generates the random number. When neither of the
previous authentication procedures are feasible, both the
provisioner and unprovisioned device generate a random number and
require the user supervising the setup to verify that values on
the device and provisioner are the same.
* Distribution of provisioning data: At this point, the provisioning
process can be protected. This involves the distribution of data
such as a Network key, to secure the communications at network
layer and a unicast address among other information.
Bluetooth mesh has the following characteristics:
* Terms: Configuration, discovery, provisioning.
* Players: Client, Device, Manager, Manufacturer, Peer, Server, User
* Initial beliefs assumed in the device:
* Processes:
* Beliefs imparted to the device after protocol execution:
2.5. Fast IDentity Online (FIDO) alliance
2.6. Fast IDentity Online (FIDO) alliance
The Fast IDentity Online Alliance (FIDO) is currently specifying an The Fast IDentity Online Alliance (FIDO) is currently specifying an
automatic onboarding protocol for IoT devices [fidospec]. The goal automatic onboarding protocol for IoT devices [fidospec]. The goal
of this protocol is to provide a new IoT device with information for of this protocol is to provide a new IoT device with information for
interacting securely with an online IoT platform. This protocol interacting securely with an online IoT platform. This protocol
allows owners to choose the IoT platform for their devices at a late allows owners to choose the IoT platform for their devices at a late
stage in the device lifecyle. The draft specification refers to this stage in the device lifecyle. The draft specification refers to this
feature as "late binding". feature as "late binding".
The FIDO IoT protocol itself is composed of one Device Initialization The FIDO IoT protocol itself is composed of one Device Initialization
skipping to change at page 8, line 7 skipping to change at page 9, line 47
When a device is unboxed and powered on by the new owner, the device When a device is unboxed and powered on by the new owner, the device
discovers a network-local or an Internet-based rendezvous server. discovers a network-local or an Internet-based rendezvous server.
Protocols (TO0, TO1, and TO2) between the device, the rendezvous Protocols (TO0, TO1, and TO2) between the device, the rendezvous
server, and the new owner (as the owner onboarding service) ensure server, and the new owner (as the owner onboarding service) ensure
that the device and the new owner are able to authenticate each that the device and the new owner are able to authenticate each
other. Thereafter, the new owner establishes cryptographic control other. Thereafter, the new owner establishes cryptographic control
of the device and provides it with credentials of the IoT platform of the device and provides it with credentials of the IoT platform
which the device should used. which the device should used.
3.6. Internet Engineering Task Force (IETF) FIDO has the following characteristics:
In this section, we will look at some IETF standards and draft * Terms: Provisioning, onboarding, commissioning, initialization.
specifications related to IoT bootstrapping.
3.6.1. Enrollment over Secure Transport (EST) * Players: Device, Manager, Manufacturer, Owner, Rendezvous Server,
Server, User
* Initial beliefs assumed in the device:
* Processes:
* Beliefs imparted to the device after protocol execution:
2.7. Enrollment over Secure Transport (EST)
Enrollment over Secure Transport (EST) [RFC7030] defines a profile of Enrollment over Secure Transport (EST) [RFC7030] defines a profile of
Certificate Management over CMS (CMC) [RFC5272]. EST relies on Certificate Management over CMS (CMC) [RFC5272]. EST relies on
Hypertext Transfer Protocol (HTTP) and Transport Layer Security (TLS) Hypertext Transfer Protocol (HTTP) and Transport Layer Security (TLS)
for exchanging CMC messages and allows client devices to obtain for exchanging CMC messages and allows client devices to obtain
client certificates and associated Certification Authority (CA) client certificates and associated Certification Authority (CA)
certificates. A companion specification for using EST over secure certificates. A companion specification for using EST over secure
CoAP has also been standardized [I-D.ietf-ace-coap-est]. EST assumes CoAP has also been standardized [I-D.ietf-ace-coap-est]. EST assumes
that some initial information is already distributed so that EST that some initial information is already distributed so that EST
client and servers can perform mutual authentication before client and servers can perform mutual authentication before
continuing with protocol. [RFC7030] further defines "Bootstrap continuing with protocol. [RFC7030] further defines "Bootstrap
Distribution of CA Certificates" which allows minimally configured Distribution of CA Certificates" which allows minimally configured
EST clients to obtain initial trust anchors. It relies on human EST clients to obtain initial trust anchors. It relies on human
users to verify information such as the CA certificate "fingerprint" users to verify information such as the CA certificate "fingerprint"
received over the unauthenticated TLS connection setup. After received over the unauthenticated TLS connection setup. After
successful completion of this bootstrapping step, clients can proceed successful completion of this bootstrapping step, clients can proceed
to the enrollment step during which they obtain client certificates to the enrollment step during which they obtain client certificates
and associated CA certificates. and associated CA certificates.
3.6.2. Bootstrapping Remote Secure Key Infrastructures (BRSKI) EST has the following characteristics:
* Terms: Bootstrapping, enrollment, initialization, configuration.
* Players: Administrator, Client, Device, Manufacturer, Owner, Peer,
Peer, Responder, Server, User
* Initial beliefs assumed in the device:
* Processes:
* Beliefs imparted to the device after protocol execution:
2.8. Bootstrapping Remote Secure Key Infrastructures (BRSKI)
The ANIMA working group is working on a bootstrapping solution for The ANIMA working group is working on a bootstrapping solution for
devices that relies on 802.1AR vendor certificates called devices that relies on 802.1AR vendor certificates called
Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI) [RFC8995].
[I-D.ietf-anima-bootstrapping-keyinfra]. In addition to vendor In addition to vendor installed IEEE 802.1AR certificates, a vendor
installed IEEE 802.1AR certificates, a vendor based service on the based service on the Internet is required. Before being
Internet is required. Before being authenticated, a new device only authenticated, a new device only needs link-local connectivity, and
needs link-local connectivity, and does not require a routable does not require a routable address. When a vendor provides an
address. When a vendor provides an Internet based service, devices Internet based service, devices can be forced to join only specific
can be forced to join only specific domains. The document highlights domains. The document highlights that the described solution is
that the described solution is aimed in general at non-constrained aimed in general at non-constrained (i.e. class 2+ defined in
(i.e. class 2+ defined in [RFC7228]) devices operating in a non- [RFC7228]) devices operating in a non-challenged network. It claims
challenged network. It claims to scale to thousands of devices to scale to thousands of devices located in hostile environments,
located in hostile environments, such as ISP provided CPE devices such as ISP provided CPE devices which are drop-shipped to the end
which are drop-shipped to the end user. user.
3.6.3. Secure Zero Touch Provisioning BRSKI has the following characteristics:
* Terms: Bootstrapping, provisioning, enrollment, onboarding.
* Players: Administrator, Client, Cloud Registrar, Configurator,
Device, Domain Registrar, Initiator, Join Proxy, JRC,
Manufacturer, Owner, Peer, Pledge, Server, User
* Initial beliefs assumed in the device:
* Processes:
* Beliefs imparted to the device after protocol execution:
2.9. Secure Zero Touch Provisioning
[RFC8572] defines a bootstrapping strategy for enabling devices to [RFC8572] defines a bootstrapping strategy for enabling devices to
securely obtain all the configuration information with no installer securely obtain all the configuration information with no installer
input, beyond the actual physical placement and connection of cables. input, beyond the actual physical placement and connection of cables.
Their goal is to enable a secure NETCONF [RFC6241] or RESTCONF Their goal is to enable a secure NETCONF [RFC6241] or RESTCONF
[RFC8040] connection to the deployment specific network management [RFC8040] connection to the deployment specific network management
system (NMS). This bootstrapping method requires the devices to be system (NMS). This bootstrapping method requires the devices to be
configured with trust anchors in the form of X.509 certificates. configured with trust anchors in the form of X.509 certificates.
[RFC8572] is similar to BRSKI based on [RFC8366]. [RFC8572] is similar to BRSKI based on [RFC8366].
3.6.4. Nimble out-of-band authentication for EAP (EAP-NOOB) SZTP has the following characteristics:
* Terms: Bootstrapping, provisioning, onboarding, enrollment,
configuration, discovery.
* Players: Administrator, Bootstrap Server, Client, Device,
Manufacturer, Onboarding Server, Owner, Redirect Server,
Responder, Server, User
* Initial beliefs assumed in the device:
* Processes:
* Beliefs imparted to the device after protocol execution:
2.10. Nimble out-of-band authentication for EAP (EAP-NOOB)
EAP-NOOB [I-D.ietf-emu-eap-noob] defines an EAP method where the EAP-NOOB [I-D.ietf-emu-eap-noob] defines an EAP method where the
authentication is based on a user-assisted out-of-band (OOB) channel authentication is based on a user-assisted out-of-band (OOB) channel
between the server and peer. It is intended as a generic between the server and peer. It is intended as a generic
bootstrapping solution for IoT devices which have no pre-configured bootstrapping solution for IoT devices which have no pre-configured
authentication credentials and which are not yet registered on the authentication credentials and which are not yet registered on the
authentication server. This method claims to be more generic than authentication server. This method claims to be more generic than
most ad-hoc bootstrapping solutions in that it supports many types of most ad-hoc bootstrapping solutions in that it supports many types of
OOB channels. The exact in-band messages and OOB message contents OOB channels. The exact in-band messages and OOB message contents
are specified and not the OOB channel details. EAP-NOOB also are specified and not the OOB channel details. EAP-NOOB also
supports IoT devices with only output (e.g. display) or only input supports IoT devices with only output (e.g. display) or only input
(e.g. camera). It makes combined use of both secrecy and integrity (e.g. camera). It makes combined use of both secrecy and integrity
of the OOB channel for more robust security than the ad-hoc of the OOB channel for more robust security than the ad-hoc
solutions. solutions.
4. Comparison EAP-NOOB has the following characteristics:
There are several stages before a device becomes fully operational.
This typically involves establishing some initial trust after which
credentials and other parameters are configured. For DPP,
bootstrapping is the first step before authentication and
provisioning of credentials can occur. For EST, bootstrapping
happens as the first step when the client devices have no
certificates available for starting enrollment. Provisioning/
configuring are terms used for providing additional information to
devices before they are fully operational. For example, credentials
are provisioned onto the device. But before credential provisioning,
a device is bootstrapped and authenticated. Some protocols may only
deal with parts of the process. For example, TLS maybe used for
authentication after bootstrapping. A separate device management
protocol then may run over this TLS tunnel for provisioning
operational information and credentials.
5. Recommendations
o It is recommended that the IETF use the term "bootstrapping" for
the initial (authentication) step that a device must perform.
Bootstrapping will likely happen before the device has obtained
full network connectivity.
o It is recommended to use the term "provisioning"/"configuring" for
the process of providing necessary information to a device to
become operational after initial authentication is complete. As
is evident from above, provisioning and configuring may include
bootstrapping and authentication as a sub protocol.
o IETF specifications should aim to avoid mixing terminology or
adding new terminology for better consistency.
6. Classification of available mechanisms
Given the large number of bootstrapping protocols and related
specifications, it can be helpful to classify them. We categorize
the available bootstrapping solutions into the following major
classes:
o Managed methods: These 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], Bootstrapping Remote Secure Key
Infrastructures (BRSKI) and vendor certificates [vendorcert]. EAP
Transport Layer Security EAP-TLS [I-D.ietf-emu-eap-tls13] for
instance assumes that both the client and the server have
certificates to authenticate each other. Based on this
authentication, the server authorizes the client for network
access. The Eduroam federation [RFC7593] uses a network of such
servers to support roaming clients.
o Opportunistic and leap-of-faith methods: In these 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].
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. Based on how the OOB channel is
used, the P2P methods can be further classified into two sub
categories:
* Key derivation: Contextual information received over the OOB
channel is used for shared key derivation. For example,
[proximate] relies on the common radio environment of the
devices being paired to derive the shared secret which would
then be used for secure communication.
* Key confirmation: A Diffie-Hellman key exchange occurs over the
insecure network and the established key is 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 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 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.
7. IoT Device Bootstrapping Methods
In this section we look at additional bootstrapping protocols for IoT
devices which are not covered in Section 3. Protocols already
covered in Section 3 however are mentioned in their respective
classes. This list is non-exhaustive.
7.1. Managed Methods
EAP-TLS is a widely used EAP method for network access authentication
[I-D.ietf-emu-eap-tls13]. It requires certificate-based mutual
authentication and a public key infrastructure. The ZigBee Alliance
has specified an IPv6 stack for IEEE 802.15.4 [IEEE802.15.4] devices
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 that realizes mutual
authentication and session key derivation using a Pre-Shared Key
(PSK). Given the light-weight nature of EAP-PSK, it can be suitable
for resource-constrained devices. However, secure distribution of a
large number of PSKs can be challenging.
CoAP-EAP [I-D.marin-ace-wg-coap-eap] defines a bootstrapping service
for IoT. The authors propose transporting EAP over CoAP [RFC7252]
for the constrained link, and communication with AAA infrastructures
in the non-constrained link. While the draft discusses the use of
EAP-PSK, the authors claim that they are specifying a new EAP lower
layer and any EAP method which results in generation 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 * Terms: Bootstrapping, configuration, registration.
secure bootstrapping of smart objects. They extend their
bootstrapping scheme for configuring additional keys that are used
for secure group communication.
Generic Bootstrapping Architecture (GBA) is another bootstrapping * Players: Administrator, Authenticator, Client, Device,
method that falls in centralized category. GBA is part of the 3GPP Manufacturer, Owner, Peer, Server, User
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 for IoT.
The four bootstrapping modes specified by the Open Mobile Alliance * Initial beliefs assumed in the device:
(OMA) Light-weight M2M (LwM2M) standard require some sort of pre-
provisioned credentials on the device. All the four modes are
examples of managed bootstrapping methods.
The Kerberos protocol [RFC4120] is a network authentication protocol * Processes:
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 Kerberos for IoT devices [kerberosiot].
It is also important to mention some of the work done on implicit * Beliefs imparted to the device after protocol execution:
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.
7.1.1. Bootstrapping in LPWAN 2.11. LPWAN
Low Power Wide Area Network (LPWAN) encompasses a wide variety of Low Power Wide Area Network (LPWAN) encompasses a wide variety of
technologies whose link-layer characteristics are severely technologies whose link-layer characteristics are severely
constrained in comparison to other typical IoT link-layer constrained in comparison to other typical IoT link-layer
technologies such as Bluetooth or IEEE 802.15.4. While some LPWAN technologies such as Bluetooth or IEEE 802.15.4. While some LPWAN
technologies rely on proprietary bootstrapping solutions which are technologies rely on proprietary bootstrapping solutions which are
not publicly accessible, others simply ignore the challenge of not publicly accessible, others simply ignore the challenge of
bootstrapping and key distribution. In this section, we discuss the bootstrapping and key distribution. In this section, we discuss the
bootstrapping methods used by LPWAN technologies covered in bootstrapping methods used by LPWAN technologies covered in
[RFC8376]. [RFC8376].
o LoRaWAN [LoRaWAN] describes its own protocol to authenticate nodes * LoRaWAN [LoRaWAN] describes its own protocol to authenticate nodes
before allowing them join a LoRaWAN network. This process is before allowing them join a LoRaWAN network. This process is
called as joining and it is based on pre-shared keys (called called as joining and it is based on pre-shared keys (called
AppKeys in the standard). The joining procedure comprises only AppKeys in the standard). The joining procedure comprises only
one exchange (join-request and join-accept) between the joining one exchange (join-request and join-accept) between the joining
node and the network server. There are several adaptations to node and the network server. There are several adaptations to
this joining procedure that allow network servers to delegate this joining procedure that allow network servers to delegate
authentication and authorization to a backend AAA infrastructure authentication and authorization to a backend AAA infrastructure
[RFC2904]. [RFC2904].
o Wi-SUN Alliance Field Area Network (FAN) uses IEEE 802.1X and EAP- * Wi-SUN Alliance Field Area Network (FAN) uses IEEE 802.1X and EAP-
TLS for network access authentication. It performs a 4-way TLS for network access authentication. It performs a 4-way
handshake to establish a session keys after EAP-TLS handshake to establish a session keys after EAP-TLS
authentication. authentication.
o NB-IoT relies on the traditional 3GPP mutual authentication scheme * NB-IoT relies on the traditional 3GPP mutual authentication scheme
based on a shared-secret in the Subscriber Identity Module (SIM) based on a shared-secret in the Subscriber Identity Module (SIM)
of the device and the mobile operator. of the device and the mobile operator.
o Sigfox security is based on unique device identifiers and * Sigfox security is based on unique device identifiers and
cryptographic keys. As stated in [RFC8376], although the cryptographic keys. As stated in [RFC8376], although the
algorithms and keying details are not publicly available, there is algorithms and keying details are not publicly available, there is
sufficient information to indicate that bootstrapping in Sigfox is sufficient information to indicate that bootstrapping in Sigfox is
based on pre-established credentials between the device and the based on pre-established credentials between the device and the
Sigfox network. Sigfox network.
From the above, it is clear that all LPWAN technologies rely on pre- From the above, it is clear that all LPWAN technologies rely on pre-
provisioned credentials for authentication between a new device and provisioned credentials for authentication between a new device and
the network. Thus, all of them can be categorized as managed the network.
bootstrapping methods.
7.2. Peer-to-Peer or Ad-hoc Methods LPWAN has the following characteristics:
While managed methods are viable for many IoT devices, they may not * Terms: Bootstrapping, provisioning, configuration, discovery.
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 Ad-hoc methods of bootstrapping are used. We discuss a few
example next.
P2P or ad-hoc bootstrapping methods are used for establishing keys * Players: Administrator, Authenticator, Border Router, Client,
and credential information for secure communication without any pre- Device, Manager, Network Server, User
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
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 * Initial beliefs assumed in the device:
for connecting/introducing one of the devices to a centralized
server. Such methods would however be classified as hybrids.
EAP-NOOB [I-D.ietf-emu-eap-noob] is an example of P2P and ad-hoc * Processes:
bootstrapping method that establishes a security association between
an IoT device (node) and an online server (unlike pairing two devices * Beliefs imparted to the device after protocol execution:
for local connections over WiFi or Bluetooth).
2.12. Thread
Thread Group commissioning [threadcommissioning] introduces a two Thread Group commissioning [threadcommissioning] introduces a two
phased process i.e. Petitioning and Joining. Entities involved are phased process i.e. Petitioning and Joining. Entities involved are
leader, joiner, commissioner, joiner router and border router. leader, joiner, commissioner, joiner router, and border router.
Leader is the first device in Thread network that must be Leader is the first device in Thread network that must be
commissioned using out-of-band process and is used to inject correct commissioned using out-of-band process and is used to inject correct
user generated Commissioning Credentials (can be changed later) into user generated Commissioning Credentials (can be changed later) into
Thread Network. Joiner is the node that intends to get authenticated Thread Network. Joiner is the node that intends to get authenticated
and authorized on Thread Network. Commissioner is either within the and authorized on Thread Network. Commissioner is either within the
Thread Network (Native) or connected with Thread Network via a WLAN Thread Network (Native) or connected with Thread Network via a WLAN
(External). (External).
Under some topologies, Joiner Router and Border Router facilitate the Under some topologies, Joiner Router and Border Router facilitate the
Joiner node to reach Native and External Commissioner, respectively. Joiner node to reach Native and External Commissioner, respectively.
skipping to change at page 16, line 5 skipping to change at page 14, line 35
out securely (using pair-wise key) by Joiner Router to Joiner for out securely (using pair-wise key) by Joiner Router to Joiner for
letting Joiner to join the Thread Network. Entities involved in letting Joiner to join the Thread Network. Entities involved in
Joining process depends on system topology i.e. location of Joining process depends on system topology i.e. location of
Commissioner and Joiner. Thread networks only operate using IPv6. Commissioner and Joiner. Thread networks only operate using IPv6.
Thread devices can devise GUAs (Global Unicast Addresses) [RFC4291]. Thread devices can devise GUAs (Global Unicast Addresses) [RFC4291].
Provision also exist via Border Router, for Thread device to acquire Provision also exist via Border Router, for Thread device to acquire
individual global address by means of DHCPv6 or using SLAAC individual global address by means of DHCPv6 or using SLAAC
(Stateless Address Autoconfiguration) address derived with advertised (Stateless Address Autoconfiguration) address derived with advertised
network prefix. network prefix.
7.3. Leap-of-faith/Opportunistic Methods Thread has the following characteristics:
Bergmann et al. [simplekey] develop a secure bootstrapping mechanism * Terms: Commissioning, discovery, provisioning.
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.
7.4. Hybrid Methods * Players: Administrator, Border Agent, Border Router, Commissioner,
Commissioner Candidate, Configurator, Device, End Device, End
Device, Endpoint Identifier, Initiator, Joiner, Joiner Router,
Owner, Peer, Peer, Responder, Server, User
[RFC7250] defines how raw public keys can be used for mutual * Initial beliefs assumed in the device:
authentication of devices and servers. The extension specified in
[RFC7250] 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
typical X.509 version 3 certificates. Each side validates the keys
received with pre-configured values stored. Using raw public keys
for bootstrapping can be seen as a hybrid method. 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). CoAP already provides support for using raw public keys
(see Section 9.1.3.2. of [RFC7252])
8. Security Considerations * Processes:
* Beliefs imparted to the device after protocol execution:
3. Comparison
There are several stages before a device becomes fully operational.
This typically involves establishing some initial trust after which
credentials and other parameters are configured. For DPP,
bootstrapping is the first step before authentication and
provisioning of credentials can occur. For EST, bootstrapping
happens as the first step when the client devices have no
certificates available for starting enrollment. Provisioning/
configuring are terms used for providing additional information to
devices before they are fully operational. For example, credentials
are provisioned onto the device. But before credential provisioning,
a device is bootstrapped and authenticated. Some protocols may only
deal with parts of the process. For example, TLS maybe used for
authentication after bootstrapping. A separate device management
protocol then may run over this TLS tunnel for provisioning
operational information and credentials.
4. Comparison of terminology
5. Comparison of players
6. Comparison of initial beliefs
7. Comparison of processes
8. Comparison of knowledge imparted to the device
9. Security Considerations
This draft does not take any posture on the security properties of This draft does not take any posture on the security properties of
the different bootstrapping protocols discussed. Specific security the different bootstrapping protocols discussed. Specific security
considerations of bootstrapping protocols are present in the considerations of bootstrapping protocols are present in the
respective specifications. respective specifications.
Nonetheless, we briefly discuss some important security aspects which Nonetheless, we briefly discuss some important security aspects which
are not fully explored in various specifications. are not fully explored in various specifications.
Firstly, an IoT system may deal with authorization for resources and Firstly, an IoT system may deal with authorization for resources and
services separately from bootstrapping and authentication in terms of services separately from initial security setup in terms of timing as
timing as well as protocols. As an example, two resource-constrained well as protocols. As an example, two resource-constrained devices A
devices A and B may perform mutual authentication using credentials and B may perform mutual authentication using credentials provided by
provided by an offline third-party X before device A obtains an offline third-party X before device A obtains authorization for
authorization for running a particular application on device B from running a particular application on device B from an online third-
an online third-party Y. In some cases, authentication and party Y. In some cases, authentication and authorization maybe
authorization maybe tightly coupled, e.g., successful authentication tightly coupled, e.g., successful authentication also means
also means successful authorization. successful authorization.
Secondly, re-bootstrapping of IoT devices may be required since keys Secondly, initial security setup of IoT devices may be necessary
have limited lifetimes and devices may be lost or resold. Protocols several times during the device lifecycle since keys have limited
and systems must have adequate provisions for revocation and re- lifetimes and devices may be lost or resold. Protocols and systems
bootstrapping. Re-bootstrapping must be as secure as the initial must have adequate provisions for revocation and fresh security
bootstrapping regardless of whether this re-bootstrapping is done setup. A rerun of the security setup mechanism must be as secure as
manually or automatically over the network. the initial security setup regardless of whether it is done manually
or automatically over the network.
Lastly, some IoT networks use a common group key for multicast and Lastly, some IoT networks use a common group key for multicast and
broadcast traffic. As the number of devices in a network increase broadcast traffic. As the number of devices in a network increase
over time, a common group key may not be scalable and the same over time, a common group key may not be scalable and the same
network may need to be split into separate groups with different network may need to be split into separate groups with different
keys. Bootstrapping and provisioning protocols may need appropriate keys. Bootstrapping and provisioning protocols may need appropriate
mechanisms for identifying and distributing keys to the current mechanisms for identifying and distributing keys to the current
member devices of each group. member devices of each group.
9. IANA Considerations 10. IANA Considerations
There are no IANA considerations for this document. There are no IANA considerations for this document.
10. Acknowledgements 11. Acknowledgements
We would like to thank Tuomas Aura, Hannes Tschofenig, and Michael We would like to thank Tuomas Aura, Hannes Tschofenig, and Michael
Richardson for providing extensive feedback as well as Rafa Marin- Richardson for providing extensive feedback as well as Rafa Marin-
Lopez for his support. Lopez for his support.
11. Informative References 12. Informative References
[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] Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol [dpp] Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol
(DPP)", Wi-Fi Alliance Specification version 1.1, 2018, (DPP)", Wi-Fi Alliance Specification version 1.1, 2018,
<https://www.wi- <https://www.wi-
fi.org/download.php?file=/sites/default/files/private/ fi.org/download.php?file=/sites/default/files/private/
Device_Provisioning_Protocol_Specification_v1.1_1.pdf>. Device_Provisioning_Protocol_Specification_v1.1_1.pdf>.
[fidospec] [fidospec] Fast Identity Online Alliance, "FIDO Device Onboard
Fast Identity Online Alliance, "FIDO IoT Spec", Fido Specification", Fido Alliance Version: 1.0, March 2021,
Alliance Version: 1.0, August 2020, <https://fidoalliance.org/specifications/download-iot-
<https://fidoalliance.org/specs/internet-of-things/ specifications/>.
FIDO-IoT-spec.html>.
[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.ietf-ace-coap-est] [I-D.ietf-ace-coap-est]
Stok, P., Kampanakis, P., Richardson, M., and S. Raza, Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S.
"EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- Raza, "EST over secure CoAP (EST-coaps)", Work in
est-18 (work in progress), January 2020. Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6
January 2020, <https://www.ietf.org/archive/id/draft-ietf-
ace-coap-est-18.txt>.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-ace-wg-coap-eap]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Marin-Lopez, R. and D. Garcia-Carrillo, "EAP-based
and K. Watsen, "Bootstrapping Remote Secure Key Authentication Service for CoAP", Work in Progress,
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Internet-Draft, draft-ietf-ace-wg-coap-eap-03, 26 July
keyinfra-45 (work in progress), November 2020. 2021, <https://www.ietf.org/archive/id/draft-ietf-ace-wg-
coap-eap-03.txt>.
[I-D.ietf-emu-eap-noob] [I-D.ietf-emu-eap-noob]
Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band
authentication for EAP (EAP-NOOB)", draft-ietf-emu-eap- authentication for EAP (EAP-NOOB)", Work in Progress,
noob-03 (work in progress), December 2020. Internet-Draft, draft-ietf-emu-eap-noob-06, 3 September
2021, <https://www.ietf.org/archive/id/draft-ietf-emu-eap-
noob-06.txt>.
[I-D.ietf-emu-eap-tls13] [I-D.ietf-emu-eap-tls13]
Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3", Mattsson, J. P. and M. Sethi, "Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-13 (work in progress), November (EAP-TLS 1.3)", Work in Progress, Internet-Draft, draft-
2020. ietf-emu-eap-tls13-21, 20 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-emu-eap-
[I-D.marin-ace-wg-coap-eap] tls13-21.txt>.
Marin-Lopez, R. and D. Garcia-Carrillo, "EAP-based
Authentication Service for CoAP", draft-marin-ace-wg-coap-
eap-07 (work in progress), January 2021.
[I-D.oflynn-core-bootstrapping] [I-D.oflynn-core-bootstrapping]
Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security
Bootstrapping of Resource-Constrained Devices", draft- Bootstrapping of Resource-Constrained Devices", Work in
oflynn-core-bootstrapping-03 (work in progress), November Progress, Internet-Draft, draft-oflynn-core-bootstrapping-
2010. 03, 7 November 2010, <https://www.ietf.org/archive/id/
draft-oflynn-core-bootstrapping-03.txt>.
[I-D.sethi-gba-constrained] [I-D.sethi-gba-constrained]
Sethi, M., Lehtovirta, V., and P. Salmela, "Using Generic Sethi, M., Lehtovirta, V., and P. Salmela, "Using Generic
Bootstrapping Architecture with Constrained Devices", Bootstrapping Architecture with Constrained Devices", Work
draft-sethi-gba-constrained-01 (work in progress), in Progress, Internet-Draft, draft-sethi-gba-constrained-
February 2014. 01, 13 February 2014, <https://www.ietf.org/archive/id/
draft-sethi-gba-constrained-01.txt>.
[IEEE802.15.4] [IEEE802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
Std. 802.15.4-2015, April 2016, Std. 802.15.4-2015, April 2016,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/802.15.4-2015.html>. standard/802.15.4-2015.html>.
[implicit] [LoRaWAN] LoRa Alliance, "LoRa Specification V1.1", LoRa
Porambage, P., Schmitt, C., Kumar, P., Gurtov, A., and M. Alliance Version: 1.1, October 2017, <https://lora-
Ylianttila, "Pauthkey: A pervasive authentication protocol alliance.org/resource_hub/lorawan-specification-v1-1/>.
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, T., "Kerberos for Internet-of-Things", February
2014, <https://kit.mit.edu/sites/default/files/documents/
Kerberos_Internet_of%20Things.pdf>.
[LoRaWAN] Sornin, N., Luis, M., Eirich, T., and T. Kramp, "LoRa
Specification V1.0", January 2015, <https://www.lora-
alliance.org/portals/0/specs/
LoRaWAN%20Specification%201R0.pdf>.
[ocf] Open Connectivity Foundation, "OCF Security [ocf] Open Connectivity Foundation, "OCF Security
Specification", Version 1.0.0, June 2017, Specification", Version 2.2.2, February 2021,
<https://openconnectivity.org/specs/ <https://openconnectivity.org/specs/
OCF_Security_Specification_v1.0.0.pdf>. OCF_Security_Specification_v2.2.2.pdf>.
[oma] Open Mobile Alliance, "Lightweight Machine to Machine [oma] Open Mobile Alliance, "Lightweight Machine to Machine
Technical Specification: Core", Approved Version 1.2, Technical Specification: Core", Approved Version 1.2,
November 2020, November 2020,
<www.openmobilealliance.org/release/LightweightM2M/ <https://www.openmobilealliance.org/release/
V1_2-20201110-A/OMA-TS-LightweightM2M_Core- LightweightM2M/V1_2-20201110-A/OMA-TS-LightweightM2M_Core-
V1_2-20201110-A.pdf>. V1_2-20201110-A.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, S., Miller, R., Varshavsky, A., Trappe, W., and N.
Mandayam, "Proximate: proximity-based secure pairing using
ambient wireless signals.", Proceedings of MobiSys
International Conference , pp. 211-224, June 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904, D. Spence, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000, DOI 10.17487/RFC2904, August 2000,
<https://www.rfc-editor.org/info/rfc2904>. <https://www.rfc-editor.org/info/rfc2904>.
skipping to change at page 22, line 37 skipping to change at page 20, line 37
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[SEP2.0] ZigBee Alliance, "ZigBee IP Specification", March 2014, [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
<hhttp://www.zigbee.org/non-menu-pages/ and K. Watsen, "Bootstrapping Remote Secure Key
zigbee-ip-download/>. Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure
Bootstrapping of Cloud-Managed Ubiquitous Displays", Bootstrapping of Cloud-Managed Ubiquitous Displays",
Proceedings of ACM International Joint Conference on Proceedings of ACM International Joint Conference on
Pervasive and Ubiquitous Computing (UbiComp 2014), pp. Pervasive and Ubiquitous Computing (UbiComp 2014), pp.
739-750, Seattle, USA, September 2014, 739-750, Seattle, USA, September 2014,
<http://dx.doi.org/10.1145/2632048.2632049>. <http://dx.doi.org/10.1145/2632048.2632049>.
[simpleconn] [simpleconn]
Wi-Fi Alliance, "Wi-Fi Simple Configuration", Wi-Fi Alliance, "Wi-Fi Simple Configuration",
Version 2.0.7, 2019, <https://www.wi- Version 2.0.7, 2019, <https://www.wi-
fi.org/download.php?file=/sites/default/files/private/Wi-F fi.org/download.php?file=/sites/default/files/private/Wi-F
i_Simple_Configuration_Technical_Specification_v2.0.7.pdf> i_Simple_Configuration_Technical_Specification_v2.0.7.pdf>
. .
[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] [threadcommissioning]
Thread Group, "Thread Commissioning", 2015. Thread Group, "Thread Commissioning", 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] [vendorcert]
IEEE std. 802.1ar-2009, "Standard for local and IEEE std. 802.1ar-2009, "Standard for local and
metropolitan area networks - secure device identity", metropolitan area networks - secure device identity",
December 2009. December 2009.
[vermillard]
Vermillard, J., "Bootstrapping device security with
lightweight M2M", Appeared on blog at medium.com ,
February 2015.
[wps] Wi-Fi Alliance, "Wi-fi protected setup", IEEE
Standard XXXXXXXTBS, 2007.
Authors' Addresses Authors' Addresses
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 FI-02420 Jorvas
Finland Finland
Email: mohit@piuha.net Email: mohit@piuha.net
Behcet Sarikaya Behcet Sarikaya
Denpel Informatique Denpel Informatique
Email: sarikaya@ieee.org Email: sarikaya@ieee.org
Dan Garcia-Carrillo Dan Garcia-Carrillo
University of Oviedo University of Oviedo
Oviedo 33207 33207 Oviedo
Spain Spain
Email: garciadan@uniovi.es Email: garciadan@uniovi.es
 End of changes. 103 change blocks. 
556 lines changed or deleted 440 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/