<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200902" docName="draft-dawei-access-authentication-physical-layer-00" category="std">
 <front>
  <title abbrev="RFF ACCESS">IoT Access Authentication Framework
 	based on Radio Frequency Fingerprint and Fingerprint Expression Specification</title>
  <author fullname="Dawei Fang" initials="D" surname="Fang">
   <organization>Southeast University
</organization>
   <address>
    <postal>
     <street>No.2 SiPaiLou
</street>
     <city>Nanjing

</city>
     <region>JiangSu</region>
     <code>210096</code>
     <country>China</country>
    </postal>
    <email>dweifang@seu.edu.cn</email>
   </address>
  </author>
  <author fullname="Aiqun Hu" initials="A" surname="Hu">
   <organization>Southeast University
</organization>
   <address>
    <postal>
     <street>No.2 SiPaiLou
</street>
     <city>Nanjing

</city>
     <region>JiangSu</region>
     <code>210096</code>
     <country>China</country>
    </postal>
    <email>aqhu@seu.edu.cn</email>
   </address>
  </author>
  <author fullname="Hua Fu" initials="H" surname="Fu">
   <organization>Southeast University
</organization>
   <address>
    <postal>
     <street>No.2 SiPaiLou
</street>
     <city>Nanjing

</city>
     <region>JiangSu</region>
     <code>210096</code>
     <country>China</country>
    </postal>
    <email>hfu@seu.edu.cn</email>
   </address>
  </author>
  <author fullname="Yu Jiang" initials="Y" surname="Jiang">
   <organization>Southeast University
</organization>
   <address>
    <postal>
     <street>No.2 SiPaiLou
</street>
     <city>Nanjing

</city>
     <region>JiangSu</region>
     <code>210096</code>
     <country>China</country>
    </postal>
    <email>jiangyu@seu.edu.cn</email>
   </address>
  </author>
  <date day="17" month="February" year="2022"/>
  <workgroup>Southeast University</workgroup>
  <abstract>
   <t>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.</t>
  </abstract>
  <note title="Requirements Language">
   <t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
      &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
      document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
  </note>
 </front>
 <middle>
  <section title="Introduction" anchor="intro">
   <t>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.</t>
   <t>Some RFF features can be used for classification and identification. Different kinds of RFF extraction algorithms would generate features with different expressions<xref target="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.</t>
  </section>
  <section title="Glossary">
   <t>IoT Device Access Gateway<list style="empty">
     <t>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.</t>
    </list>
   </t>
   <t>Trust Center<list style="empty">
     <t>A special IoT device responsible for authenticating the legitimacy of devices and distributing communication keys in a IoT network.</t>
    </list>
   </t>
   <t>Lower Computer<list style="empty">
     <t>A computer that directly controls the hardware to obtain the condition of other devices or command them.</t>
    </list>
   </t>
   <t>CSMA/CD<list style="empty">
     <t>Carrier Sense Multiple Access with Collision Detection</t>
    </list>
   </t>
   <t>ASCII<list style="empty">
     <t>American Standard Code for Information Interchange</t>
    </list>
   </t>
  </section>
  <section title="RF Fingerprint Access Control Framework" anchor="RFF_Framework">
   <t>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. </t>
   <t/>
   <t>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 <xref target="Structure_figure"/>. 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.</t>
   <t>
    <figure anchor="Structure_figure" title="Authentication Model">
     <artwork>  +-------------------+              +-------------------+ 
  |     Claimant      | &lt;----------&gt; |   relying party   |
  +-------------------+              +-------------------+ 
           ^                                    ^
           |                                    |
           |                                    |
           |                                    |
           |                                    |
           |                                    v
           |                          +-------------------+ 
           +-----------------------&gt;  |     verifier      |
                                      +-------------------+ 

</artwork>
    </figure>
   </t>
   <t/>
   <t>
    <xref target="Deployed_figure"/> 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.</t>
   <t>
    <figure title="RFF Access Control Model" anchor="Deployed_figure">
     <artwork>  +-------------+       +---------------+       +----------------+ 
  | New Device  |       |  Intermediate |       |  PHY Gateway   |
  | (Claimant)  |&lt;-----&gt;|  Device Node  |&lt;-----&gt;| /Trust Center  |
  |             |       |               |       | (Relying Party)|
  +-------------+       +---------------+       +----------------+
      ^                                                |   ^
      |                                                |   |
      |                                       1.request|   |4.result
      |        Trusted Environment                     |   | 
      |    +-------------------------------------------+--------+
      |    |                                           |   |    |
      |    |                                           v   |    |
      |    | +---------------+ 2.request with RFF +------------+|
      |    | |Authentication | &lt;--------------    |    Proxy   ||
      |    | |    Server     |  --------------&gt;   |  (extract  ||                          
      |    | +---------------+   3.result         |   feature) || 
      |    |                                      +------------+|
      |    |                                           |  ^     |                      
      |    |                                           |  |     |
      |    |                                           v  |     |
      |    |                                  +---------------+ |
      +----+--------------------------------&gt; |     Signal    | |
           |                                  |    Collector  | |                                          
           |                                  +---------------+ |
           |                                                    |
           +----------------------------------------------------+</artwork>
    </figure>
   </t>
   <t>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.</t>
   <t>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.</t>
   <t>The relying party executes access control according to the authentication status code, such that:<list style="symbols">
     <t>Legal<list style="empty">
       <t>Assign communication keys to allow new nodes to join the network.</t>
      </list>
     </t>
     <t>Illegal<list style="empty">
       <t>Do not assign keys to the new node and send a control frame to block the illegal device.</t>
      </list>
     </t>
     <t>No Fingerprint Collected<list style="empty">
       <t>Send the control frame to ask the new node to resubmit the authentication request.</t>
      </list>
     </t>
    </list>
   </t>
  </section>
  <section anchor="Framework_Function" title="Specification of Basic Functions of Access Control Framework">
   <t>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.</t>
   <t>The IoT device application layer protocol should provide specific signaling and functional processes for access control framework. Specifically:<list style="symbols">
     <t>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.</t>
     <t>Authentication status code should contain at least 3 types: legal, illegal, no fingerprint collected.</t>
     <t>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.</t>
    </list>
   </t>
   <t>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.</t>
   <t>All communication interfaces in the framework should be reliable.</t>
   <t>The relying party and the authenticating party should adopt encrypted communication mode, using an independent, preset session key.</t>
   <t>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.</t>
  </section>
  <section anchor="Fingerprint_Expression" title="Specification of Fingerprint Expression">
   <section title="Common RF Fingerprint Types">
    <t>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.


</t>
   </section>
   <section title="Specification of Expression Format">
    <t>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.</t>
    <t>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.</t>
   </section>
   <section title="Specification of Fingerprint Compression Coding">
    <t>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:<list style="symbols">
      <t>Normalize the fingerprint vector , scale the numerical value in (- 1,1).</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
     </list>
    </t>
   </section>
  </section>
  <section anchor="Control_Message" title="Specification of Control Message in Framework">
   <t>The control message is compatible with radius protocol, in which attributes, functions and maximum length are in accordance with radius protocol.</t>
   <t>The control message is compatible with RADIUS protocol<xref target="RFC2865">RFC 2865</xref>, in which attributes, functions and maximum length are in accordance with radius protocol.</t>
   <section anchor="RFF_Message_Format" title="RFF Access Message Format">
    <t>The message format shall at least contain five fields: frame type, identifier, frame length, authenticator and attribute. The detailed description is shown in <xref target="RFF_Message_Format_figure"/>.</t>
    <t>
     <figure anchor="RFF_Message_Format_figure" title="RFF Access Message Format">
      <artwork>   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 ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-</artwork>
     </figure>
    </t>
    <t>Code<list style="empty">
      <t>Describe the type of message. 1 indicates access request message, while 2 indicates access accept message.</t>
     </list>
    </t>
    <t>Identifier<list style="empty">
      <t>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.</t>
     </list>
    </t>
    <t>Length<list style="empty">
      <t>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.</t>
     </list>
    </t>
    <t>Response Authenticator<list style="empty">
      <t>Verify the response message of servers. Authenticator in the request message is a random number, followed by MD5 of shared key and random number.</t>
     </list>
    </t>
    <t>Attributes<list style="empty">
      <t>The Attribute field is variable in length. It is the content body of the message. attributes is encoded in Type/Length/Value triplets.</t>
     </list>
    </t>
   </section>
   <section anchor="Attributes_format" title="Attributes Format">
    <t>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. <xref target="Attribute_Format_figure"/> shows the structure of the attribute.</t>
    <t>
     <figure anchor="Attribute_Format_figure" title="Atrribute Format">
      <artwork>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    MAC address    |   Length  |         Fingerprint           | 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
     </figure>
    </t>
   </section>
  </section>
  <section anchor="IANA" title="IANA Considerations">
   <t>This document includes no request to IANA.</t>
  </section>
  <section anchor="Security" title="Security Considerations">
   <t>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.</t>
  </section>
 </middle>
 <back>
  <references title="Normative References">
   <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?></references>
  <references title="Informative References">
   <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-linning-authentication-physical-layer-00.xml"?>
   <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"?></references>
 </back>
</rfc>
