Open Service Access Protocol for IoT Smart Devices
draft-wang-open-service-access-protocol-05
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bin Wang , Shaopeng Zhou , Chao Li , Chunming Wu , Zizhao Wang , HaoNan Yan , Yinghui Xie | ||
| Last updated | 2024-04-14 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-open-service-access-protocol-05
Internet Engineering Task Force B. Wang, Ed.
Internet-Draft S. Zhou, Ed.
Intended status: Standards Track Hikvision
Expires: 17 October 2024 C. Li, Ed.
Guangzhou University
C. Wu, Ed.
Z. Wang, Ed.
Zhejiang University
H.N. Yan, Ed.
Y.H. Xie, Ed.
Hikvision
15 April 2024
Open Service Access Protocol for IoT Smart Devices
draft-wang-open-service-access-protocol-05
Abstract
With the development of IoT (Internet of Things) technology,
everything becomes interconnected. Mass IoT data, devices,
businesses, and services adopt different data descriptions and
service access methods, resulting in fragmentation issues such as
data heterogeneity, device heterogeneity, and application
heterogeneity. These issues hinder the development of the industry.
To solve this problem, this draft proposes the requirements for IoT
smart devices to transmit and control, as well as transmission and
protocol interfaces. It is intended for program design, system
testing and acceptance, and related research. The structured,
unified, and standardized open service interconnection model reduces
business replication costs and eliminates service barriers, thus
promoting industrial development.
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."
Wang, et al. Expires 17 October 2024 [Page 1]
Internet-Draft Open Service Access Protocol for IoT April 2024
This Internet-Draft will expire on 17 October 2024.
Copyright Notice
Copyright (c) 2024 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. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements for Consistency . . . . . . . . . . . . . . . . 4
2.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 4
2.1.1. Area . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Attribute . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3. Operation . . . . . . . . . . . . . . . . . . . . . . 4
2.1.4. Event . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.5. Resource . . . . . . . . . . . . . . . . . . . . . . 4
2.1.6. IoT Device Management Platform . . . . . . . . . . . 4
2.1.7. Load Balancing Service . . . . . . . . . . . . . . . 4
2.1.8. Device Access Service . . . . . . . . . . . . . . . . 5
2.1.9. Picture Service . . . . . . . . . . . . . . . . . . . 5
2.1.10. Video Service . . . . . . . . . . . . . . . . . . . . 5
2.1.11. Event Service . . . . . . . . . . . . . . . . . . . . 5
2.1.12. IoT Smart Devices . . . . . . . . . . . . . . . . . . 5
2.2. Abbreviations and Acronyms . . . . . . . . . . . . . . . 5
3. IOT model construction . . . . . . . . . . . . . . . . . . . 6
3.1. Model Design Principles . . . . . . . . . . . . . . . . . 6
3.1.1. Simple . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Pervasiveness . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Extensibility . . . . . . . . . . . . . . . . . . . . 6
3.1.4. Ease of use . . . . . . . . . . . . . . . . . . . . . 6
4. Framework of Device Communication Protocol . . . . . . . . . 6
5. Interface protocol structure . . . . . . . . . . . . . . . . 7
6. Device certification . . . . . . . . . . . . . . . . . . . . 8
7. Get access service . . . . . . . . . . . . . . . . . . . . . 16
8. Registration and Deregistration . . . . . . . . . . . . . . . 17
9. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
Wang, et al. Expires 17 October 2024 [Page 2]
Internet-Draft Open Service Access Protocol for IoT April 2024
12. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Preface
With the development of IoT technology, everything is widely
interconnected and deeply invole with human-machine interaction.
This includes various innovative applications such as autonomous
vehicles, telemedicine, smart factories, smart cities, and more.
However, as businesses grow, the adoption of different data
descriptions and service access methods by mass IoT data, devices,
businesses, and services leads to fragmentation issues. These
fragmentation issues can be observed in the form of data
heterogeneity, device heterogeneity, and application heterogeneity.
Unfortunately, these issues hinder the development of the industry.
The main challenges that arise from this fragmentation are:
1. Low value of data: IoT data has the characteristics of multi-
source heterogeneity and huge scale, making it difficult for data
analysis and sharing. At the same time, the lack of business
relevance between massive amounts of data leads to inefficient
use of data.
2. High cost of business replication: different devices use
different access standards. The cost of device access is too
high and the time is too long. With the growth quantity of
applications and devices, new device needs to be customized and
developed multiple times for different standards, resulting in
increased business replication cost.
3. Difficulty in industrial chain cooperation: There are different
access protocols and data models between different manufacturers.
The internal industrial chain has its own system, which makes it
difficult for industrial chain to collaborate, for devices to be
linked, maintained, for service to be compatible, Which seriously
affects the user experience.
In order to solve the problem, this draft proposes the requirements
for IoT smart devices to transmit and control, as well as
transmission and protocol interfaces. It is for the program design,
system testing and acceptance, and related research. Structured,
unified, and standardized open service interconnection model reduces
business replication cost and removes service barriers to push
industrial development.
Wang, et al. Expires 17 October 2024 [Page 3]
Internet-Draft Open Service Access Protocol for IoT April 2024
2. Requirements for Consistency
2.1. Terms and Definitions
2.1.1. Area
A set of related functions, which is business independent.
2.1.2. Attribute
Used to describe the sustainable state of the devices during
operation, which can be read and set.
2.1.3. Operation
A method that can be called externally by a device or platform. The
operation includes "input parameters" and "output parameters". The
input parameters are the instruction information that needed to
perform the operation, and the output parameters are the feedback
information after the instruction is executed.
2.1.4. Event
Information actively reported by the device. This type of
information needs to be reported in real time and processed by the
platform in time. If the device network is interrupted, it can be
cached and reported after recovery.
2.1.5. Resource
An entity that is a relatively independent component of the device
and can independently handle user requirements. User applications
can independently show or manage the resources of the device. For
example, the video channel of NVR device.
2.1.6. IoT Device Management Platform
A system that connects a large number of diverse and heterogeneous
sensing devices and can unify access management of devices, collect,
process and store data.
2.1.7. Load Balancing Service
Responsible for equipment certification. The device actively
authenticates to the load balancing service. After passing the
authentication, the device will balance the load to multiple devices
to access the service through redirection.
Wang, et al. Expires 17 October 2024 [Page 4]
Internet-Draft Open Service Access Protocol for IoT April 2024
2.1.8. Device Access Service
Services for managing, controlling and configing device functions and
support attributes, operations, and events.
2.1.9. Picture Service
Responsible for image storage services, support upload, download
images and other functions.
2.1.10. Video Service
Responsible for media data transmission, support real-time preview,
video playback, voice intercom and other functions.
2.1.11. Event Service
Responsible for receiving and handling events.
2.1.12. IoT Smart Devices
Physical entities with video, image, and information perception
capabilities, including: video equipment, access control, radar, etc.
It can be directly connected to the IoT device management platform,
or be a gateway that connects the agent sub-device and the IoT device
management platform.
2.2. Abbreviations and Acronyms
+============================+=====================================+
| Abbreviations and Acronyms | Full Name |
+============================+=====================================+
| IP | Internet Protocol |
+----------------------------+-------------------------------------+
| JSON | Java Script Object Notation |
+----------------------------+-------------------------------------+
| MQTT[MQTT2016] | Message Queuing Telemetry Transport |
+----------------------------+-------------------------------------+
| TLS[RFC8446] | Transport Layer Security |
+----------------------------+-------------------------------------+
| UTF-8 | 8-bit Unicode Transformation Forma |
+----------------------------+-------------------------------------+
| URL | Uniform Resoure Locator |
+----------------------------+-------------------------------------+
Table 1: Abbreviations and Acronyms
Wang, et al. Expires 17 October 2024 [Page 5]
Internet-Draft Open Service Access Protocol for IoT April 2024
3. IOT model construction
3.1. Model Design Principles
3.1.1. Simple
The model is independent of network technology and operator protocol,
and focuses on the virtualization description of the device itself,
which simplifies the understanding process of the device
manufacturer.
3.1.2. Pervasiveness
It is compatible with the needs of more manufacturers as much as
possible. The model is divided into public attributes and specific
attributes. The device can have public attributes or include self-
defined features of the device. and Provide industry model templates
by industry.
3.1.3. Extensibility
Support user-defined services, provide data transparent transmission
mechanism, and define basic model capabilities and industry templates
separately.
Modularity: reduce duplicate resources, extract public services for
reuse, and improve utilization efficiency.
3.1.4. Ease of use
Provide more easy-to-use interfaces, including DSL language model
description for integration.
4. Framework of Device Communication Protocol
The framework of the protocol is shown below:
Wang, et al. Expires 17 October 2024 [Page 6]
Internet-Draft Open Service Access Protocol for IoT April 2024
Bussiness Protocol-------------------------------------------+
| +------+ +-----+ +-------+ +----+ +--------+ |
| | | | | | | |Area| |Resource| |
| |Store/| |Media| |Upgrate| +----+ +--------+ |
| | File | | | | | +---------+ +---------+ +-----+ |
| | | | | | | |Attribute| |Operation| |Event| |
| +------+ +-----+ +-------+ +---------+ +---------+ +-----+ |
+------------------------------------------------------------+
Fundamental Communication Protocol---------------------------+
| +---------------------------+ |
| | +-----------------------+ +----------------------------+ |
| | | Store | Media |Update | | Attribute|Operation| Event | |
| | |Channel|Channel|Channel| | Channel | Channel |Channel| |
| | +-----------------------+ +----^-----+----^---------^--+ |
| +---------------------------+ | | | |
| ^ ^ ^ | | | |
| | | +---+---------+----------+---------+--+ |
| | | | MQTT | |
| | | +-----------------^---------------^---+ |
| | | | | |
| | | | +----+---+ |
| | | | | TLS | |
| | | | +----^---+ |
| | | | | |
| +---+---+ +--+---------------------+---------------+---+ |
| |HTTP(S)| | TCP | |
| +-------+ +--------------------------------------------+ |
+------------------------------------------------------------+
Figure 1: Framework of Device Communication Protocol
The business is separated from the protocol. In the bottom layer, it
adopts MQTT to transmit data. Different transmission channels are
used for authentication, media, storage and attributes, operations,
and events.
5. Interface protocol structure
In this draft, the session channel interface adopts MQTT protocol.
Structure of MQTT protocol is divided into three sections: fixed
header, variable header and payload. Structure of MQTT protocol is
shown below.
Wang, et al. Expires 17 October 2024 [Page 7]
Internet-Draft Open Service Access Protocol for IoT April 2024
--------+---------------------------+-----------------------------------
| |
| Header | Payload
Structre|------------+--------------+----------------+------------------
| | | |
|Fixedheader |Variableheader|GeneralPayload |ApplicationPayload
--------+------------+--------------+-------+--------+------------------
Name |Fixedheader |Variableheader|Length |Content |Content
--------+------------+--------------+-------+--------+------------------
Symbol |FixedHEADER |VariableHEADER|LEN |Gernal |Func
--------+------------+--------------+-------+--------+------------------
Length |2-5 Bytes |Variable |2 Bytes|Variable|Variable
--------+------------+--------------+-------+--------+------------------
Des- |Depending |Different |The |See |The format
cription|on the |control |length |defi- |depends on
|length of |message has |of |nition |specific
|the variable|different |general|for its |transaction
|header and |variable |payload|format |
|payload, the|headers | | |
|length of | | | |
|the fixed | | | |
|header | | | |
|varies | | | |
|between 2 | | | |
|and 5 bytes | | | |
--------+------------+--------------+-------+--------+------------------
Figure 2: MQTT protocol structure
General protocols and business protocol bodies need AES (128)
encryption during transmission, and UTF-8 encoding is used uniformly
for character strings.
6. Device certification
The overall protocol format of the authentication process is shown as
follows:
Wang, et al. Expires 17 October 2024 [Page 8]
Internet-Draft Open Service Access Protocol for IoT April 2024
--------+--------------------------+------------------------------------
| |
| Header | Payload
Structre|-----------+--------------+-----------------+------------------
| | | |
|Fixedheader|Variableheader|GeneralPayload |ApplicationPayload
--------+-----------+--------------+---------+-------+------------------
Name |Fixedheader|Variableheader|Version |Con+ |
| | | |tent |
--------+-----------+--------------+---------+-------+------------------
Symbol |FixedHEADER|VariableHEADER|PROTOCOL-| |PROTOCOL-
| | |VERSION |Func |VERSION
| | | | |
--------+-----------+--------------+---------+-------+------------------
Length |2|5 Bytes |Variable |3 Bytes |Va- |3 Bytes
| | | |riable |
| | | | |
--------+-----------+--------------+---------+-------+------------------
Des- |Depending |Different |The |See |The
cription|on the |control |version |tran- |version
|length of |message has |of |saction|of
|the |different |protocol |for its|protocol
|variable |variable | |format |
|header and |headers | | |
|payload, | | | |
|the | | | |
|length of | | | |
|the fixed | | | |
|header | | | |
|varies | | | |
|between 2 | | | |
|and 5 bytes| | | |
--------+-----------+--------------+---------+-------+------------------
Figure 3: MQTT protocol format
The protocol version definition is shown as follows:
Wang, et al. Expires 17 October 2024 [Page 9]
Internet-Draft Open Service Access Protocol for IoT April 2024
+===================+======+=======================================+
| Name | Type | Description |
+===================+======+=======================================+
| FORM_VERSION | char | version number of protocol form |
+-------------------+------+---------------------------------------+
| HIGH_TYPE_VERSION | char | version number of protocol type(high) |
+-------------------+------+---------------------------------------+
| LOW_TYPE_VERSION | char | version number of protocol type(low) |
+-------------------+------+---------------------------------------+
Table 2: Protocol version definition
Device access adopts bidirectional negotiation protocol process.
Devices sends the supported type of protocol group to the balance
load service, and the server will determine which way to communicate
depending on its own situation. After the device being
authenticated, it can establish an MQTT connection with the device
access service (Das) through the sessionkey to communicate with the
bussiness protocol. The specific bidirectional negotiation diagram
is as follows:
Wang, et al. Expires 17 October 2024 [Page 10]
Internet-Draft Open Service Access Protocol for IoT April 2024
+------+ +------+
|Device| |Server|
+---+--+ +------+
| |
| |
| |
| |
+----------------------+----------+ | |
| Negotiation Request | | | |
+----------------------+ | +--Negotiation Request---> +--+
| Control Message Type:0x1 | | | |
| | | | |
| Control Flag:0x1 | | | |
| | | | |
| Protocol Type:1 | | | |
| | | | |
| Protocol Group:(1,2,4,8) | | | |
| | | <--Negotiation Response--+ |
| Transaction Content:xxxxxx | | | |
+---------------------------------+ | +--+
| |
| |
+----------------------+----------+ | |
| Negotiation Response | | | |
+----------------------+ | | |
| Control Message Type:0x2 | | |
| | | |
| Control Flag:0x1 | | |
| | | |
| Protocol Type:1 | | |
| | | |
| Transaction Content:xxxxxx | | |
+---------------------------------+ | |
Figure 4: bidirectional negotiation diagram - consistence
Wang, et al. Expires 17 October 2024 [Page 11]
Internet-Draft Open Service Access Protocol for IoT April 2024
+------+ +------+
|Device| |Server|
+---+--+ +------+
+----------------+-+ | | +----------------+-+
| Negotiation | | | | | Negotiation | |
| Request2 | | | | | Response2 | |
+----------------+ | | Negotiation | +----------------+ |
|Control | +-- Request1 --> | |Control |
|Message Type:0x1 | | | |Message Type:0x2 |
| | | | | |
|Control Flag:0x1 | | | |Control Flag:0x1 |
| | | | | |
|Protocol Type:2 | | | |Protocol Type:2 |
| | | | | |
|Protocol | | Negotiation | |Protocol |
|Group:(1,2,4,8) | | <-- Response1--+ |Group:(2,4,8) |
| | | | | |
|Transaction | | | |Transaction |
|Content:xxxx | | | |Content:xxxx |
+------------------+ | | +------------------+
| |
+------------------------------------------------------------------+
| Negotiation |
Disconnect +-- Request2 --> |
| |
+----------------+-+ | | +----------------+-+
| Negotiation | | | | | Negotiation | |
| Request2 | | | | | Response2 | |
+----------------+ | | | +----------------+ |
|Control | | | |Control |
|Message Type:0x1 | | Negotiation | |Message Type:0x2 |
| | | <-- Response2--+ | |
|Control Flag:0x1 | | | |Control Flag:0x1 |
| | | | | |
|Protocol Type:2 | | | |Protocol Type:2 |
| | | | | |
|Protocol | | | |Transaction |
|Group:(1,2,4,8) | | | |Content:xxxx |
| | | | | |
|Transaction | | | | |
|Content:xxxx | | | | |
+------------------+ | | +------------------+
| |
| |
+ +
Figure 5: bidirectional negotiation diagram - inconsistence
Wang, et al. Expires 17 October 2024 [Page 12]
Internet-Draft Open Service Access Protocol for IoT April 2024
bidirectional negotiation can be divided into two conditions:
(1) If the service supports this type of protocol, select the most
secure protocol in the device's protocol group to complete the
negotiation and communicate with the device;
(2) If the service does not support the type of protocol, return the
message to the device, which contains the type of protocol and
protocol group supported by the service. And then, interupt TCP
connection. If the device supports it, use again the type of
protocol and protocol group supported by the service to go through
the authentication process. Otherwise, the device should give up
authentication with the service.
In order to ensure forward compatibility with the ECDH key
interaction mode, Bit1 of the control flag bit is enabled. When Bit1
is 0, the control message type remains in the original mode, and when
Bit1 is 1, it means that the ECDH key mode is used for interaction.
The key algorithm of secret key in the authentication process:
sharekey:pdkdf2_SHA256(md5(md5(MD5(verification code + device serial
number)+www.88075998.com))) Device masterkey: ecdh_NID_secp384r1
(lbs_publickey, device_privatekey) Server masterkey:
ecdh_NID_secp384r1 (device_publickey, lbs_privatekey)
a) First Authentication
When the device requires for working online the first time,
useexchange algorithm of ECDH secret key to initialize DEVID and
MasterKey. The process is shown as follows:
Wang, et al. Expires 17 October 2024 [Page 13]
Internet-Draft Open Service Access Protocol for IoT April 2024
+------+ +-----------+
|Device| |Lbs Service|
+------+ +------+----+
| |
+-----------------Private key Exchange------------------------+
+-----+ |
| |Generate Private Key and Publickey |
<-----+ |
+-----+ |
| |Generate Share Key |
<-----+ |
|-------Request for Private Key Interaction------->
<-------Reponse for Private Key Interaction-------+
+-----+ |
| |Decrypt lbs_publickey from Response |
<-----+ |
+-----+ |
| |Generate Mater Key |
<-----+ |
+-------------------- Apply DevID----------------------------+
|-------| Request for Applying DevID |------------>
<---------Reponse for Applying DevID--------------+
+-----+ |
| |Decrypt DevID and Session Key from Response|
<-----+ |
|---|Request for Getting Das Service Address------>
<----Reponse for Getting Das Service Address------+
| |
+ +
Figure 6: First Authentication
b) Re-authentication
When the device is disconnected and ask for re-authenticated, it
needs to request re-authentication from the platform and update the
session key. The specific process is shown as follows:
Wang, et al. Expires 17 October 2024 [Page 14]
Internet-Draft Open Service Access Protocol for IoT April 2024
+------+ +-----------+
|Device| |Lbs Service|
+------+ +-----+-----+
| |
+-------------------------------------------------------------+
+------+ Update Request for Sessionkey +----------->
| |
<------+ Update Respond for Sessionkey +-----------+
| |
+-----+ |
| Decrypt Session Key |
| | From Response |
<-----+ |
+-------------------------------------------------------------+
| |
+---------+ Get Service Address Request +---------->
| |
<---------+ Get Service Address Response +---------+
| |
Figure 7: Re-authenticate
c) Define the ECDH control message type as follows:
Wang, et al. Expires 17 October 2024 [Page 15]
Internet-Draft Open Service Access Protocol for IoT April 2024
+===========+=======+================================+=============+
|message |control| name | description |
|direction |message| | |
+===========+=======+================================+=============+
|Dev<--->Lbs|0x1 | Authentication_ECDH_Req | request for |
| | | | ECDH |
| | | | exchange |
+-----------+-------+--------------------------------+-------------+
|Dev<--->Lbs|0x2 | Authentication_ECDH_Rsp | response |
| | | | for ECDH |
| | | | exchange |
+-----------+-------+--------------------------------+-------------+
|Dev<--->Lbs|0x3 | Rsrv | reserve |
+-----------+-------+--------------------------------+-------------+
|Dev<--->Lbs|0x4 | Refresh_SessionKey_Req | refresh |
| | | | SessionKey |
| | | | request |
+-----------+-------+--------------------------------+-------------+
|Dev<--->Lbs|0x5 | Rsrv | reserve |
+-----------+-------+--------------------------------+-------------+
|Dev<--->Lbs|0x6 | Refresh_SessionKey_Rsp | refresh |
| | | | SessionKey |
| | | | response |
+-----------+-------+--------------------------------+-------------+
|Dev<--->Lbs|0x7 | Authentication_apply_devid_Req | request |
| | | | device ID |
+-----------+-------+--------------------------------+-------------+
|Dev<--->Lbs|0x8 | Authentication_apply_devid_Rsq | response |
| | | | device ID |
+-----------+-------+--------------------------------+-------------+
|Dev<--->Lbs|0x9 | Authentication_apply_devid_Cfm | confirm |
| | | | device ID |
+-----------+-------+--------------------------------+-------------+
Table 3: Protocol version definition
7. Get access service
As the number of device accesses increases, there will be bottlenecks
in the performance of single-node accesses, so the platform needs to
support the mode of multiple device accesses. To support this mode,
the devices are redirected to multiple access services by a load
balancing server. After the device obtains the session key through
two-way authentication, it initiates a request for access service
within the same TCP connection, and the message in the request is
encrypted with the session key.
Wang, et al. Expires 17 October 2024 [Page 16]
Internet-Draft Open Service Access Protocol for IoT April 2024
+------------+ +-------------+
+------+ |Balance Load| |Device Access|
|Device| | Service | | Service |
+------+ +------+-----+ +------+------+
| | |
Redirect---------------------------------+ |
| +--- F1:Request for getting a -----> | |
| | device access service address | | |
| | | | |
| <--- F2:Return a device access ----+ | |
| | service information | | |
+----------------------------------------+ |
| | |
Bussiness-------------------------------------------------------+
| | | | |
| <------- Business message:AES128(message)----------> |
| | AES128 private key:session key | |
| | | | |
+---------------------------------------------------------------+
Figure 8: Get access service
8. Registration and Deregistration
After the device completes two-way authentication to obtain a
specific access service address, the device initiates a request to
register online through the MQTT protocol, and the application
message body in the request is encrypted using the sessionKey
obtained by two-way authentication.
+-------------+ +------------+
| Device | | Platform |
|(MQTT Client)| |(MQTT Sever)|
+-----+-------+ +------+-----+
| |
+------- F1:Device register and login(MQTT CONNECT) ------->
| |
<-------- F2:Register and respond(MQTT CONNACK) -----------+
| |
<---------------- Business interaction -------------------->
| |
+---- F3:Send request for disconnect(MQTT DISCONNECT) ----->
| |
+ +
Figure 9: Registration and Deregistration
Wang, et al. Expires 17 October 2024 [Page 17]
Internet-Draft Open Service Access Protocol for IoT April 2024
a) F1: After the device and platform network connection is
established, the device sends a online request to the platform via
MQTTCONNECT, of which payload contains one or more encoded fields,
including: unique identifier of the client, Will subject, Will
message, username and password.
b) F2: The platform returns the response message to the device via
MQTTCONNACK to inform it whether it succeeded or not;
c) F3: Before disconnecting, the device sends a DISSCONNECT message
to the platform, indicating that it wants to disconnect normally, and
the platform will close the TCP/IP connection after receiving the
request.
9. Heartbeat
After the device has registered with the platform, it needs to send
heartbeat requests periodically according to the heartbeat interval
indicated in the registration request. The interval is usually 30s.
Used for:
a) Inform the platform that the device is alive when no other control
messages are sent from the device to the platform.
b) Request the platform to send a response confirming that it is
alive.
c) Use the network to confirm that the network connection is not
disconnected.
+------+ +--------+
|Device| |Platform|
+------+ +----+---+
| |
+------ F1: Send a heartbeat request(MQTT PINGREQ) ----------->
| |
<--- F2: Respond to the heartbeat request MQTT PINGRESP) -----+
| |
Figure 10: Heartbeat
10. Security Considerations
This entire memo deals with security issues.
Wang, et al. Expires 17 October 2024 [Page 18]
Internet-Draft Open Service Access Protocol for IoT April 2024
11. IANA Considerations
This documents has no IANA actions.
12. Informative References
[MQTT2016] ISOIEC, "Information technology - Message Queuing
Telemetry Transport", <https://www.iso.org/obp/
ui/#iso:std:iso-iec:20922:ed-1:v1:en>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Authors' Addresses
Bin Wang (editor)
Hikvision
555 Qianmo Road, Binjiang District
Hangzhou
310051
China
Phone: +86 571 8847 3644
Email: wbin2006@gmail.com
Shaopeng Zhou (editor)
Hikvision
555 Qianmo Road, Binjiang District
Hangzhou
310051
China
Phone: +86 571 8847 3644
Email: zhoushaopeng@hikvision.com
Chao Li (editor)
Guangzhou University
230 Wai Huan Xi Road
Guangzhou
510006
China
Email: lichao@gzhu.edu.cn
Chunming Wu (editor)
Zhejiang University
866 Yuhangtang Rd
Wang, et al. Expires 17 October 2024 [Page 19]
Internet-Draft Open Service Access Protocol for IoT April 2024
Hangzhou
310058
China
Email: wuchunming@zju.edu.cn
Zizhao Wang (editor)
Zhejiang University
866 Yuhangtang Rd
Hangzhou
310058
China
Email: 22021272@zju.edu.cn
HaoNan Yan (editor)
Hikvision
555 Qianmo Road, Binjiang District
Hangzhou
310051
China
Phone: +86 182 9201 6473
Email: yanhaonan@hikvision.com
Yinghui Xie (editor)
Hikvision
555 Qianmo Road, Binjiang District
Hangzhou
310051
China
Phone: +86 139 5327 0326
Email: xieyinghui@hikvision.com
Wang, et al. Expires 17 October 2024 [Page 20]