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