Southeast University D. Fang Internet-Draft A. Hu Intended status: Standards Track H. Fu Expires: 21 August 2022 Y. Jiang Southeast University 17 February 2022 IoT Access Authentication Framework based on Radio Frequency Fingerprint and Fingerprint Expression Specification draft-dawei-access-authentication-physical-layer-00 Abstract This document specifies the uniform expression and format of different kinds of wireless radio frequency fingerprints. It also specifies the structure and functions of wireless authentication framework on fingerprints, including the specification of the signal frames' structure. This document is applicable to the construction and management of secure access at the edge of the Internet of things. This document assumes that the reader is familiar with some concepts and details regarding physical layer security. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 21 August 2022. Fang, et al. Expires 21 August 2022 [Page 1] Internet-Draft RFF ACCESS February 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. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RF Fingerprint Access Control Framework . . . . . . . . . . . 3 4. Specification of Basic Functions of Access Control Framework . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Specification of Fingerprint Expression . . . . . . . . . . . 7 5.1. Common RF Fingerprint Types . . . . . . . . . . . . . . . 7 5.2. Specification of Expression Format . . . . . . . . . . . 7 5.3. Specification of Fingerprint Compression Coding . . . . . 8 6. Specification of Control Message in Framework . . . . . . . . 8 6.1. RFF Access Message Format . . . . . . . . . . . . . . . . 8 6.2. Attributes Format . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The classical device-authentication methods includes MAC address, pre-shared key. However, the MAC address is easy to be imitated. Radio frequency fingerprint (RFF) is a physical layer inherent characteristic for a device. Utilizing the RFF for terminal access control, it is possible to realize identity authentication by received waveforms. Some RFF features can be used for classification and identification. Different kinds of RFF extraction algorithms would generate features with different expressions[I-D.linning-authentication-physical-layer]. Hybrid Fang, et al. Expires 21 August 2022 [Page 2] Internet-Draft RFF ACCESS February 2022 features would be used to improve identification relability in practical use.So The wireless access control system based on RFF must support different kinds of fingerprint expressions and be compatible with the existing authentication framework. Besides uniforming the RFF expressions could make the framework suitable for a variety of IoT devices. As a new authentication key, RF fingerprint is incorporated into the access control system. This requires the unified expression format, coding, control signal frame, status code and other specifications of fingerprint. 2. Glossary IoT Device Access Gateway A device works for network connection, control and management, which deployed at the boundary between the perception layer and the network layer of the Internet of things. It realize the communication between the Internet of things devices and the network layer. Trust Center A special IoT device responsible for authenticating the legitimacy of devices and distributing communication keys in a IoT network. Lower Computer A computer that directly controls the hardware to obtain the condition of other devices or command them. CSMA/CD Carrier Sense Multiple Access with Collision Detection ASCII American Standard Code for Information Interchange 3. RF Fingerprint Access Control Framework RF fingerprint access control framework uses RF fingerprint as the authentication token for access. It is different from the traditional authentication mode which depends on the pair of MAC address and secure key. It substitutes the secure key with RF fingerprint. When a new network device requests access, if its MAC address is illegal, the access framework will directly reject it. If its MAC address is legal, it will then be judged whether its fingerprint matches its MAC address. If not, it will be considered Fang, et al. Expires 21 August 2022 [Page 3] Internet-Draft RFF ACCESS February 2022 as an illegal and disguised device with a fake MAC address. Limited to the weak computing ability of IoT edge devices and the requirement of RF fingerprint extraction algorithm, the access control framework adopts a three-party authentication model. It includes the claimant, relying party, the verifier, and the relationships among them is shown in Figure 1. The claimant refers to the IoT device requesting access to the network. The relying party refers to the nodes which is responsible for access control in the IoT network, such as the central node device or the lower computer of the IP interface. The verifier refers to a trusted third party for RF fingerprint extraction and identification. The verifier and the relying party can be the same entity. +-------------------+ +-------------------+ | Claimant | <----------> | relying party | +-------------------+ +-------------------+ ^ ^ | | | | | | | | | v | +-------------------+ +-----------------------> | verifier | +-------------------+ Figure 1: Authentication Model Figure 2 shows the network architecture after deploying the network model of Figure 1. The RF fingerprint wireless access control system mainly includes physical layer equipment access gateways, authentication servers, proxy servers, signal collectors, etc. The relying party is an entrance gateway of the IP network, or the trust center which is a special device in an IoT network. Therefore, the communication between the relying party and the proxy server requires an appropriate interface. The black and white list of the system is stored in the authentication server. Fang, et al. Expires 21 August 2022 [Page 4] Internet-Draft RFF ACCESS February 2022 +-------------+ +---------------+ +----------------+ | New Device | | Intermediate | | PHY Gateway | | (Claimant) |<----->| Device Node |<----->| /Trust Center | | | | | | (Relying Party)| +-------------+ +---------------+ +----------------+ ^ | ^ | | | | 1.request| |4.result | Trusted Environment | | | +-------------------------------------------+--------+ | | | | | | | v | | | | +---------------+ 2.request with RFF +------------+| | | |Authentication | <-------------- | Proxy || | | | Server | --------------> | (extract || | | +---------------+ 3.result | feature) || | | +------------+| | | | ^ | | | | | | | | v | | | | +---------------+ | +----+--------------------------------> | Signal | | | | Collector | | | +---------------+ | | | +----------------------------------------------------+ Figure 2: RFF Access Control Model Detailed access process is described as follows. When a new device applies to join a network, it should firstly establish a connection to parent node. The IP address of the new device is preseted or assigned by its parent node before authenticattion. After the preliminary connection is established, the parent node sends an authentication request, which carries the MAC address of the new device, to the relying party. The relying party sends an authentication request to the proxy server, and the proxy server uses the analog signals received from the new device to extract. Then the proxy server sends a request frame containing the fingerprint to the authentication server. The signal collector usually keeps monitoring the entire system. Since the wireless network device adopts the CSMA/CD strategy for sending signals, the request frame for joining a network would be captured by the signal collector in real time. Sampling data is already stored in the proxy server before the relying party requests authentication. If the proxy server does not capture the claimant's connection request signal, it will return a status code, ?no Fang, et al. Expires 21 August 2022 [Page 5] Internet-Draft RFF ACCESS February 2022 fingerprint collected?, to the relying party. Therefore, there are three kinds of status code for authentication: legal, illegal and no fingerprint collected. The relying party executes access control according to the authentication status code, such that: * Legal Assign communication keys to allow new nodes to join the network. * Illegal Do not assign keys to the new node and send a control frame to block the illegal device. * No Fingerprint Collected Send the control frame to ask the new node to resubmit the authentication request. 4. Specification of Basic Functions of Access Control Framework The certification service of the verifier shall be independent and impartial, and its authentication results should help to establish a trust relationship between the application system and new IoT device. The IoT device application layer protocol should provide specific signaling and functional processes for access control framework. Specifically: * The connection process between the new device and its parent node should be split into two parts: connection establishment and authentication. After the connection is established, the new device uses its MAC address to request authentication. The communication key can only be obtained after the judgment is legal. * Authentication status code should contain at least 3 types: legal, illegal, no fingerprint collected. * The gateway or trust center should be able to respond to the authentication result from the proxy server when it does not actively apply a connection request. That is, the verifier can check the legitimacy of the devices in the network at any time. Fang, et al. Expires 21 August 2022 [Page 6] Internet-Draft RFF ACCESS February 2022 The verifier needs to be in a secure and trusted environment. For example, proxy servers, authentication servers, and signal collectors are deployed in a security intranet. All communication interfaces in the framework should be reliable. The relying party and the authenticating party should adopt encrypted communication mode, using an independent, preset session key. The access authentication framework does not specify the fingerprint extraction method and authentication mechanism, and has nothing to do with the signal protocol type of the IoT devices. But all kinds of fingerprints should have a unified expression form. 5. Specification of Fingerprint Expression 5.1. Common RF Fingerprint Types RF fingerprints mainly include frequency offset, phase offset, power spectral density, adaptive filter coefficients, differential constellation, etc. They could be mainly divided into two types: graphics and numerical values, both of which can be transformed into a one-dimensional vector. According to the type of IoT device and the type of communication protocol, the identification algorithm adopts single or multiple RFF features. Fingerprint identification algorithm classifies and identifies the devices through the differences among feature vectors. Features of one device is stable and similar in different time. Differences of features among different devices are obvious and easy to classify. 5.2. Specification of Expression Format RF fingerprint is expressed as a one-dimensional vector including no more than 30 elements. If it exceeds 30 elements, feature dimension reduction is required. For features that cannot be reduced to less than 30 elements, feature segmentation and packet transmission shall be carried out. The one-dimensional RFF feature vector shall fully reflect the fingerprint characteristics of the devices. The feature vector of the same device shall remain relatively stable, while the feature vectors of different devices shall maintain distinguishable differences. Fang, et al. Expires 21 August 2022 [Page 7] Internet-Draft RFF ACCESS February 2022 5.3. Specification of Fingerprint Compression Coding The original fingerprint vector dimension is less than 30 dimensions, and the data storage form is floating point or integer. The compression coding process is presented as follows: * Normalize the fingerprint vector , scale the numerical value in (- 1,1). * For each one-dimensional vector, convert it to binary decimal and 24 significant digits are reserved. The first bit is the sign bit. The sign bit 0 indicates that the value is positive and 1 indicates that the value is negative. * The 64 symbols 48 ~ 90 and 97 ~ 117 in the ASCII code table are used as the mapping table. The 24 bit binary is grouped into 4 groups according to 6 bits. Convert every 6-bit binary decimal to 1-bit 64 decimal. Then map the 64-decimal symbol to an ASCII symbol according to the index. Thus, each one-dimensional data coding dimension is decoded by 4 ASCII symbols. * Convert all dimensions of all vectors to ASCII symbols and splice them into strings. The string length is less than or equal to 120 characteristics. This string is the fingerprint formal expression. 6. Specification of Control Message in Framework The control message is compatible with radius protocol, in which attributes, functions and maximum length are in accordance with radius protocol. The control message is compatible with RADIUS protocolRFC 2865 [RFC2865], in which attributes, functions and maximum length are in accordance with radius protocol. 6.1. RFF Access Message Format The message format shall at least contain five fields: frame type, identifier, frame length, authenticator and attribute. The detailed description is shown in Figure 3. Fang, et al. Expires 21 August 2022 [Page 8] Internet-Draft RFF ACCESS February 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Respones Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 3: RFF Access Message Format Code Describe the type of message. 1 indicates access request message, while 2 indicates access accept message. Identifier Identify the message serial number, which is used to match the request message and response message, and detect the request message retransmitted within a period of time. Length The length of access control message. Bytes exceeding the length value are ignored as padding characters. If the actual length of the received message is less than the value of length, the message will be discarded. Response Authenticator Verify the response message of servers. Authenticator in the request message is a random number, followed by MD5 of shared key and random number. Attributes The Attribute field is variable in length. It is the content body of the message. attributes is encoded in Type/Length/Value triplets. Fang, et al. Expires 21 August 2022 [Page 9] Internet-Draft RFF ACCESS February 2022 6.2. Attributes Format The Attribute for RFF access control is specified from atrributes in RADIUS. It only needs one attribute. In a triplet,the first element is the MAC address of the new device,which is a fixed length for devices of one kind. The second element is the length of the triplet. The third element is the encoded fingerprint. Figure 4 shows the structure of the attribute. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC address | Length | Fingerprint | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Atrribute Format 7. IANA Considerations This document includes no request to IANA. 8. Security Considerations This section will address only security considerations associated with the use of RF fingerprint access control framework. Encrypted communication is required when the access control message is transmitted between the IoT trust center and the third-party server. If the third party is not credible, the access system loses credibility. Therefore, it is necessary to ensure that the relying party and the verifier are in a secure and trusted environment. 9. References 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, . 9.2. Informative References [I-D.linning-authentication-physical-layer] Peng, L. and A. Hu, "Authentication by Physical Layer Features", Work in Progress, Internet-Draft, draft- linning-authentication-physical-layer-00, 8 October 2018, . Fang, et al. Expires 21 August 2022 [Page 10] Internet-Draft RFF ACCESS February 2022 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . Authors' Addresses Dawei Fang Southeast University No.2 SiPaiLou Nanjing JiangSu, 210096 China Email: dweifang@seu.edu.cn Aiqun Hu Southeast University No.2 SiPaiLou Nanjing JiangSu, 210096 China Email: aqhu@seu.edu.cn Hua Fu Southeast University No.2 SiPaiLou Nanjing JiangSu, 210096 China Email: hfu@seu.edu.cn Yu Jiang Southeast University No.2 SiPaiLou Nanjing JiangSu, 210096 China Email: jiangyu@seu.edu.cn Fang, et al. Expires 21 August 2022 [Page 11]