< draft-irtf-t2trg-secure-bootstrapping-01.txt   draft-irtf-t2trg-secure-bootstrapping-02.txt >
Network Working Group M. Sethi Network Working Group M. Sethi
Internet-Draft Ericsson Internet-Draft Aalto University
Intended status: Informational B. Sarikaya Intended status: Informational B. Sarikaya
Expires: 26 April 2022 Denpel Informatique Expires: 27 October 2022 Denpel Informatique
D. Garcia-Carrillo D. Garcia-Carrillo
University of Oviedo University of Oviedo
23 October 2021 25 April 2022
Terminology and processes for initial security setup of IoT devices Terminology and processes for initial security setup of IoT devices
draft-irtf-t2trg-secure-bootstrapping-01 draft-irtf-t2trg-secure-bootstrapping-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 completetion, and the knowledge imparted to the IoT necessary for completetion, 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 26 April 2022. This Internet-Draft will expire on 27 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. 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. Device Provisioning Protocol (DPP) . . . . . . . . . . . 4 2.1. Device Provisioning Protocol (DPP) . . . . . . . . . . . 4
2.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) . . . 5 2.2. Open Mobile Alliance (OMA) Lightweight M2M (LwM2M) . . . 5
2.3. Open Connectivity Foundation (OCF) . . . . . . . . . . . 6 2.3. Open Connectivity Foundation (OCF) . . . . . . . . . . . 6
2.4. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Fast IDentity Online (FIDO) alliance . . . . . . . . . . 9 2.5. Fast IDentity Online (FIDO) alliance . . . . . . . . . . 9
2.6. Fast IDentity Online (FIDO) alliance . . . . . . . . . . 9 2.6. Enrollment over Secure Transport (EST) . . . . . . . . . 10
2.7. Enrollment over Secure Transport (EST) . . . . . . . . . 10 2.7. Bootstrapping Remote Secure Key Infrastructures
2.8. Bootstrapping Remote Secure Key Infrastructures
(BRSKI) . . . . . . . . . . . . . . . . . . . . . . . . 10 (BRSKI) . . . . . . . . . . . . . . . . . . . . . . . . 10
2.9. Secure Zero Touch Provisioning . . . . . . . . . . . . . 11 2.8. Secure Zero Touch Provisioning . . . . . . . . . . . . . 11
2.10. Nimble out-of-band authentication for EAP (EAP-NOOB) . . 12 2.9. Nimble out-of-band authentication for EAP (EAP-NOOB) . . 12
2.11. LPWAN . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.10. LPWAN . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.12. Thread . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.11. Thread . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Comparison of terminology . . . . . . . . . . . . . . . . . . 15 3.1. Comparison of terminology . . . . . . . . . . . . . . . . 15
5. Comparison of players . . . . . . . . . . . . . . . . . . . . 15 3.2. Comparison of players . . . . . . . . . . . . . . . . . . 15
6. Comparison of initial beliefs . . . . . . . . . . . . . . . . 15 3.3. Comparison of initial beliefs . . . . . . . . . . . . . . 15
7. Comparison of processes . . . . . . . . . . . . . . . . . . . 15 3.4. Comparison of processes . . . . . . . . . . . . . . . . . 15
8. Comparison of knowledge imparted to the device . . . . . . . 15 3.5. Comparison of knowledge imparted to the device . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. Informative References . . . . . . . . . . . . . . . . . . . 16 7. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 operational. The phrase "initial place before a device can become operational. The phrase "initial
security setup" intentionally includes the term "security" as setup security setup" intentionally includes the term "security" as setup
of devices without adequate security or with insecure processes is no of devices without adequate security or with insecure processes is no
longer acceptable. The initial security setup process, among other longer acceptable. The initial security setup process, among other
things, involves network discovery and selection, access things, involves network discovery and selection, access
authentication, configuration of necessary credentials and authentication, configuration of necessary credentials and
skipping to change at page 9, line 7 skipping to change at page 9, line 7
* Players: Client, Device, Manager, Manufacturer, Peer, Server, User * Players: Client, Device, Manager, Manufacturer, Peer, Server, User
* Initial beliefs assumed in the device: * Initial beliefs assumed in the device:
* Processes: * Processes:
* Beliefs imparted to the device after protocol execution: * Beliefs imparted to the device after protocol execution:
2.5. Fast IDentity Online (FIDO) alliance 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
(DI) protocol and 3 Transfer of Ownership (TO) protocols TO0, TO1, (DI) protocol and 3 Transfer of Ownership (TO) protocols TO0, TO1,
skipping to change at page 10, line 11 skipping to change at page 10, line 9
* Players: Device, Manager, Manufacturer, Owner, Rendezvous Server, * Players: Device, Manager, Manufacturer, Owner, Rendezvous Server,
Server, User Server, User
* Initial beliefs assumed in the device: * Initial beliefs assumed in the device:
* Processes: * Processes:
* Beliefs imparted to the device after protocol execution: * Beliefs imparted to the device after protocol execution:
2.7. Enrollment over Secure Transport (EST) 2.6. 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
skipping to change at page 10, line 44 skipping to change at page 10, line 42
* Players: Administrator, Client, Device, Manufacturer, Owner, Peer, * Players: Administrator, Client, Device, Manufacturer, Owner, Peer,
Peer, Responder, Server, User Peer, Responder, Server, User
* Initial beliefs assumed in the device: * Initial beliefs assumed in the device:
* Processes: * Processes:
* Beliefs imparted to the device after protocol execution: * Beliefs imparted to the device after protocol execution:
2.8. Bootstrapping Remote Secure Key Infrastructures (BRSKI) 2.7. 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) [RFC8995]. Bootstrapping Remote Secure Key Infrastructures (BRSKI) [RFC8995].
In addition to vendor installed IEEE 802.1AR certificates, a vendor In addition to vendor installed IEEE 802.1AR certificates, a vendor
based service on the Internet is required. Before being based service on the Internet is required. Before being
authenticated, a new device only needs link-local connectivity, and authenticated, a new device only needs link-local connectivity, and
does not require a routable address. When a vendor provides an does not require a routable address. When a vendor provides an
Internet based service, devices can be forced to join only specific Internet based service, devices can be forced to join only specific
domains. The document highlights that the described solution is domains. The document highlights that the described solution is
skipping to change at page 11, line 26 skipping to change at page 11, line 24
* 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: * Initial beliefs assumed in the device:
* Processes: * Processes:
* Beliefs imparted to the device after protocol execution: * Beliefs imparted to the device after protocol execution:
2.9. Secure Zero Touch Provisioning 2.8. 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].
skipping to change at page 12, line 5 skipping to change at page 12, line 5
* Players: Administrator, Bootstrap Server, Client, Device, * Players: Administrator, Bootstrap Server, Client, Device,
Manufacturer, Onboarding Server, Owner, Redirect Server, Manufacturer, Onboarding Server, Owner, Redirect Server,
Responder, Server, User Responder, Server, User
* Initial beliefs assumed in the device: * Initial beliefs assumed in the device:
* Processes: * Processes:
* Beliefs imparted to the device after protocol execution: * Beliefs imparted to the device after protocol execution:
2.10. Nimble out-of-band authentication for EAP (EAP-NOOB) 2.9. 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 [RFC9140] defines an EAP method where the authentication is
authentication is based on a user-assisted out-of-band (OOB) channel based on a user-assisted out-of-band (OOB) channel between the server
between the server and peer. It is intended as a generic and peer. It is intended as a generic bootstrapping solution for IoT
bootstrapping solution for IoT devices which have no pre-configured devices which have no pre-configured authentication credentials and
authentication credentials and which are not yet registered on the which are not yet registered on the authentication server. This
authentication server. This method claims to be more generic than method claims to be more generic than most ad-hoc bootstrapping
most ad-hoc bootstrapping solutions in that it supports many types of solutions in that it supports many types of OOB channels. The exact
OOB channels. The exact in-band messages and OOB message contents in-band messages and OOB message contents are specified and not the
are specified and not the OOB channel details. EAP-NOOB also OOB channel details. EAP-NOOB also supports IoT devices with only
supports IoT devices with only output (e.g. display) or only input output (e.g. display) or only input (e.g. camera). It makes combined
(e.g. camera). It makes combined use of both secrecy and integrity use of both secrecy and integrity of the OOB channel for more robust
of the OOB channel for more robust security than the ad-hoc security than the ad-hoc solutions.
solutions.
EAP-NOOB has the following characteristics: EAP-NOOB has the following characteristics:
* Terms: Bootstrapping, configuration, registration. * Terms: Bootstrapping, configuration, registration.
* Players: Administrator, Authenticator, Client, Device, * Players: Administrator, Authenticator, Client, Device,
Manufacturer, Owner, Peer, Server, User Manufacturer, Owner, Peer, Server, User
* Initial beliefs assumed in the device: * Initial beliefs assumed in the device:
* Processes: * Processes:
* Beliefs imparted to the device after protocol execution: * Beliefs imparted to the device after protocol execution:
2.11. LPWAN 2.10. 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].
skipping to change at page 14, line 5 skipping to change at page 14, line 5
* Players: Administrator, Authenticator, Border Router, Client, * Players: Administrator, Authenticator, Border Router, Client,
Device, Manager, Network Server, User Device, Manager, Network Server, User
* Initial beliefs assumed in the device: * Initial beliefs assumed in the device:
* Processes: * Processes:
* Beliefs imparted to the device after protocol execution: * Beliefs imparted to the device after protocol execution:
2.12. Thread 2.11. 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
skipping to change at page 15, line 23 skipping to change at page 15, line 23
certificates available for starting enrollment. Provisioning/ certificates available for starting enrollment. Provisioning/
configuring are terms used for providing additional information to configuring are terms used for providing additional information to
devices before they are fully operational. For example, credentials devices before they are fully operational. For example, credentials
are provisioned onto the device. But before credential provisioning, are provisioned onto the device. But before credential provisioning,
a device is bootstrapped and authenticated. Some protocols may only a device is bootstrapped and authenticated. Some protocols may only
deal with parts of the process. For example, TLS maybe used for deal with parts of the process. For example, TLS maybe used for
authentication after bootstrapping. A separate device management authentication after bootstrapping. A separate device management
protocol then may run over this TLS tunnel for provisioning protocol then may run over this TLS tunnel for provisioning
operational information and credentials. operational information and credentials.
4. Comparison of terminology 3.1. Comparison of terminology
5. Comparison of players 3.2. Comparison of players
6. Comparison of initial beliefs 3.3. Comparison of initial beliefs
7. Comparison of processes 3.4. Comparison of processes
8. Comparison of knowledge imparted to the device 3.5. Comparison of knowledge imparted to the device
9. Security Considerations 4. 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
skipping to change at page 16, line 21 skipping to change at page 16, line 21
or automatically over the network. 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.
10. IANA Considerations 5. IANA Considerations
There are no IANA considerations for this document. There are no IANA considerations for this document.
11. Acknowledgements 6. 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.
12. Informative References 7. Informative References
[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] Fast Identity Online Alliance, "FIDO Device Onboard [fidospec] Fast Identity Online Alliance, "FIDO Device Onboard
Specification", Fido Alliance Version: 1.0, March 2021, Specification", Fido Alliance Version: 1.0, March 2021,
<https://fidoalliance.org/specifications/download-iot- <https://fidoalliance.org/specifications/download-iot-
skipping to change at page 17, line 8 skipping to change at page 17, line 8
[I-D.ietf-ace-coap-est] [I-D.ietf-ace-coap-est]
Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S.
Raza, "EST over secure CoAP (EST-coaps)", Work in Raza, "EST over secure CoAP (EST-coaps)", Work in
Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6
January 2020, <https://www.ietf.org/archive/id/draft-ietf- January 2020, <https://www.ietf.org/archive/id/draft-ietf-
ace-coap-est-18.txt>. ace-coap-est-18.txt>.
[I-D.ietf-ace-wg-coap-eap] [I-D.ietf-ace-wg-coap-eap]
Marin-Lopez, R. and D. Garcia-Carrillo, "EAP-based Marin-Lopez, R. and D. Garcia-Carrillo, "EAP-based
Authentication Service for CoAP", Work in Progress, Authentication Service for CoAP", Work in Progress,
Internet-Draft, draft-ietf-ace-wg-coap-eap-03, 26 July Internet-Draft, draft-ietf-ace-wg-coap-eap-06, 7 December
2021, <https://www.ietf.org/archive/id/draft-ietf-ace-wg- 2021, <https://www.ietf.org/archive/id/draft-ietf-ace-wg-
coap-eap-03.txt>. coap-eap-06.txt>.
[I-D.ietf-emu-eap-noob]
Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band
authentication for EAP (EAP-NOOB)", Work in Progress,
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]
Mattsson, J. P. and M. Sethi, "Using EAP-TLS with TLS 1.3
(EAP-TLS 1.3)", Work in Progress, Internet-Draft, draft-
ietf-emu-eap-tls13-21, 20 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-emu-eap-
tls13-21.txt>.
[I-D.oflynn-core-bootstrapping]
Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security
Bootstrapping of Resource-Constrained Devices", Work in
Progress, Internet-Draft, draft-oflynn-core-bootstrapping-
03, 7 November 2010, <https://www.ietf.org/archive/id/
draft-oflynn-core-bootstrapping-03.txt>.
[I-D.sethi-gba-constrained]
Sethi, M., Lehtovirta, V., and P. Salmela, "Using Generic
Bootstrapping Architecture with Constrained Devices", Work
in Progress, Internet-Draft, draft-sethi-gba-constrained-
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>.
[LoRaWAN] LoRa Alliance, "LoRa Specification V1.1", LoRa [LoRaWAN] LoRa Alliance, "LoRa Specification V1.1", LoRa
Alliance Version: 1.1, October 2017, <https://lora- Alliance Version: 1.1, October 2017, <https://lora-
alliance.org/resource_hub/lorawan-specification-v1-1/>. alliance.org/resource_hub/lorawan-specification-v1-1/>.
skipping to change at page 20, line 42 skipping to change at page 20, line 15
[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>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>. May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
Authentication for EAP (EAP-NOOB)", RFC 9140,
DOI 10.17487/RFC9140, December 2021,
<https://www.rfc-editor.org/info/rfc9140>.
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>.
[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-
skipping to change at page 21, line 23 skipping to change at page 20, line 50
Thread Group, "Thread Commissioning", 2015. Thread Group, "Thread Commissioning", 2015.
[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.
Authors' Addresses Authors' Addresses
Mohit Sethi Mohit Sethi
Ericsson Aalto University
Hirsalantie 11 FI-02150 Espoo
FI-02420 Jorvas
Finland Finland
Email: mohit@iki.fi
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
33207 Oviedo 33207 Oviedo
Spain Spain
Email: garciadan@uniovi.es Email: garciadan@uniovi.es
 End of changes. 34 change blocks. 
93 lines changed or deleted 67 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/