Internet-Draft | RFF ACCESS | February 2022 |
Fang, et al. | Expires 21 August 2022 | [Page] |
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.¶
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].¶
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.¶
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.¶
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 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.¶
IoT Device Access Gateway¶
Trust Center¶
Lower Computer¶
CSMA/CD¶
ASCII¶
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 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.¶
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.¶
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 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:¶
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 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.¶
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.¶
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.¶
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:¶
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.¶
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.¶
Code¶
Identifier¶
Length¶
Response Authenticator¶
Attributes¶
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.¶
This document includes no request to IANA.¶
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.¶