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/ |