Network Working Group D. von Hugo Internet-Draft Deutsche Telekom Intended status: Standards Track B. Sarikaya Expires: 8 May 2023 4 November 2022 The Need for New Authentication Methods for Internet of Things draft-hsothers-iotsens-ps-03.txt Abstract In framework of future 6G the need for easy and secure connectivity between a great amount of small devices as sensors and household appliances will be essential. Such massive Internet of Things (mIoT) requires authentication methods which are reliable also in case of vulnerable wireless links and work for simple cheap (dumb) devices. Aim of this document is to lay ground for the need for new authentication models and admission methods in the framework of devices (e.g., machines in IoT communication) within a (wireless or wireline-based) network. Simple devices may only have a minimum amount of physical interfaces available. As an example for establishing an out-of-band channel for exchange of authentication material radio sensing technology may serve. This is currently under investigation for Wireless LAN and upcoming cellular radio at both IEEE and 3GPP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 May 2023. von Hugo & Sarikaya Expires 8 May 2023 [Page 1]
Internet-Draft The Need for IoT Authentication November 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. 3GPP and Wireless LAN Sensing . . . . . . . . . . . . . . . . 4 4. IoT Authentication Issues . . . . . . . . . . . . . . . . . . 4 4.1. General Considerations and Requirements . . . . . . . . . 5 4.2. Exemplary Protocols for IoT Authentication . . . . . . . 5 4.3. Assessment of Existing Authentication Methods . . . . . . 6 5. The Need for New Authentication Models . . . . . . . . . . . 7 5.1. Out-of Band Channel for Device Provisioning . . . . . . . 7 5.2. The Gaps . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Future networking to make full use of 5G capabilities or even resembling an evolution to beyond 5G will have to exploit a much more heterogeneous environment in terms of network and device connectivity technologies and applications. In addition, ease of use for customers and an as far as possible human-independent (autonomous) operation of a multitude of devices and machines (things) should be enabled. Basic pre-requisite for flawless operation of any communication service is secure and safe access to the network. Both the device and the network infrastructure have to authenticate each other during von Hugo & Sarikaya Expires 8 May 2023 [Page 2]
Internet-Draft The Need for IoT Authentication November 2022 the bootstrapping process, which starts when the device is switched into operational status. Depending on the specific access technology or family of technology variants multiple authentication methods have been developed and deployed. Regarding the aspect of ease of use and in view of the upcoming use case of massive Internet of Things (mIoT) with huge amounts of cheap und thus very simple devices many of the existing authentication methods will not be optimal here. E.g., authentication models like 802.1X [IEEE802.1X] are based on human intervention and do not scale well for mIoT. Same holds true similarly for 3GPP authentication, where user equipment (UE) has to be equipped with a USIM (Universal Subscriber Identity Module) to access a cellular network and the user has to provide a secret key, i.e., PIN (Personal Identification Number). Also such approach requires exchange of information on the communication channel in advance of the authentication and identification and thus could result in security issues. To overcome those issues and lower the risk higher levels of admission methods need a second (or out-of-band, OOB) channel to communicate with the device for authentication. Provision of at least two independent channels would allow for and be part of the Multi- or Two-Factor Authentication (MFA/TFA/2FA) required for security in high-risk scenarios. Device Provisioning Protocol (DPP) developed by Wi-Fi Alliance makes use of an out-of band channel beside the Wi-Fi interface for bootstrapping and authentication [dpp]. Thus another (trusted) device such as a mobile phone can be employed to exchange essential data via, e.g., Bluetooth or Near-Field Communications (NFC). Also visible (QR code or blinking LED) or audible (melody, human speech) information can be used via a smart phone's built-in camera or microphone, assuming that advances in signal processing may make it possible to realize these and similar use cases. More examples are mentioned in [Henning]. However, this approach requires again human intervention and/or a second interface both at the 'dumb' device and at the point of attachment to the network (e.g., Wi-Fi access point). An alternative may be to use the single radio interface in terms of sensing the signal strength and temporal and geographical change of the signal pattern as has been investigated by IEEE and 3GPP: IEEE802.11 has a project on Wireless LAN (WLAN sensing) and 802.11bf task group (TG) is in charge of this project [BFSFD]. 3GPP is studying for Rel. 19 the topic of Integrated Sensing and Communication [TR22.837]. More discussion on radio sensing can be found in Section 3. von Hugo & Sarikaya Expires 8 May 2023 [Page 3]
Internet-Draft The Need for IoT Authentication November 2022 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 3GPP and Wireless LAN Sensing 3GPP document [TR22.837] defines many use cases that vary from indoor using 3GPP signal measured by UE to outdoor using 3GPP signal measured at the Base Stations. Use cases include intruder detection in smart home, pedestrian or animal intrusion detection on a highway, rainfall monitoring, flooding in smart cities, Automated Guided Vehicles (AGVs) detection and tracking in smart factories. It is foreseen that operators will define sensing area whereby the Base Stations and UEs can be used in sensing the characteristics of an airborne object of interest generating and reporting sensing measurement data (e.g., related to an unmanned aerial vehicle (UAV) position, velocity) to a 5G sensing processing entity. IEEE 802.11 Wireless LAN sensing being developed by TGbf is based on obtaining physical Channel State Information (CSI) measurements between a transmitter and receiver WLAN nodes. Using these measurements, presence of obstacles between a transmitter and receiver can be detected and tracked. This way, using feature extraction and classification of artificial intelligence (AI), more higher level tasks like human activity recognition and object detection may become available for authentication purposes. In addition to already proposed use cases as room sensing, i.e., presence detection, gesture recognition, or building a 3D picture of an environment also the unambiguous identification of an IoT device or the owner of that device could be achieved. Wireless sensing technologies such as New Radio (NR)-based sensing and WLAN sensing aim at acquiring information about a remote object while the corresponding perception data can be utilized for analysis to obtain meaningful information. Here use cases on combining sensor data with other (e.g., location) and transparent sensing as well as protection of sensing information may be adapted to provide information usable for IoT device authentication. 4. IoT Authentication Issues von Hugo & Sarikaya Expires 8 May 2023 [Page 4]
Internet-Draft The Need for IoT Authentication November 2022 4.1. General Considerations and Requirements IoT applications may cover a broad range of domains from smart cities, industry, and homes to personal (e.g., wearable) devices, and can reach a huge number of entities. Since applications as e-health and connection to critical infrastructure may be included, the security requirements in terms of preventing unauthorized access are very high. Therefore very robust authentication mechanisms have to be applied. At the same time depending on the specific scenario a trade-off between resources as processing power and memory as driven by security protocol complexity has to be considered. Therefore it should be possible for the owner to flexibly choose and subsequently agree with the authentication system on the method to authenticate a device and the correspondingly required set of characteristic parameters. Consideration of the amount and type of resources as well as their location and availability will play a role: E.g., whether these resources are provided either within the local system components (e.g., the device itself and the point of attachment or access point) and/or within the network infrastructure (e.g., an edge cloud instance or a central data base). The result of the detection process (e.g., radio wave analysis outcome as parameters as modulation scheme, number of carriers, and fingerprinting or QR code detection) has to be compared with the required (correct) reference parameter values which are safely and confidentially stored within the network. On all levels of handling these data, i.e., storage, processing, and transport via a communication network, the integrity of the content has to be preserved. One should keep in mind, that any unintended authentication request should be prevented to minimize the risk of occasional attachment of malicious users to networks and subsequent exposure of sensitive user data. [RFC8576] serves as a reference for additional details about IoT specific security considerations including the area of authentication and documents their security challenges, threat models, and possible mitigations. 4.2. Exemplary Protocols for IoT Authentication OAuth [RFC6749] protocol extends traditional client-server authentication by providing a third party with a token. Since such token resembles a different set of credentials compared to those of the resource owner, the device needs not be allowed to use the resource owner's credentials to access protected resources. In addition [RFC8628] specifies how to complete the authorization request of a device with a one-way channel via a secondary device, von Hugo & Sarikaya Expires 8 May 2023 [Page 5]
Internet-Draft The Need for IoT Authentication November 2022 such as a smartphone. Task of a Public Key Infrastructure (PKI) with its various components (authorities) is to manage (including generation, distribution, operational usage, secure storage as well as revocation) certificates (e.g., of type X.509) to enable authentication and identification of IoT devices. The role of an IoT client to communicate with PKI system may be played by the local access point which usually has corresponding processing capabilities rather than the simple and cheap IoT devices. In case of manufacturer-installed X.509 certificates the 'Bootstrapping Remote Secure Key Infrastructure' (BRSKI) protocol [RFC8995] provides means for authentication both devices and the network and specifies a Secure Key Infrastructure (SKI) for bootstrapping. EAP (Extensible Authentication Protocol) [RFC3748] defines a flexible authentication framework for network access of a peer towards an authenticator or authentication server. Advantage of EAP for IoT is the support of multiple authentication mechanisms without need for pre-negotiation. Recently, Nimble out-of-band authentication for EAP or EAP-NOOB [RFC9140] was proposed to apply EAP to very simple IoT devices. Here, the need for pre-established (e.g., manufacturer provided certificate) relation with server or user or pre- provisioning of identifier or credentials could be avoided. For sake of security they need, however, a second interface for out-of-band communication. This OOB channel enables the device to send critical data needed, i.e., a secret nonce to EAP server. In addition, EAP ecosystem may be too complex for simple IoT devices and EAP-NOOB would require user assistance in message exchange for authenticating in-band key exchange. Therefore a more simple approach should be envisioned. 4.3. Assessment of Existing Authentication Methods In view of the above mentioned methods using out-of band channel for IoT authentication the advantage of a mechanism relying on radio sensing may have the advantage not to need explicit user interaction. Beside it does not require the user to know any key, identifier, or password for the IoT device to be authenticated. For other OOB technics the need for a pre-defined means of identifying the device (e.g., physical, acoustic, photographic or video representation, unique description in terms of parameters, etc.) may be the only prerequisite for authentication. In addition, in case of radio sensing no other interface at the IoT device would be required beyond the radio interface which can be used for both, communication and the OOB transmission of the identity and unique token. von Hugo & Sarikaya Expires 8 May 2023 [Page 6]
Internet-Draft The Need for IoT Authentication November 2022 5. The Need for New Authentication Models We solicit future work on the out-of band channels for device provisioning and the gaps identified below. 5.1. Out-of Band Channel for Device Provisioning The newly to be designed authentication model for IoT devices shall be applicable to OOB transmission of a certificate to the authenticating entity as via, e.g., above mentioned radio sensing. However, other means to exchange the essential information may also be chosen such as detection by touch, accelerometer, and gyro sensors or cameras. LED (Light Emitting Diode) using LED light indicator and/or emitter available on the device can support LED light based authentication, e.g., via a smartphone with a client for certification. Experiments on such an approach have been set up and tested during lighthouse project (see, e.g., [Lins18], [Oden18]). Criteria for choice of the corresponding technology depend on the use case and cover are reliable operation (working), scalability, ease of use and convenience, security, and many more. The created token or signature (fingerprint) shall serve in a similar way as a password [Wang3] to allow the detection and authentication of the device by comparison with pre-shared and stored information. Bluetooth Mesh Network standard for Bluetooth low energy (BLE) wireless technology [simpleconn] defines Output OOB and Input OOB authentication methods between a device and the provisioner, e.g., an access point. In case of Output OOB, the unprovisioned device picks a random number and outputs that number in a way which is explained next. For example, if the unprovisioned device is a light bulb, it could blink a given number of times. If the device has an LCD screen, it could show the random number as a multiple digit value. The user of the provisioner inputs the number observed to authenticate the unprovisioned device. After the random number has been input, the provisioner generates and checks a confirmation value. The check confirmation value operation is identical within the overall authentication step, regardless of the authentication method used. In case of Input OOB, the provisioner generates a random number, displays it, and then prompts the user to input the random number into the unprovisioned device using an appropriate action. For instance, a light switch may allow the user to input the random number by pressing a button an appropriate number of times within a certain period. After finishing the authentication action, the von Hugo & Sarikaya Expires 8 May 2023 [Page 7]
Internet-Draft The Need for IoT Authentication November 2022 unprovisioned device sends a Provisioning Input Complete PDU to the provisioner to inform it that the random number has been input. The process continues with the check confirmation value operation like in the case of Output OOB [simpleconn]. For use of 3GPP and Wireless LAN sensing as an OOB channel in IoT authentication, most possibly output OOB channel needs to be investigated. Since input OOB requires user interaction the use of radio sensing as an input OOB channel should not be the approach to be chosen. 5.2. The Gaps Main gap between existing methods and the new authentication model to be derived is the required user interaction. Another challenge may be naming and re-naming of the devices to enable re-using (e.g., home appliances after moving to a new flat) or replacement (e.g., of a broken light bulb by a new one). For this either use of geo- locational parameters or time stamps with respect to, e.g., time of production or first installation (deployment or start of operation) may be considered. The automatic exchange of the old identity with the new one during re-booting may demand for a standard geospatial naming. Aim of this document is to stimulate discussion on future directions in work at IETF towards secure and confident authentication of IoT devices to the network, independent of the access technology and the features of the IoT device. 6. IANA Considerations This document makes no request to IANA for allocation of new registries. 7. Security Considerations This document raises no new security concerns but tries to identify how to increase security in future IoT by discussing the issues of robust but easy to apply authentication mechanisms. 8. Acknowledgements Discussions with Jan Janak, Henning Schulzrinne, and Michael Richardson as well as a review by Janfred Rieckers and Jari Arkko helped us improve the draft. 9. References von Hugo & Sarikaya Expires 8 May 2023 [Page 8]
Internet-Draft The Need for IoT Authentication November 2022 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 9.2. Informative References [BFSFD] IEEE, "Institute of Electrical and Electronics Engineers, IEEE P802.11 - TASK GROUP BF (WLAN SENSING) 11-21/0504r2 "Specification Framework for TGbf"", July 2021. [dpp] Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol (DPP)", Wi-Fi Alliance Specification version 1.1, 2018, <https://www.wi- fi.org/download.php?file=/sites/default/files/private/ Device_Provisioning_Protocol_Specification_v1.1_1.pdf>. [Henning] Schulzrinne, H., "Do We Still Need Wi-Fi in the Era of 5G (and 6G)?", February 2021. [I-D.irtf-t2trg-secure-bootstrapping-02] Sethi, M., Sarikaya, B., and D. Garcia-Carrillo, "Terminology and processes for initial security setup of IoT devices", Work in Progress, Internet-Draft, draft- irtf-t2trg-secure-bootstrapping-02, 25 April 2022, <https://www.ietf.org/archive/id/draft-irtf-t2trg-secure- bootstrapping-02.txt>. [IEEE802.1X] IEEE, "Institute of Electrical and Electronics Engineers, "802.1X - Port Based Network Access Control"", January 2020. [Lins18] Linssen, A., "Secure Authentication of Remote IoT Devices Using Visible Light Communication: Transmitter Design and Implementation", Columbia University , 2018, <https://www.cs.columbia.edu/~hgs/papers/ Lins18_Secure.pdf>. von Hugo & Sarikaya Expires 8 May 2023 [Page 9]
Internet-Draft The Need for IoT Authentication November 2022 [Oden18] Odental, H., "Secure Authentication of Remote IoT Devices Using Visible Light Communication: Receiver Design and Implementation", Columbia University , 2018, <https://www.cs.columbia.edu/~hgs/papers/ Oden18_Secure.pdf>. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>. [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>. [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of Things (IoT) Security: State of the Art and Challenges", RFC 8576, DOI 10.17487/RFC8576, April 2019, <https://www.rfc-editor.org/info/rfc8576>. [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, <https://www.rfc-editor.org/info/rfc8628>. [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An Autonomic Control Plane (ACP)", RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>. [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/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>. [simpleconn] Bluetooth Special Interest Group, "Mesh Profile", Version 1.0.1, 2019, <https://www.bluetooth.com/specifications/specs/mesh- profile-1-0-1/>. [TR22.837] 3GPP Draft Technical Report Release 19, "3GPP, "Study on Integrated Sensing and Communication"", 2022. von Hugo & Sarikaya Expires 8 May 2023 [Page 10]
Internet-Draft The Need for IoT Authentication November 2022 [Wang3] Wang, H., Lymberopoulos, D., and J. Liu, "Sensor-Based User Authentication", EWSN 2015, LNCS 8965, 168 , 2015. Acknowledgements Authors' Addresses Dirk von Hugo Deutsche Telekom Deutsche-Telekom-Allee 9 64295 Darmstadt Germany Email: Dirk.von-Hugo@telekom.de Behcet Sarikaya Email: sarikaya@ieee.org von Hugo & Sarikaya Expires 8 May 2023 [Page 11]