draft-irtf-t2trg-security-setup-iot-devices-01.txt   draft-irtf-t2trg-security-setup-iot-devices-02.txt 
Network Working Group M. Sethi Network Working Group M. Sethi
Internet-Draft Aalto University Internet-Draft Aalto University
Intended status: Informational B. Sarikaya Intended status: Informational B. Sarikaya
Expires: 28 March 2024 Expires: 26 September 2024
D. Garcia-Carrillo D. Garcia-Carrillo
University of Oviedo University of Oviedo
25 September 2023 25 March 2024
Terminology and processes for initial security setup of IoT devices Terminology and processes for initial security setup of IoT devices
draft-irtf-t2trg-security-setup-iot-devices-01 draft-irtf-t2trg-security-setup-iot-devices-02
Abstract Abstract
This document provides an overview of terms that are commonly used This document provides an overview of terms that are commonly used
when discussing the initial security setup of Internet of Things when discussing the initial security setup of Internet of Things
(IoT) devices. This document also presents a brief but illustrative (IoT) devices. This document also presents a brief but illustrative
survey of protocols and standards available for initial security survey of protocols and standards available for initial security
setup of IoT devices. For each protocol, we identify the terminology setup of IoT devices. For each protocol, we identify the terminology
used, the entities involved, the initial assumptions, the processes used, the entities involved, the initial assumptions, the processes
necessary for completion, and the knowledge imparted to the IoT necessary for completion, and the knowledge imparted to the IoT
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 28 March 2024. This Internet-Draft will expire on 26 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Standards and Protocols . . . . . . . . . . . . . . . . . . . 4 2. Standards and Protocols . . . . . . . . . . . . . . . . . . . 4
2.1. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Device Provisioning Protocol (DPP) . . . . . . . . . . . 6 2.2. Device Provisioning Protocol (DPP) . . . . . . . . . . . 6
2.3. Enrollment over Secure Transport (EST) . . . . . . . . . 7 2.3. Enrollment over Secure Transport (EST) . . . . . . . . . 7
2.4. Open Mobile Alliance (OMA) Lightweight Machine to Machine 2.4. Open Mobile Alliance (OMA) Lightweight Machine to Machine
specification (LwM2M) . . . . . . . . . . . . . . . . . 8 specification (LwM2M) . . . . . . . . . . . . . . . . . 8
skipping to change at page 2, line 50 skipping to change at page 2, line 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Initial security setup for a device refers to any process that takes Initial security setup for a device refers to any process that takes
place before a device can become fully operational. The phrase place before a device can become fully operational. The phrase
*initial security setup* intentionally includes the term _security_ *initial security setup* intentionally includes the term _security_
as setup of devices without adequate security or with insecure as setup of devices without adequate security or with insecure
processes is no longer acceptable. The initial security setup processes is no longer acceptable. The initial security setup
process, among other things, involves network discovery and process, among other things, involves network discovery and
selection, access authentication, configuration of necessary selection, access authentication, and configuration of necessary
credentials and parameters. credentials and parameters.
Initial security setup for IoT devices is challenging because the Initial security setup for IoT devices is challenging because the
size of an IoT network varies from a couple of devices to tens of size of an IoT network varies from a couple of devices to tens of
thousands, depending on the application. Moreover, devices in IoT thousands, depending on the application. Moreover, devices in IoT
networks are produced by a variety of vendors and are typically networks are produced by a variety of vendors and are typically
heterogeneous in terms of the constraints on their power supply, heterogeneous in terms of the constraints on their power supply,
communication capability, computation capacity, and user interfaces communication capability, computation capacity, and user interfaces
available. This challenge of initial security setup in IoT was available. This challenge of initial security setup in IoT was
identified by Sethi et al. [Sethi14] while developing a solution for identified by Sethi et al. [Sethi14] while developing a solution for
skipping to change at page 3, line 25 skipping to change at page 3, line 25
Initial security setup of devices typically also involves providing Initial security setup of devices typically also involves providing
them with some sort of network connectivity. The functionality of a them with some sort of network connectivity. The functionality of a
disconnected device is rather limited. Initial security setup of disconnected device is rather limited. Initial security setup of
devices often assumes that some network has been setup a-priori. devices often assumes that some network has been setup a-priori.
Setting up and maintaining a network itself is challenging. For Setting up and maintaining a network itself is challenging. For
example, users may need to configure the network name (called as example, users may need to configure the network name (called as
Service Set Identifier (SSID) in Wi-Fi networks) and passphrase Service Set Identifier (SSID) in Wi-Fi networks) and passphrase
before new devices can be setup. Specifications such as the Wi-Fi before new devices can be setup. Specifications such as the Wi-Fi
Alliance Simple Configuration [simpleconn] help users setup networks. Alliance Simple Configuration [simpleconn] help users setup networks.
However, this document is only focused on terminology and processes However, this document is only focused on terminology and processes
associated with initial security setup of devices and excludes any associated with the initial security setup of devices and excludes
discussion on setting up networks. any discussion on setting up networks.
There are several terms that are used in the context of initial There are several terms that are used in the context of initial
security setup of devices: security setup of devices:
* Bootstrapping * Bootstrapping
* Provisioning * Provisioning
* Onboarding * Onboarding
skipping to change at page 3, line 50 skipping to change at page 3, line 50
* Initialization * Initialization
* Configuration * Configuration
* Registration * Registration
* Discovery * Discovery
In addition to using a variety of different terms, initial security In addition to using a variety of different terms, initial security
setup mechanisms can rely on a number of entities. For example, a setup mechanisms can rely on several entities. For example, a
companion smartphone device maybe necessary for some initial security companion smartphone device may be necessary for some initial
setup mechanisms. Moreover, security setup procedures have diverse security setup mechanisms. Moreover, security setup procedures have
initial assumptions about the device being setup. As an example, an diverse initial assumptions about the device being setup. As an
initial security setup mechanism may assume that the device is example, an initial security setup mechanism may assume that the
provisioned with a pre-shared key and a list of trusted network device is provisioned with a pre-shared key and a list of trusted
identifiers. Finally, initial security setup mechanisms impart network identifiers. Finally, initial security setup mechanisms
different information to the device after completion. For example, impart different information to the device after completion. For
some mechanisms may only provide a key for use with an authorization example, some mechanisms may only provide a key for use with an
server, while others may configure elaborate access control lists authorization server, while others may configure elaborate access
directly. control lists directly.
The next section provides an overview of some standards and protocols The next section provides an overview of some standards and protocols
for initial security setup of IoT devices. For each mechanism, the for initial security setup of IoT devices. For each mechanism, the
following are explicitly identified: following are explicitly identified:
* Terminology used * Terminology used
* Entities or "players" involved * Entities or "players" involved
* Initial assumptions about the device * Initial assumptions about the device
skipping to change at page 4, line 40 skipping to change at page 4, line 40
Bluetooth mesh specifies a provisioning protocol. The goal of the Bluetooth mesh specifies a provisioning protocol. The goal of the
provisioning phase is to securely incorporate a new Bluetooth mesh provisioning phase is to securely incorporate a new Bluetooth mesh
node, by completing two critical tasks. First, to authenticate the node, by completing two critical tasks. First, to authenticate the
unprovisioned device and second, to create a secure link with said unprovisioned device and second, to create a secure link with said
device to share information. device to share information.
The provisioning process is divided into five distinct stages The provisioning process is divided into five distinct stages
summarize next: summarize next:
* Beaconing for discover: The new unprovisioned device is discovered * Beaconing for discovery: The new unprovisioned device is
by the provisioner discovered by the provisioner
* Negotiation: The unprovisioned device indicates to the provisioner * Negotiation: The unprovisioned device indicates to the provisioner
a set of capabilities such as the security algorithms supported, a set of capabilities such as the security algorithms supported,
the availability of its public key using an Out-of-Band (OOB) the availability of its public key using an Out-of-Band (OOB)
channel and the input/output interfaces supported channel and the input/output interfaces supported
* Public-key exchange: The authentication method is selected by the * Public-key exchange: The authentication method is selected by the
provisioner and both devices exchange Elliptic-curve provisioner and both devices exchange Elliptic-curve
Diffie–Hellman (ECDH) public keys. These keys may be static or Diffie–Hellman (ECDH) public keys. These keys may be static or
ephemeral. Their exchange can be done in two ways, either via ephemeral. Their exchange can be done in two ways, either via
skipping to change at page 5, line 37 skipping to change at page 5, line 37
such as a Network key, to secure the communications at network such as a Network key, to secure the communications at network
layer and a unicast address among other information. layer and a unicast address among other information.
Bluetooth mesh has the following characteristics: Bluetooth mesh has the following characteristics:
* Terms: Configuration, discovery, provisioning. * Terms: Configuration, discovery, provisioning.
* Players: Client, Device, Manager, Manufacturer, Peer, Server, User * Players: Client, Device, Manager, Manufacturer, Peer, Server, User
* Initial beliefs assumed in the device: Previously to the * Initial beliefs assumed in the device: Previously to the
provisioning phase, there is no pre-shared credentials for a trust provisioning phase, there are no pre-shared credentials for a
relation. trust relation.
* Processes: Provisioning * Processes: Provisioning
* Beliefs imparted to the device after protocol execution: After the * Beliefs imparted to the device after protocol execution: After the
provisiong, the device trusts the provisioner entity and any other provisioning, the device trusts the provisioner entity and any
device in the network sharing its network key. other device in the network sharing its network key.
2.2. Device Provisioning Protocol (DPP) 2.2. 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:
* 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.
* 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 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 exchanged out-of-band in both
directions). directions).
* 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.
DPP has the following characteristics: DPP has the following characteristics:
* Terms: Bootstrapping, configuration, discovery, enrollment, * Terms: Bootstrapping, configuration, discovery, enrollment,
provisioning. provisioning.
skipping to change at page 7, line 19 skipping to change at page 7, line 19
devices employ the DPP Authentication protocol's bootstrapping devices employ the DPP Authentication protocol's bootstrapping
keys. Configuration: The Configurator uses the DPP Configuration keys. Configuration: The Configurator uses the DPP Configuration
protocol to provision the Enrollee through the secure channel protocol to provision the Enrollee through the secure channel
created during DPP Authentication. Network access: The Enrollee created during DPP Authentication. Network access: The Enrollee
establishes network access using the newly provisioned establishes network access using the newly provisioned
credentials. credentials.
* Beliefs imparted to the device after protocol execution: DPP * Beliefs imparted to the device after protocol execution: DPP
bootstrapping relies on the transfer of the public-key that is bootstrapping relies on the transfer of the public-key that is
expected to be trusted. The beliefs when mutual authentication is expected to be trusted. The beliefs when mutual authentication is
run, relies on the trust of a succesful DPP bootstrapping. When run, relies on the trust of a successful DPP bootstrapping. When
mutual authentication is not supported, a device that can control mutual authentication is not supported, a device that can control
when and how its own public key is bootstrapped, can perform a when and how its own public key is bootstrapped, can perform a
weak authentication to any entity that knows its public key. weak authentication to any entity that knows its public key.
2.3. Enrollment over Secure Transport (EST) 2.3. 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
skipping to change at page 8, line 16 skipping to change at page 8, line 16
distribution of initial information which provides both the EST distribution of initial information which provides both the EST
client and server with the information for the EST client and client and server with the information for the EST client and
server to perform mutual authentication as well as for server to perform mutual authentication as well as for
authorization. authorization.
* Processes: Distribution of Certificates, Bootstrap, Enrollment * Processes: Distribution of Certificates, Bootstrap, Enrollment
* Beliefs imparted to the device after protocol execution: The EST * Beliefs imparted to the device after protocol execution: The EST
enrollment process is designed to make establishing automated enrollment process is designed to make establishing automated
certificate issuing from a trustworthy CA as simple as possible. certificate issuing from a trustworthy CA as simple as possible.
After the processe have finished, the device is able to After the process has finished, the device is able to
automatically renew its certificates through re-enrollment as it automatically renew its certificates through re-enrollment as it
has a trust relation with the ESP server. has a trust relation with the ESP server.
2.4. Open Mobile Alliance (OMA) Lightweight Machine to Machine 2.4. Open Mobile Alliance (OMA) Lightweight Machine to Machine
specification (LwM2M) specification (LwM2M)
LwM2M specification developed by OMA [oma] defines a RESTful LwM2M specification developed by OMA [oma] defines a RESTful
architecture where a new IoT device (LwM2M client) first contacts an architecture where a new IoT device (LwM2M client) first contacts an
LwM2M Bootstrap-Server for obtaining essential information such LwM2M Bootstrap-Server for obtaining essential information such
credentials for subsequently registering with one or more LwM2M credentials for subsequently registering with one or more LwM2M
skipping to change at page 8, line 39 skipping to change at page 8, line 39
data, controlling an actuator, modifying access controls etc.). data, controlling an actuator, modifying access controls etc.).
LwM2M specification does not deal with the initial network LwM2M specification does not deal with the initial network
configuration of IoT devices and assumes that the IoT client device configuration of IoT devices and assumes that the IoT client device
has network reachability to the LwM2M Bootstrap-Server and LwM2M has network reachability to the LwM2M Bootstrap-Server and LwM2M
Server. Server.
The current standard defines the following four bootstrapping modes: The current standard defines the following four bootstrapping modes:
* Factory Bootstrap: An IoT device is configured with all the * Factory Bootstrap: An IoT device is configured with all the
information necessary for securely communicating with an LwM2M information necessary for securely communicating with an LwM2M
Bootstrap-Server and/or LwM2M Serverwhile it is manufactured and Bootstrap-Server and/or LwM2M Server while it is manufactured and
prior to its deployment. prior to its deployment.
* Bootstrap from Smartcard: An IoT device retrieves all the * Bootstrap from Smartcard: An IoT device retrieves all the
information necessary for securely communicating with an LwM2M information necessary for securely communicating with an LwM2M
Bootstrap-Server and/or LwM2M Server from a Smartcard. Bootstrap-Server and/or LwM2M Server from a Smartcard.
* Client Initiated Bootstrap: If the IoT device in one of the above * Client Initiated Bootstrap: If the IoT device in one of the above
bootstrapping modes is only configured with information about an bootstrapping modes is only configured with information about an
LwM2M Bootstrap-Server, then the client device must first LwM2M Bootstrap-Server, then the client device must first
communicate securely with the configured LwM2M Bootstrap-Server communicate securely with the configured LwM2M Bootstrap-Server
and obtain necessary information and credentials to subsequently and obtain the necessary information and credentials to
register with one or more LwM2M Servers. subsequently register with one or more LwM2M Servers.
* Server Initiated Bootstrap: In this bootstrapping mode, the LwM2M * Server Initiated Bootstrap: In this bootstrapping mode, the LwM2M
server triggers the client device to begin the client initiated server triggers the client device to begin the client initiated
bootstrap sequence described above. bootstrap sequence described above.
The LwM2M specification is also quite flexible in terms of the The LwM2M specification is also quite flexible in terms of the
credentials and the transport security mechanism used between the credentials and the transport security mechanism used between the
client device and the LwM2M Server or the LwM2M Bootstrap-Server. client device and the LwM2M Server or the LwM2M Bootstrap-Server.
Credentials such as a pre-shared symmetric key, a raw public key Credentials such as a pre-shared symmetric key, a raw public key
(RPK), or x.509 certificates can be used with various transport (RPK), or x.509 certificates can be used with various transport
skipping to change at page 9, line 34 skipping to change at page 9, line 34
device uses the Enrollment over Secure Transport (EST) certificate device uses the Enrollment over Secure Transport (EST) certificate
management protocol for provisioning certificates from the LwM2M management protocol for provisioning certificates from the LwM2M
Bootstrap-Server to the LwM2M Client. Bootstrap-Server to the LwM2M Client.
OMA has the following characteristics: OMA has the following characteristics:
* *Terms*: * *Terms*:
- _Bootstrapping_ and _Unbootstrapping_: Bootstrapping is used - _Bootstrapping_ and _Unbootstrapping_: Bootstrapping is used
for describing the process of providing an IoT device with for describing the process of providing an IoT device with
credentials and information of one or more LwM2M server. credentials and information of one or more LwM2M servers.
Interestingly, the transport bindings specification Interestingly, the transport bindings specification
[oma-transport] also uses the term unbootstrapping for the [oma-transport] also uses the term unbootstrapping for the
process where objects corresponding to an LwM2M Server are process where objects corresponding to an LwM2M Server are
deleted on the client. deleted on the client.
- _Provisioning_ and _configuration_: terms used to refer to the - _Provisioning_ and _configuration_: terms used to refer to the
process of providing some infomration to a LwM2M client. process of providing some information to a LwM2M client.
- _Discovery_: term for the process by which a LwM2M Bootstrap- - _Discovery_: term for the process by which a LwM2M Bootstrap-
Server or LwM2M Server discovers objects, object instances, Server or LwM2M Server discovers objects, object instances,
resources, and attributes supported by RESTful interfaces of a resources, and attributes supported by RESTful interfaces of a
LwM2M Client. LwM2M Client.
- _Register_ and _De-register_: Register is the process by which - _Register_ and _De-register_: Register is the process by which
a client device sets up a secure association with an LwM2M a client device sets up a secure association with an LwM2M
Server and provides the server with information about objects Server and provides the server with information about objects
and existing object instances of the client. De-register is and existing object instances of the client. De-register is
skipping to change at page 10, line 23 skipping to change at page 10, line 23
- _Intialization_: term for the process by which an LwM2M - _Intialization_: term for the process by which an LwM2M
Bootstrap-Server or LwM2M Server deletes objects on the client Bootstrap-Server or LwM2M Server deletes objects on the client
before performing any write operations. before performing any write operations.
* *Players*: Device manufacturers or Smartcard manufacturers are * *Players*: Device manufacturers or Smartcard manufacturers are
responsible for providing client IoT devices with initial responsible for providing client IoT devices with initial
information and credentials of LwM2M Bootstrap-Server and/or LwM2M information and credentials of LwM2M Bootstrap-Server and/or LwM2M
server. server.
* *Initial beliefs assumed in the device*: The client at the very * *Initial beliefs assumed in the device*: The client at the very
least has necessary information to trust the LwM2M bootstrap least has the necessary information to trust the LwM2M bootstrap
server in the . server.
* *Processes*: LwM2M does not require any actions from the device * *Processes*: LwM2M does not require any actions from the device
owner/user. Once the device is registered with the LwM2M server, owner/user. Once the device is registered with the LwM2M server,
various actions related to device management can be performed by various actions related to device management can be performed by
device owner/user via the LwM2M server. device owner/user via the LwM2M server.
* *Beliefs imparted to the device after protocol execution*: After * *Beliefs imparted to the device after protocol execution*: After
the bootstrapping is performed, the LwM2M client can register the bootstrapping is performed, the LwM2M client can register
(Security object and Server object) with the LwM2M servers. (Security object and Server object) with the LwM2M servers.
skipping to change at page 11, line 39 skipping to change at page 11, line 39
owner. The local network needs standard AAA configuration for owner. The local network needs standard AAA configuration for
routing EAP-NOOB sessions to the application server chosen by the routing EAP-NOOB sessions to the application server chosen by the
device owner/user. device owner/user.
* *Initial beliefs assumed in the device*: EAP-NOOB does not require * *Initial beliefs assumed in the device*: EAP-NOOB does not require
devices to have any pre-installed credentials but expects all devices to have any pre-installed credentials but expects all
devices to use a standard identifier (noob@eap-noob.arpa) during devices to use a standard identifier (noob@eap-noob.arpa) during
initial network discovery. initial network discovery.
* *Processes*: The IoT device performs network discovery and one or * *Processes*: The IoT device performs network discovery and one or
more OOB outputs maybe generated. The user is expected EAP more OOB outputs may be generated. The user is expected EAP
exchange is encompassed by Initial Exchange, OOB step, Completion exchange is encompassed by Initial Exchange, OOB step, Completion
Exchange and Waiting Exchange. Exchange and Waiting Exchange.
* *Beliefs imparted to the device after protocol execution*: After * *Beliefs imparted to the device after protocol execution*: After
EAP-NOOB botstrapping process is complete, the device and server EAP-NOOB bootstrapping process is complete, the device and server
establish a long-term secret which can renewed without further establish a long-term secret, which can be renewed without further
user involvement. As a side-effect, the device also obtains user involvement. As a side-effect, the device also obtains
identifier and credentials for network and Internet connectivity identifier and credentials for network and Internet connectivity
(via the EAP authenticator). (via the EAP authenticator).
2.6. Open Connectivity Foundation (OCF) 2.6. 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 a onboarding process is configuring the ownership, i.e., establishing a
legitimate user that owns the device. For this, the user is supposed legitimate user that owns the device. For this, the user is supposed
skipping to change at page 12, line 32 skipping to change at page 12, line 32
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 on-path for provisioning. Naturally, this mode is vulnerable to on-path
attackers. attackers.
* 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.
* 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.
* 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 provisions/ established secure communication, the onboarding tool provisions/
configures the device with Owner credentials. Owner credentials may configures the device with Owner credentials. Owner credentials may
consist of certificates, shared keys, or Kerberos tickets for consist of certificates, shared keys, or Kerberos tickets for
skipping to change at page 13, line 14 skipping to change at page 13, line 14
* Terms: Configuration, discovery, enrollment, onboarding, * Terms: Configuration, discovery, enrollment, onboarding,
provisioning, registration, provisioning, registration,
* Players: Client, Device, Manager, Manufacturer, Owner, Peer, * Players: Client, Device, Manager, Manufacturer, Owner, Peer,
Server, User Server, User
* Initial beliefs assumed in the device: The device needs to be * Initial beliefs assumed in the device: The device needs to be
associated with an owner in the onboarding process and then go associated with an owner in the onboarding process and then go
through the provisioning process before being considered as through the provisioning process before being considered as
trustworty. trustworthy.
* Processes: Onboarding, provisioning. * Processes: Onboarding, provisioning.
* Beliefs imparted to the device after protocol execution: In the * Beliefs imparted to the device after protocol execution: In the
provisioning phase the device receives the necessary credentials provisioning phase the device receives the necessary credentials
to interact with provisioning services and any other services or to interact with provisioning services and any other services or
devices that are part of the normal operation of the device. devices that are part of the normal operation of the device.
2.7. Fast IDentity Online (FIDO) alliance 2.7. Fast IDentity Online (FIDO) alliance
skipping to change at page 13, line 48 skipping to change at page 13, line 48
(CoAP) [RFC7252] or directly over TCP, Bluetooth etc. FIDO IoT (CoAP) [RFC7252] or directly over TCP, Bluetooth etc. FIDO IoT
however assumes that the device already has IP connectivity to a however assumes that the device already has IP connectivity to a
rendezvous server. Establishing this initial IP connectivity is rendezvous server. Establishing this initial IP connectivity is
explicitly stated as "out-of-scope" but the draft specification hints explicitly stated as "out-of-scope" but the draft specification hints
at the usage of Hypertext Transfer Protocol (HTTP) [RFC7230] proxies at the usage of Hypertext Transfer Protocol (HTTP) [RFC7230] proxies
for IP networks and other forms of tunnelling for non-IP networks. for IP networks and other forms of tunnelling for non-IP networks.
The specification only provides a non-normative example of the DI The specification only provides a non-normative example of the DI
protocol which must be executed in the factory during device protocol which must be executed in the factory during device
manufacture. This protocol embeds initial ownership and manufacture. This protocol embeds initial ownership and
manufacturing credentials into Restricted Operation Environment (ROE) manufacturing credentials into a Restricted Operation Environment
on the device. The initial information embedded also includes a (ROE) on the device. The initial information embedded also includes
unique device identifier (called as GUID in the specification). a unique device identifier (called GUID in the specification). After
After DI is executed, the manufacturer has an ownership voucher which DI is executed, the manufacturer has an ownership voucher which is
is passed along the supply chain to the device owner. passed along the supply chain to the device owner.
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 use.
FIDO has the following characteristics: FIDO has the following characteristics:
* Terms: Provisioning, onboarding, commissioning, initialisation. * Terms: Provisioning, onboarding, commissioning, initialisation.
* Players: Device, Manager, Manufacturer, Owner, Rendezvous Server, * Players: Device, Manager, Manufacturer, Owner, Rendezvous Server,
User User
* Initial beliefs assumed in the device: In the initial state the * Initial beliefs assumed in the device: In the initial state the
device is not yet associated with a specific owner. The DI device is not yet associated with a specific owner. The DI
process has to take place to embed owndership and manufacturing process has to take place to embed ownership and manufacturing
credentials in the device, the first in a chaim to create an credentials in the device, the first in a chain to create an
ownership voucher that will be used to perform the transfer of ownership voucher that will be used to perform the transfer of
ownership of the device. ownership of the device.
* Processes: Device Initialize Protocol (DI), Transfer Ownership * Processes: Device Initialize Protocol (DI), Transfer Ownership
Protocol 0 (TO0), Transfer Ownership Protocol 1 (TO1), Transfer Protocol 0 (TO0), Transfer Ownership Protocol 1 (TO1), Transfer
Ownership Protocol 2 (TO2) Ownership Protocol 2 (TO2)
* Beliefs imparted to the device after protocol execution: When the * Beliefs imparted to the device after protocol execution: When the
device is powered on, and all TO protocols run, the device figures device is powered on, and all TO protocols run, the device figures
out by contacting with the rendezvous server, who the owner is, out by contacting the rendezvous server, who the owner is,
authenticate with the owner. At this point the rendezvous server, authenticate with the owner. At this point the rendezvous server,
and owner are able to authenticate the device. and the owner are able to authenticate the device.
2.8. Bootstrapping Remote Secure Key Infrastructures (BRSKI) 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 [ieee8021ar] vendor certificates devices that rely on 802.1AR [ieee8021ar] vendor certificates called
called Bootstrapping Remote Secure Key Infrastructures (BRSKI) Bootstrapping Remote Secure Key Infrastructures (BRSKI) [RFC8995].
[RFC8995]. In addition to vendor installed IEEE 802.1AR In addition to vendor installed IEEE 802.1AR certificates, a vendor
certificates, a vendor based service on the Internet is required. based service on the Internet is required. Before being
Before being authenticated, a new device only needs link-local authenticated, a new device only needs link-local connectivity, and
connectivity, and does not require a routable address. When a vendor does not require a routable address. When a vendor provides an
provides an Internet based service, devices can be forced to join Internet based service, devices can be forced to join only specific
only specific domains. The document highlights that the described domains. The document highlights that the described solution is
solution is aimed in general at non-constrained (i.e. class 2+ aimed in general at non-constrained (i.e. class 2+ defined in
defined in [RFC7228]) devices operating in a non-challenged network. [RFC7228]) devices operating in a non-challenged network. It claims
It claims to scale to thousands of devices located in hostile to scale to thousands of devices located in hostile environments,
environments, such as ISP provided CPE devices which are drop-shipped such as ISP provided CPE devices which are drop-shipped to the end
to the end user. user.
BRSKI has the following characteristics: BRSKI has the following characteristics:
* Terms: Bootstrapping, provisioning, enrollment, onboarding. * Terms: Bootstrapping, provisioning, enrollment, onboarding.
* Players: Administrator, Client, Cloud Registrar, Configurator, * Players: Administrator, Client, Cloud Registrar, Configurator,
Device, Domain Registrar, Initiator, Join Proxy, JRC, Device, Domain Registrar, Initiator, Join Proxy, JRC,
Manufacturer, Owner, Peer, Pledge, Server, User Manufacturer, Owner, Peer, Pledge, Server, User
* Initial beliefs assumed in the device: Every device has an IDevID, * Initial beliefs assumed in the device: Every device has an IDevID,
 End of changes. 33 change blocks. 
66 lines changed or deleted 70 lines changed or added

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