<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-wang-secure-access-of-iot-terminals-05" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true">

<front>
<title abbrev="Secure Access of IoT Smart Terminals">Technical Requirements for Secure Access and Management of IoT Smart Terminals</title><seriesInfo value="draft-wang-secure-access-of-iot-terminals-05" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>
<author role="editor" initials="B." surname="Wang" fullname="Bin Wang"><organization>Hikvision</organization><address><postal><street>555 Qianmo Road, Binjiang District</street>
<city>Hangzhou</city>
<code>310051</code>
<country>CN</country>
</postal><phone>+86 571 8847 3644</phone>
<email>wbin2006@gmail.com</email>
</address></author>
<author role="editor" initials="S." surname="Liu" fullname="Song Liu"><organization>Hikvision</organization><address><postal><street>555 Qianmo Road, Binjiang District</street>
<city>Hangzhou</city>
<code>310051</code>
<country>CN</country>
</postal><phone>+86 571 8847 3644</phone>
<email>achelics@gmail.com</email>
</address></author>
<author role="editor" initials="L." surname="Wan" fullname="Li Wan"><organization>Hikvision</organization><address><postal><street>555 Qianmo Road, Binjiang District</street>
<city>Hangzhou</city>
<code>310051</code>
<country>CN</country>
</postal><phone>+86 571 8847 3644</phone>
<email>dzwanli@126.com</email>
</address></author>
<author role="editor" initials="J." surname="Li" fullname="Jun Li"><organization>CICS-CERT</organization><address><postal><street>No.35, Lugu Rd., Shijingshan Dist</street>
<city>Beijing</city>
<code>100040</code>
<country>CN</country>
</postal><email>lijun@cics-cert.org.cn</email>
</address></author>
<author role="editor" initials="X." surname="Wang" fullname="Xing Wang"><organization>Hikvision</organization><address><postal><street>555 Qianmo Road, Binjiang District</street>
<city>Hangzhou</city>
<code>310051</code>
<country>CN</country>
</postal><phone>+86 571 8847 3644</phone>
<email>xing.wang.email@gmail.com</email>
</address></author>
<author role="editor" initials="H.N." surname="Yan" fullname="HaoNan Yan"><organization>Hikvision</organization><address><postal><street>555 Qianmo Road, Binjiang District</street>
<city>Hangzhou</city>
<code>310051</code>
<country>CN</country>
</postal><phone>+86 571 8847 3644</phone>
<email>yanhaonan.sec@gmail.com</email>
</address></author>
<author role="editor" initials="Y.H." surname="Xie" fullname="Yinghui Xie"><organization>Hikvision</organization><address><postal><street>555 Qianmo Road, Binjiang District</street>
<city>Hangzhou</city>
<code>310051</code>
<country>CN</country>
</postal><phone>+86 571 8847 3644</phone>
<email>532874282@qq.com</email>
</address></author>
<date year="2023" month="October" day="19"></date>
<area>Security</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>IoT</keyword>
<keyword>secure access</keyword>
<keyword>smart terminals</keyword>

<abstract>
<t>It is difficult to supervise the great deal of Internet of Things (IoT) smart terminals which are widely distributed. Furthermore, a large number of smart terminals (such as IP cameras, access control terminals, traffic cameras, etc.) running on the network have high security risks in access control. This draft introduces the technical requirements for access management and control of IoT smart terminals, which is used to solve the problem of personate and illegal connection in the access process, and enables users to strengthen the control of devices and discover devices that is offline in time, so as to ensure the safety and stability of smart terminals in the access process.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>With the rapid development of the IoT and the IP-based communication system, a large number of terminals have been interconnected through the network. Due to numerous branches of IoT network and the scattered distribution of smart terminals, it is difficult for human to supervise. Therefore, how to ensure the full-time control and available of IoT network becomes a new problem. A large number of smart terminals (such as IP cameras, access control terminals, traffic cameras and other dumb terminals), which running in the network, have a large security risk in terms of security access control. With the further development of the convergence of IoT systems and information network, if IoT smart terminals are once used by hackers, it is easy for hackers to penetrate the whole network through IoT smart terminals, causing core business systems unable to work and a large amount of confidential information to leak, which will bring huge loss. Therefore, the establishment of a perfect access control mechanism and application control mechanism of smart terminals is an important part of the IoT security system.</t>
<t>This draft outlines the technical requirements for secure access and management of smart terminals in the IoT to address the security threats and challenges that exist in the access process of terminals. We discuss the networking structure of common IoT smart terminals in Section 2. Security threats and challenges faced in the access process of IoT smart terminals in will be clarified in Section 3. In Section 4, we review the guidelines and regulations related to the access of IoT terminals. In Section 5, we present the requirements for secure access and management of IoT smart terminals and describes in detail. This draft provides a reference for IoT security access and management .</t>
</section>

<section anchor="the-network-structure-of-iot-system"><name>The Network Structure of IoT System</name>
<t>Under normal circumstances, IoT smart terminals are connected to the network through IoT gateway, and then the data of terminals is reported to the application center through IoT gateway, which builds the complete network.</t>
<t>The diagram of an IoT system is shown in the figure below. In the perception layer, four types of IoT smart terminals form four subsystems, which are video monitoring subsystem, access control subsystem, alarm subsystem and intercom subsystem. The smart terminals in each subsystem are different. In the video monitoring subsystem, the main terminals are IP cameras and intelligent cameras for collecting video and image data. In the access control subsystem, the main terminals are turnstiles and vehicle access control hosts for collecting vehicle information. In the alarm subsystem, the main terminals are alarm hosts, alarm keyboards and wireless alarm hosts, which are used to set alarm policies, issue alarm warnings and report alarm events, etc. In the intercom subsystem, its main terminals are intercom hosts and individual equipment, which are used to collect voice data. Through this figure, we can know that in the IoT system, smart terminals are heterogeneous and complex, and the data are aggregated into the application layer through the transport layer, which greatly increases the difficulty of the application layer to control the terminals in the sensing layer.</t>

<artwork>+----------------------------------------------------------------------+
|                                                                      |
| Application                                           +------------+ |
|   Layer                   +--------+                  | Video      | |
|              +--------+   | Storage|    +-------+     | Integrated | |
|              |  HOST  |   | System |    |  DVI  +-----+ Platform   | |
|              +---+----+   +---+----+    +---+---+     +------+-----+ |
|                  |            |             |                |       |
|                  |            |             |                |       |
+------------------+------------+--+----------+----------------+-------+
|                                  |                                   |
|                                  |                                   |
| Transport                  +-----+----+                              |
|   Layer                    |  Router  |                              |
|                            +-----+----+                              |
|                                  |                                   |
|             +------------------+-+------------+----------------+     |
|             |                  |              |                |     |
|           +-+-------+     +----+----+    +----+----+     +-----+---+ |
|           | Gateway |     | Gateway |    | Gateway |     | Gateway | |
|           +-+-------+     +----+----+    +----+----+     +-----+---+ |
|             |                  |              |                |     |
|             |                  |              |                |     |
+----------------------------------------------------------------------+
|             |                  |              |                |     |
+-------------+--+ +-------------+--+  +--------+-----+ +--------+-----+
|     Video      | |     Access     |  |    Alarm     | |   Intercom   |
|   Surveillance | |     Control    |  |  Subsystem   | |   Subsystem  |
|    Subsystem   | |    Subsystem   |  | +----------+ | |              |
| +------------+ | | +------------+ |  | |Alarm Host| | | +----------+ |
| | IP Camera  | | | |  Turnstile | |  | +----------+ | | |Intercom  | |
| +------------+ | | +------------+ |  | |   Alarm  | | | |  Host    | |
| | Ip Camera  | | | |   Vehicle  | |  | | Keyboard | | | +----------+ |
| +------------+ | | |   Access   | |  | +----------+ | | |Individual| |
| |Smart Camera| | | |Control Host| |  | | Wireless | | | |Equipment | |
| +------------+ | | +------------+ |  | |Alarm Host| | | |          | |
+----------------+ +----------------+  | +----------+ | | +----------+ |
|                                      +--------------+ +--------------+
|   Perception                                                         |
|     Layer                                                            |
|                                                                      |
+----------------------------------------------------------------------+
</artwork>
<t>Figure: The Network Structure of an IoT System</t>
</section>

<section anchor="security-threats-and-challenges"><name>Security Threats and Challenges</name>
<t>The main security threats and challenges in the process of accessing IoT smart terminals are as follows:</t>

<ol>
<li><t>Illegal connection: By IoT smart terminals, illegal devices and hosts may access to the network for probing and attacking. The application layer network may be invaded by smart terminals, which will lead to information leakage.</t>
</li>
<li><t>Personate connection: Wide distribution of IoT smart terminals and the public deployment environment make it easy for malicious devices to impersonate legitimate devices and upload fake data, which will lead to abnormal function of the devices and causes great damage to the security of IoT.</t>
</li>
<li><t>Devices offline: IoT smart terminals are numerous and very vulnerable when they suffer from physical attacks, network anomalies, power supply anomalies, and aging of device, which leads them to work offline. However, offline devices are difficult to discover, causing the loss of some functions.</t>
</li>
<li><t>Devices management: There are many kinds of IoT smart terminals, and it is often not clear how many IoT smart terminals are in the whole IoT network and how many IoT smart terminals have security problems, which leads to unable to control IoT smart terminals and sort out device assets.</t>
</li>
</ol>
</section>

<section anchor="current-technology-level"><name>Current Technology Level</name>

<ol>
<li><t>On the access control of IoT, many control protocols applied to IoT smart terminals have been proposed, such as Zigbee <xref target="ZB"></xref>, DALI <xref target="DALI"></xref>, BACNET <xref target="BACNET"></xref>, which do not contribute to the secure access of IoT devices. The UPnP <xref target="ISOIEC23941"></xref> access protocol defines the access to IoT smart terminals, but does not consider the issue of secure access.</t>
</li>
<li><t>There are many specialized and generic security protocols being used in current IP-based deployments of IoT smart device applications. For example, IPsec <xref target="RFC7296"></xref>, TLS <xref target="RFC8446"></xref>, DTLS <xref target="RFC6347"></xref>, HIP <xref target="RFC7401"></xref>, Kerberos <xref target="RFC4120"></xref>, SASL <xref target="RFC4422"></xref>, and EAP <xref target="RFC3748"></xref>, etc. However, these protocols also can not protect against illegal connection, personate connection and offline encountered during device access.</t>
</li>
<li><t>There are also a number of groups that  focus on IoT device security. For example, the Cloud Security Alliance (CSA) recommended that when enterprises build the IoT network, they should strengthen IoT smart device authentication/authorization <xref target="CSA"></xref>. The Global System for Mobile communications Association (GSMA) has published a security guide for IoT systems <xref target="GSMA"></xref> to bring a set of security guidelines to the research of IoT security product. The United States Department of Homeland Security(DHS) has proposed six IoT security strategic principles <xref target="DHS"></xref> to guide IoT developers, manufacturers, service providers, and consumers in considering security issues. These teams give good advice on building security for the IoT, but there is no introduction or description of secure access to the IoT.</t>
</li>
<li><t>The current security standards on IoT, such as <xref target="RFC8576"></xref>, introduce the security issues and solutions, but there is no mention of the problems and solutions in the access process of smart terminals.</t>
</li>
<li><t>In other related device access standards, there are device access and portal-based authentication based on 802.1x <xref target="ISO88021X"></xref>. However, due to IoT smart terminals are mainly dumb terminals, they are not suitable for authentication access through 802.1x or portal, and the two authentication methods cannot be used to solve the illegal and personate connection of devices.</t>
</li>
</ol>
</section>

<section anchor="secure-access-and-management-of-iot-smart-terminals"><name>Secure Access and Management of IoT Smart Terminals</name>

<section anchor="framework-of-secure-access-management"><name>Framework of Secure Access Management</name>
<t>Comparing to three-layer framework of IoT,a layer of access and management is added for the framework of secure access management, which is between transport layer and application layer. The framework of secure access management for IoT smart terminals is shown in the following figure. In this framework, the access process of IoT is divided into four parts, which are sensing&amp;control domain, access&amp;management domain, application&amp;service domain, and user domain. Among them, access&amp;management domain is the specific implementation of the secure access and management technical requirements to ensure secure access of smart terminals in terms of smart terminals management, access control, strategy management and access log audit.</t>

<artwork>+-------------------------------------------------------User Domain----+
|      Application &amp; Service Domain                                    |
| +------------------+    +------------------+   +-------------------+ |
| |Bussiness System 1|    |Bussiness System 2|   |Bussiness System...| |
| +------------------+    +------------------+   +-------------------+ |
+----------------------------------------------------------------------+
           ^                ^                ^
           |                |                |
+----------+----------------+----------------+----------User Domain----+
|                     Access &amp; Management Domain                       |
| +-----------------+-----------------+----------------+-------------+ |
| |      Device     |  Device Access  |  Access Policy |  Log Audit  | |
| |    Management   | +-------------+ |   Management   |             | |
| |                 | |  Unique ID  | |                |             | |
| |                 | | Information | |                |             | |
| | +-----+-------+ | +-------------+ | +------------+ |             | |
| | | IP  | Port&amp; | | |  Trusted    | | |   IP&amp;MAC   | | +---------+ | |
| | |     |Service| | |Communication| | +------------+ | |Exception| | |
| | +-------------+ | |  Protocol   | | |IP&amp;MAC&amp;Brand| | +---------+ | |
| | |Type | Brand | | +-------------+ | +------------+ | |Behavior | | |
| | +-------------+ | | Certificate | | |IP&amp;MAC&amp;Brand| | +---------+ | |
| | |Model|  MAC  | | |   access    | | |   &amp;Model   | | |Operation| | |
| | +-------------+ | +-------------+ | +------------+ | +---------+ | |
| +------------------------------------------------------------------+ |
+----------------------------------------------------------------------+
                    Indirect  ^             ^           ^ Direct
                    Connection|             |           | Connection
+----------------------------------------------------------------------+
| Sensing &amp;                 +-----------+   |           |              |
| Controlling               |IoT Gateway|   |           |              |
|   Domain                  +------^----+   |           |              |
|                                  |        |           |              |
| +------------------------------------------------------------------+ |
| | +---------+   +---------+   +--------+  |  +------+ |   +------+ | |
| | |RS-485   |   |Zigbee   |   |IP/WIFI/|  |  |Video | |   |Smart | | |
| | |RS232    |   |Lora and |   |5G/4G   |  |  |and   | |   |IP    | | |
| | |and Other|   |Other    |   |Smart   +--+  |Audio +-+   |Camera| | |
| | |Wired    |   |Wireless |   |Device  |     |Device|     +------+ | |
| | |Terminals|   |Terminals|   +--------+     |RFID  |              | |
| | +---------+   +---------+                  +------+              | |
| +------------------------------------------------------------------+ |
+----------------------------------------------------------------------+
</artwork>
<t>Figure: Framework of Secure Access Management for Smart Terminals</t>

<section anchor="sensing-controlling-domain"><name><strong>Sensing &amp; Controlling Domain</strong></name>
<t>Smart Terminals: Include wired terminals like RS-485, RS-232 and other devices, wireless terminals such as ZigBee, LoRa and other devices, smart devices like smart IP, WiFi, 5G, 4G, audio and video device and RFID, etc.</t>
<t>IOT Gateway: An entity used to connect smart terminals and upper layer, which is able to store data, compute data and transform protocol.</t>
<t>Among them, smart terminals can be directly connected to the access &amp;-management domain, or indirectly connected to the access &amp; management domain through the IoT gateway.</t>
</section>

<section anchor="access-management-domain"><name><strong>Access &amp; Management Domain</strong></name>
<t>Access &amp; management domain is the core, which is used to manage and control the access of smart terminals, including four parts: device management, device access, access policy management and log audit.</t>
<t>The contents of each part are clarified as follows:</t>
<t>Device Management: It mainly manages device asset information, including status, IP address, MAC address, type, brand, model, firmware version, open port and service of smart terminals.</t>
<t>Device Access: It refers to the device access mode supported by smart terminals, including access based on unique identification information of smart terminals (the composition of it can be one or more sets of device asset information), access based on trusted communication protocol of smart terminals and access based on certificate authentication.</t>
<t>Access Policy Management: It refers to the access policy management based on the unique identification information of smart terminals. The access policy includes IP&amp;MAC access policy, IP&amp;MAC&amp;brand access policy, IP&amp;MAC&amp;brand&amp;model access policy.</t>
<t>Log Audit: Used to record, store and audit the log information generated in the access process of smart terminals, including exception log audit, behavior log audit and operation log audit.</t>
</section>

<section anchor="application-service-domain"><name><strong>Application &amp; Service Domain</strong></name>
<t>Application &amp; service domain is the core business system, which provides informational application services for information collecting, exchanging and processing. The information provided by the smart terminals is verified by the access &amp; management domain to ensure security and stability of the system.</t>
</section>

<section anchor="user-domain"><name><strong>User Domain</strong></name>
<t>User domain refers to the users of smart terminals who can directly access the core business system in application &amp; service domain, and view the access condition of smart terminals and manage them in access &amp; management domain.</t>
</section>
</section>

<section anchor="requirements-for-device-security-access"><name><strong>Requirements for Device Security Access</strong></name>

<section anchor="requirements-for-devices-access-authentication-identity-information"><name><strong>Requirements for Devices Access Authentication Identity Information</strong></name>
<t>The identity information of devices should include one or more of the following characteristics:</t>
<t>1.IP Address
2.MAC Address
3.Brand
4.Type
5.Model
6.Firmware Version
7.Port &amp; Service</t>
</section>

<section anchor="requirements-for-access-status-of-devices"><name><strong>Requirements for Access Status of Devices</strong></name>
<t>There should be at least four types of access status:</t>
<t>1.Online: The device that has been authenticated and is still working well.
2.Offline: The device that has been authenticated whereas is not connected to network.
3.Replacement: The device that has not been authenticated whereas its authentication information is as the same as other authenticated device.
4.Illegal connection: The device that has not been authenticated and its information is different from other authenticated device.</t>
</section>

<section anchor="recommendation-of-access-policy"><name><strong>Recommendation of Access Policy</strong></name>
<t>1.The device access policy should have at least five combinations:<br />
  a. IP + MAC<br />
  b. IP + MAC + Brand<br />
  c. IP + MAC + Brand + Model<br />
  d. IP + MAC + Brand + Model + Type<br />
  e. IP + MAC + Brand + Model + Type + Firmware Version
2.The illegal access of replacement device and illegal connection device can be quickly discovered and prevented.
3.The configuration of access policy can be done manually and automatically.
4.The access policy can be customized by any combination of recommendation of access policy shown in requirement 1.</t>
</section>
</section>

<section anchor="requirements-for-management-of-terminals"><name><strong>Requirements for Management of Terminals</strong></name>
<t>Device management requires to monitor status of terminals in real time, to profile terminals, to identify and manage applications running on terminals, to identify and manage asset information of terminals, and to manage IP addresses of terminals.</t>
<t>1.Requirements for condition monitoring and management of terminals
  a.It should be able to monitor the offline and online status of smart terminals in real time.
  b.It should be able to discover whether there is a weak password information of the smart terminal.
  c.It should be able to discover the risky ports of smart terminals.
  d.It should be able to alert offline devices or the devices with weak passwords and risky ports.
2.Requirements for management of terminal profiling
  a.It should be able to visualize the information of smart terminals, including IP address, brand, type, model, etc.
3.Requirements for management of identifying applications
  a.It should be able to automatically identify and manage the devices' open services and service ports.
  b.It should be able to automatically discover andidentify the application system of B/S architecture or C/S architecture running in the network where the IoT smart terminal located, including IP, service port, application name.
4.Requirements for management of identifying asset information of the device
  a.It should be able to manage IP address, MAC address, brand, model, type, firmware version, open port, and online time of smart terminals.
  b.It should be able to manage the communicationprotocol information.
  c.It should be able to manage the geographiclocation information of terminals</t>
</section>

<section anchor="requirements-for-device-protocol-access"><name><strong>Requirements for Device Protocol Access</strong></name>
<t>Device Protocol Access requires the ability to release trusted protocol of IoT smart terminals and block untrusted protocols.</t>
<t>1.It should release IoT protocols, such as http, mqtt, onvif, coap, etc.
2.It should block illegal protocols in real time, such as ssh, ftp, telnet, etc.
3.It should select the corresponding protocols based on the specific business scenario, such as rtsp, onvif, and other protocols that used in the video surveillance field.</t>

<section anchor="requirements-for-access-log-audit"><name><strong>Requirements for Access Log Audit</strong></name>
<t>Access log audit requires the ability to audit all types of operations, such as abnormal and malicious behavior of access.</t>
<t>1.It should record abnormal behavior log information of access in real time and provide analysis and audit functions.
2.It should record malicious behavior log information of access in real time and provide analysis and audit functions.
3.It should record the management, access and blocking of access devices and other types of operations in real time, and provide analysis and audit functions.</t>
</section>
</section>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>This entire memo deals with security issues.</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This documents has no IANA actions.</t>
</section>

</middle>

<back>
<references><name>Informative References</name>
<reference anchor="BACNET" target="http://www.bacnet.org">
  <front>
    <title>BACnet</title>
    <author>
      <organization>American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE)</organization>
    </author>
    <date></date>
  </front>
</reference>
<reference anchor="CSA" target="https://downloads.cloudsecurityalliance.org/whitepapers/Security_Guidance_for_Early_Adopters_of_the_Internet_of_Things.pdf">
  <front>
    <title>Security Guidance for Early Adopters of the Internet of Things (IoT)</title>
    <author></author>
    <date year="2015"></date>
  </front>
</reference>
<reference anchor="DALI" target="http://www.dalibydesign.us/dali.html">
  <front>
    <title>DALI Explained</title>
    <author></author>
    <date></date>
  </front>
</reference>
<reference anchor="DHS" target="https://www.dhs.gov/sites/default/files/publications/Strategic_Principles_for_Securing_the_Internet_of_Things-2016-1115-FINAL....pdf">
  <front>
    <title>Strategic Principles For Securing the Internet of Things (IoT)</title>
    <author></author>
    <date year="2016"></date>
  </front>
</reference>
<reference anchor="GSMA" target="http://www.gsma.com/connectedliving/future-iot-networks/iot-security-guidelines">
  <front>
    <title>GSMA IoT Security Guidelines and Assessment</title>
    <author></author>
    <date></date>
  </front>
</reference>
<reference anchor="ISO88021X" target="">
  <front>
    <title>Telecommunications and exchange between information technology systems - Requirements for local and metropolitan area networks - Part 1X: Port-based network access control</title>
    <author>
      <organization>ISO/IEC/IEEE</organization>
    </author>
    <date></date>
  </front>
</reference>
<reference anchor="ISOIEC23941" target="">
  <front>
    <title>IoT management and control device control protocol</title>
    <author>
      <organization>ISO/IEC</organization>
    </author>
    <date></date>
  </front>
</reference>
<reference anchor="RFC3748" target="https://www.rfc-editor.org/info/rfc3748">
  <front>
    <title>Extensible Authentication Protocol (EAP)</title>
    <author fullname="B. Aboba" initials="B." surname="Aboba">
      <organization></organization>
    </author>
    <author fullname="L. Blunk" initials="L." surname="Blunk">
      <organization></organization>
    </author>
    <author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht">
      <organization></organization>
    </author>
    <author fullname="J. Carlson" initials="J." surname="Carlson">
      <organization></organization>
    </author>
    <author fullname="H. Levkowetz" initials="H." surname="Levkowetz" role="editor">
      <organization></organization>
    </author>
    <date year="2004" month="June"></date>
  </front>
  <seriesInfo name="DOI" value="10.17487/RFC3748"></seriesInfo>
</reference>
<reference anchor="RFC4120" target="https://www.rfc-editor.org/info/rfc4120">
  <front>
    <title>The Kerberos Network Authentication Service (V5)</title>
    <author fullname="C. Neuman" initials="C." surname="Neuman">
      <organization></organization>
    </author>
    <author fullname="T. Yu" initials="T." surname="Yu">
      <organization></organization>
    </author>
    <author fullname="S. Hartman" initials="S." surname="Hartman">
      <organization></organization>
    </author>
    <author fullname="K. Raeburn" initials="K." surname="Raeburn">
      <organization></organization>
    </author>
    <date year="2005" month="July"></date>
  </front>
  <seriesInfo name="DOI" value="10.17487/RFC4120"></seriesInfo>
</reference>
<reference anchor="RFC4422" target="https://www.rfc-editor.org/info/rfc4422">
  <front>
    <title>Simple Authentication and Security Layer (SASL)</title>
    <author fullname="A. Melnikov" initials="A." surname="Melnikov" role="editor">
      <organization></organization>
    </author>
    <author fullname="K. Zeilenga" initials="K." surname="Zeilenga" role="editor">
      <organization></organization>
    </author>
    <date year="2006" month="June"></date>
  </front>
  <seriesInfo name="DOI" value="10.17487/RFC4422"></seriesInfo>
</reference>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347">
  <front>
    <title>Datagram Transport Layer Security Version 1.2</title>
    <author fullname="E. Rescorla" initials="E." surname="Rescorla">
      <organization></organization>
    </author>
    <author fullname="N. Modadugu" initials="N." surname="Modadugu">
      <organization></organization>
    </author>
    <date year="2012" month="January"></date>
  </front>
  <seriesInfo name="DOI" value="10.17487/RFC6347"></seriesInfo>
</reference>
<reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7296">
  <front>
    <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
    <author fullname="C. Kaufman" initials="C." surname="Kaufman">
      <organization></organization>
    </author>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman">
      <organization></organization>
    </author>
    <author fullname="Y. Nir" initials="Y." surname="Nir">
      <organization></organization>
    </author>
    <author fullname="P. Eronen" initials="P." surname="Eronen">
      <organization></organization>
    </author>
    <author fullname="T. Kivinen" initials="T." surname="Kivinen">
      <organization></organization>
    </author>
    <date year="2014" month="October"></date>
  </front>
  <seriesInfo name="DOI" value="10.17487/RFC7296"></seriesInfo>
</reference>
<reference anchor="RFC7401" target="https://www.rfc-editor.org/info/rfc7401">
  <front>
    <title>Host Identity Protocol Version 2 (HIPv2)</title>
    <author fullname="R. Moskowitz" initials="R." surname="Moskowitz" role="editor">
      <organization></organization>
    </author>
    <author fullname="T. Heer" initials="T." surname="Heer">
      <organization></organization>
    </author>
    <author fullname="P. Jokela" initials="P." surname="Jokela">
      <organization></organization>
    </author>
    <author fullname="T. Henderson" initials="T." surname="Henderson">
      <organization></organization>
    </author>
    <date year="2015" month="April"></date>
  </front>
  <seriesInfo name="DOI" value="10.17487/RFC7401"></seriesInfo>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446">
  <front>
    <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
    <author fullname="E. Rescorla" initials="E." surname="Rescorla">
      <organization></organization>
    </author>
    <date year="2018" month="August"></date>
  </front>
  <seriesInfo name="DOI" value="10.17487/RFC8446"></seriesInfo>
</reference>
<reference anchor="RFC8576" target="https://www.rfc-editor.org/info/rfc8576">
  <front>
    <title>Internet of Things (IoT) Security: State of the Art and Challenges</title>
    <author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morchon">
      <organization></organization>
    </author>
    <author fullname="S. Kumar" initials="S." surname="Kumar">
      <organization></organization>
    </author>
    <author fullname="M. Sethi" initials="M." surname="Sethi">
      <organization></organization>
    </author>
    <date year="2019" month="April"></date>
  </front>
  <seriesInfo name="DOI" value="10.17487/RFC8576"></seriesInfo>
</reference>
<reference anchor="ZB" target="http://www.zigbee.org/">
  <front>
    <title>Zigbee Alliance</title>
    <author></author>
    <date year="2020"></date>
  </front>
</reference>
</references>

</back>

</rfc>
