Internet DRAFT - draft-dawei-access-authentication-physical-layer
draft-dawei-access-authentication-physical-layer
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,
<https://www.rfc-editor.org/info/rfc2119>.
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,
<http://www.ietf.org/internet-drafts/draft-linning-
authentication-physical-layer-00.txt>.
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,
<https://www.rfc-editor.org/info/rfc2865>.
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]
