idnits 2.17.1 draft-wang-secure-access-of-iot-terminals-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 March 2021) is 1129 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Wang, Ed. 3 Internet-Draft S. Liu, Ed. 4 Intended status: Standards Track L. Wan, Ed. 5 Expires: 17 September 2021 Hikvision 6 J. Li, Ed. 7 CICS-CERT 8 X. Wang, Ed. 9 Hikvision 10 16 March 2021 12 Technical Requirements for Secure Access and Management of IoT Smart 13 Terminals 14 draft-wang-secure-access-of-iot-terminals-01 16 Abstract 18 It is difficult to supervise the great deal of Internet of Things 19 (IoT) smart terminals which are widely distributed. Furthermore, a 20 large number of smart terminals (such as IP cameras, access control 21 terminals, traffic cameras, etc.) running on the network have high 22 security risks in access control. This draft introduces the 23 technical requirements for access management and control of IoT smart 24 terminals, which is used to solve the problem of personate and 25 illegal connection in the access process, and enables users to 26 strengthen the control of devices and discover devices that is 27 offline in time, so as to ensure the safety and stability of smart 28 terminals in the access process. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 17 September 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. The Network Structure of IoT system . . . . . . . . . . . . . 3 65 3. Security Threats and Challenges . . . . . . . . . . . . . . . 5 66 4. Current Technology Level . . . . . . . . . . . . . . . . . . 5 67 5. Secure Access and Management of IoT Smart Terminals . . . . . 6 68 5.1. Framework of Secure Access Management . . . . . . . . . . 6 69 5.1.1. Sensing & Controlling Domain . . . . . . . . . . . . 8 70 5.1.2. Access & Management Domain . . . . . . . . . . . . . 8 71 5.1.3. Application & Service Domain . . . . . . . . . . . . 9 72 5.1.4. User Domain . . . . . . . . . . . . . . . . . . . . . 9 73 5.2. Requirements for Device Access . . . . . . . . . . . . . 9 74 5.2.1. Requirements for Devices Access Authentication Identity 75 Information . . . . . . . . . . . . . . . . . . . . . 9 76 5.2.2. Requirements for Access Status of Devices . . . . . . 9 77 5.2.3. Recommendation of Access Policy . . . . . . . . . . . 10 78 5.3. Requirements for Management of terminals . . . . . . . . 10 79 5.4. Requirements for Access Log Audit . . . . . . . . . . . . 11 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Informative References . . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 With the rapid development of the IoT and the IP-based communication 88 system, a large number of terminals have been interconnected through 89 the network. Due to numerous branches of IoT network and the 90 scattered distribution of smart terminals,it is difficult for human 91 to supervise. Therefore, how to ensure the full-time control and 92 available of IoT network becomes a new problem. A large number of 93 smart terminals (such as IP cameras, access control terminals, 94 traffic cameras and other dumb terminals), which running in the 95 network, have a large security risk in terms of security access 96 control. With the further development of the convergence of IoT 97 systems and information network, if IoT smart terminals are once used 98 by hackers, it is easy for hackers to penetrate the whole network 99 through IoT smart terminals, causing core business systems unable to 100 work and a large amount of confidential information to leak, which 101 will bring huge loss. Therefore, the establishment of a perfect 102 access control mechanism and application control mechanism of smart 103 terminals is an important part of the IoT security system. 105 This draft outlines the technical requirements for secure access and 106 management of smart terminals in the IoT to address the security 107 threats and challenges that exist in the access process of terminals. 108 We discuss the networking structure of common IoT smart terminals in 109 Section 2. Security threats and challenges faced in the access 110 process of IoT smart terminals in will be clarified in Section 3. In 111 Section 4, we review the guidelines and regulations related to the 112 access of IoT terminals. In Section 5, we present the requirements 113 for secure access and management of IoT smart terminals and describes 114 in detail. This draft provides a reference for IoT security access 115 and management . 117 2. The Network Structure of IoT system 119 In general, IoT smart terminals are connected to the network through 120 IoT gateway, and then the data of terminals is reported to the 121 application center through IoT gateway, which builds the complete 122 network. 124 The diagram of an IoT system is shown in the figure below. In the 125 perception layer, four types of IoT smart terminals form four 126 subsystems, which are video monitoring subsystem, access control 127 subsystem, alarm subsystem and intercom subsystem. The smart 128 terminals in each subsystem are different. In the video monitoring 129 subsystem, the main terminals are IP cameras and intelligent cameras 130 for collecting video and image data. In the access control 131 subsystem, the main terminals are turnstiles and vehicle access 132 control hosts for collecting vehicle information. In the alarm 133 subsystem, the main terminals are alarm hosts, alarm keyboards and 134 wireless alarm hosts, which are used to set alarm policies, issue 135 alarm warnings and report alarm events, etc. In the intercom 136 subsystem, its main terminals are intercom hosts and individual 137 equipment, which are used to collect voice data. Through this 138 figure, we can know that in the IoT system, smart terminals are 139 heterogeneous and complex, and the data are aggregated into the 140 application layer through the transport layer, which greatly 141 increases the difficulty of the application layer to control the 142 terminals in the sensing layer. 144 +----------------------------------------------------------------------+ 145 | | 146 | Application +------------+ | 147 | Layer +--------+ | Video | | 148 | +--------+ | Storage| +-------+ | integrated | | 149 | | HOST | | system | | DVI +-----+ platform | | 150 | +---+----+ +---+----+ +---+---+ +------+-----+ | 151 | | | | | | 152 | | | | | | 153 +------------------+------------+--+----------+----------------+-------+ 154 | | | 155 | | | 156 | Transport +-----+----+ | 157 | Layer | router | | 158 | +-----+----+ | 159 | | | 160 | +------------------+-+------------+----------------+ | 161 | | | | | | 162 | +-+-------+ +----+----+ +----+----+ +-----+---+ | 163 | | gateway | | gateway | | gateway | | gateway | | 164 | +-+-------+ +----+----+ +----+----+ +-----+---+ | 165 | | | | | | 166 | | | | | | 167 +----------------------------------------------------------------------+ 168 | | | | | | 169 +-------------+--+ +-------------+--+ +--------+-----+ +--------+-----+ 170 | Video | | Access | | Alarm | | Intercom | 171 | surveillance | | control | | subsystem | | subsystem | 172 | subsystem | | subsystem | | +----------+ | | | 173 | +------------+ | | +------------+ | | |Alarm host| | | +----------+ | 174 | | IP camera | | | | Turnstile | | | +----------+ | | |Intercom | | 175 | +------------+ | | +------------+ | | | Alarm | | | | host | | 176 | | Ip Camera | | | | Vehicle | | | | keyboard | | | +----------+ | 177 | +------------+ | | | access | | | +----------+ | | |Individual| | 178 | |Smart Camera| | | |control host| | | | Wireless | | | |equipment | | 179 | +------------+ | | +------------+ | | |alarm host| | | | | | 180 +----------------+ +----------------+ | +----------+ | | +----------+ | 181 | +--------------+ +--------------+ 182 | Perception | 183 | Layer | 184 | | 185 +----------------------------------------------------------------------+ 187 Figure 1: The Network Structure of an IoT System 189 3. Security Threats and Challenges 191 The main security threats and challenges in the process of accessing 192 IoT smart terminals are as follows: 194 1. Illegal connection: By IoT smart terminals, illegal devices and 195 hosts may access to the network for probing and attacking. The 196 application layer network may be invaded by smart terminals, 197 which will lead to information leakage. 199 2. Personate connection: Wide distribution of IoT smart terminals 200 and the public deployment environment make it easy for malicious 201 devices to impersonate legitimate devices and upload fake data, 202 which will lead to abnormal function of the devices and causes 203 great damage to the security of IoT. 205 3. Devices offline: IoT smart terminals are numerous and very 206 vulnerable when they suffer from physical attacks, network 207 anomalies, power supply anomalies, and aging of device, which 208 leads them to work offline. However, offline devices are 209 difficult to discover, causing the loss of some functions. 211 4. Devices management: There are many kinds of IoT smart terminals, 212 and it is often not clear how many IoT smart terminals are in the 213 whole IoT network and how many IoT smart terminals have security 214 problems, which leads to unable to control IoT smart terminals 215 and sort out device assets. 217 4. Current Technology Level 219 1. On the access control of IoT,many control protocols applied to 220 IoT smart terminals have been proposed, such as Zigbee [ZB], DALI 221 [DALI], BACNET [BACNET], which do not contribute to the secure 222 access of IoT devices. The UPnP [ISOIEC23941] access protocol 223 defines the access to IoT smart terminals, but does not consider 224 the issue of secure access. 226 2. There are many specialized and generic security protocols being 227 used in current IP-based deployments of IoT smart device 228 applications. For example, IPsec [RFC7296], TLS [RFC8446], DTLS 229 [RFC6347], HIP [RFC7401], Kerberos [RFC4120], SASL [RFC4422], and 230 EAP [RFC3748], etc. However, these protocols also can not 231 protect against illegal connection, personate connection and 232 offline encountered during device access. 234 3. There are also a number of groups that focus on IoT device 235 security . For example, the Cloud Security Alliance (CSA) 236 recommended that when enterprises build the IoT network, they 237 should strengthen IoT smart device authentication/authorization 238 [CSA]. The Global System for Mobile communications Association 239 (GSMA) has published a security guide for IoT systems [GSMA] to 240 bring a set of security guidelines to the research of IoT 241 security product. The United States Department of Homeland 242 Security(DHS) has proposed six IoT security strategic principles 243 [DHS] to guide IoT developers, manufacturers, service providers, 244 and consumers in considering security issues. These teams give 245 good advice on building security for the IoT, but there is no 246 introduction or description of secure access to the IoT. 248 4. The current security standards on IoT, such as [RFC8576], 249 introduce the security issues and solutions, but there is no 250 mention of the problems and solutions in the access process of 251 smart terminals. 253 5. In other related device access standards, there are device access 254 and portal-based authentication based on 802.1x [ISO88021X]. 255 However, due to IoT smart terminals are mainly dumb terminals, 256 they are not suitable for authentication access through 802.1x or 257 portal, and the two authentication methods cannot be used to 258 solve the illegal and personate connection of devices. 260 5. Secure Access and Management of IoT Smart Terminals 262 5.1. Framework of Secure Access Management 264 Comparing to three-layer framework of IoT,a layer of access and 265 management is added for the framework of secure access management, 266 which is between transport layer and application layer. The 267 framework of secure access management for IoT smart terminals is 268 shown in the following figure. In this framework, the access process 269 of IoT is divided into four parts, which are sensing&control domain, 270 access&management domain, application&service domain and user domain. 271 Among them, access&management domain is the specific implementation 272 of the secure access and management technical requirements to ensure 273 secure access of smart terminals in terms of smart terminals 274 management, access control, strategy management and access log audit. 276 +-------------------------------------------------------User Domain----+ 277 | Application & Service Domain | 278 | +------------------+ +------------------+ +-------------------+ | 279 | |Bussiness System 1| |Bussiness System 2| |Bussiness System...| | 280 | +------------------+ +------------------+ +-------------------+ | 281 +----------------------------------------------------------------------+ 282 ^ ^ ^ 283 | | | 284 +----------+----------------+----------------+----------User Domain----+ 285 | Access & Management Domain | 286 | +-----------------+-----------------+----------------+-------------+ | 287 | | Device | Device Access | Access Policy | Log Audit | | 288 | | Management | +-------------+ | Management | | | 289 | | | | Unique id | | | | | 290 | | | | information | | | | | 291 | | +-----+-------+ | +-------------+ | +------------+ | | | 292 | | | IP | Port& | | | Trusted | | | IP&MAC | | +---------+ | | 293 | | | |Service| | |communication| | +------------+ | |Exception| | | 294 | | +-------------+ | | protocol | | |IP&MAC&Brand| | +---------+ | | 295 | | |Type | Brand | | +-------------+ | +------------+ | |Behavior | | | 296 | | +-------------+ | | Certificate | | |IP&MAC&Brand| | +---------+ | | 297 | | |Model| MAC | | | access | | | &Model | | |Operation| | | 298 | | +-------------+ | +-------------+ | +------------+ | +---------+ | | 299 | +------------------------------------------------------------------+ | 300 +----------------------------------------------------------------------+ 301 Indirect ^ ^ ^ Direct 302 connection| | | connection 303 +----------------------------------------------------------------------+ 304 | Sensing & +-----------+ | | | 305 | Controlling |IoT Gateway| | | | 306 | Domain +------^----+ | | | 307 | | | | | 308 | +------------------------------------------------------------------+ | 309 | | +---------+ +---------+ +--------+ | +------+ | +------+ | | 310 | | |RS-485 | |Zigbee | |IP/WIFI/| | |Video | | |Smart | | | 311 | | |RS232 | |Lora and | |5G/4G | | |and | | |IP | | | 312 | | |and other| |other | |smart +--+ |Audio +-+ |Camera| | | 313 | | |wired | |wireless | |device | |device| +------+ | | 314 | | |terminals| |terminals| +--------+ |RFID | | | 315 | | +---------+ +---------+ +------+ | | 316 | +------------------------------------------------------------------+ | 317 +----------------------------------------------------------------------+ 319 Figure 2: Framework of Secure Access Management for Smart Terminals 321 5.1.1. Sensing & Controlling Domain 323 Smart Terminals: include RS-485, RS-232 and other wired terminals, 324 zigberr, Lora and other wireless terminals, smart IP, WiFi, 5g, 4G 325 smart devcie, audio and video device and RFID, etc. 327 IOT Gateway: Be able to store data, compute and transform protocol, 328 an entity used to connect smart terminals and terminals of upper 329 layer. 331 Among them, smart terminals can be directly connected with the 332 access&management domain, or indirectly connected with the access and 333 management domain through the Internet of things gateway. 335 5.1.2. Access & Management Domain 337 Access and management domain is the core, which is used to manage and 338 control the access of smart terminals, including four parts: device 339 management, device access, access policy management and log audit. 341 The contents of each part clarified as follows: 343 Device Management: It mainly manages device asset information, 344 including IP address, MAC address, type of device, brand, model, open 345 port and service of smart terminals. 347 Device Access: Refers to the device access mode supported by smart 348 terminals, including access based on unique identification 349 information of smart terminal (the composition of unique 350 identification information of device can be one or more sets of 351 device asset information managed by device), access based on trusted 352 communication protocol of smart terminal and access based on 353 certificate authentication. 355 Access Policy Management: Refers to the access policy management 356 based on the unique identification information of smart terminals, 357 including: IP, MAC access policy; IP, MAC, manufacturer access 358 policy; IP, MAC, manufacturer, model access policy. 360 Log Audit: Used to record, store and audit the log information 361 generated in the access process of smart terminals, including 362 exception log audit, behavior log audit and operation log audit. 364 5.1.3. Application & Service Domain 366 Application & service domain is the core business system, which 367 provides informational application services for information 368 collecting, exchanging and processing. The information provided by 369 the smart terminals that verified by the access & management domain 370 to ensure security and stability of the system. 372 5.1.4. User Domain 374 User domain is the users of smart terminals, they can directly access 375 the core business system in the application & service domain, and 376 access & management domain to view the access condition of smart 377 terminals and manage them. 379 5.2. Requirements for Device Access 381 5.2.1. Requirements for Devices Access Authentication Identity 382 Information 384 The identity information of devices access authentication should 385 include one or more of the following characteristics: 387 1. IP address 389 2. address 391 3. brand 393 4. type 395 5. model 397 6. firmware version 399 5.2.2. Requirements for Access Status of Devices 401 There should be at least four types of access status: 403 1. Online: The device that has authenticated and is working well. 405 2. Offline: The device that has authenticated but is not connected 406 to network. 408 3. Personate: A device that can not authenticate and its 409 authentication information is the same as other authenticated 410 device. 412 4. Illegal connection: A device that fails to authenticate and its 413 authentication information is different from other authenticated 414 device. 416 5.2.3. Recommendation of Access Policy 418 1. The device access policy can be at least five combinations: 420 a. IP + MAC 422 b. IP + Mac + manufacturer 424 c. IP + Mac + manufacturer + model 426 d. IP + Mac + manufacturer + model + type 428 e. IP + Mac + manufacturer + model + type + firmware version 430 2. Quickly discover the access of personate and illegal connection, 431 and prevent illegal control of devices. 433 3. The configuration of access policy can be done manually and 434 automatically 436 4. Device access policy can be customized as any combination of 437 recommendation of access policy shown in requirement 3. 439 5.3. Requirements for Management of terminals 441 Device management requires to monitor status of terminals in real 442 time, to profile terminals, to identify and manage applications 443 running on terminals, to identify and manage asset information of 444 terminals, and to manage IP addresses of terminals. 446 1. Requirements for condition monitoring and management of terminals 448 1. It should be able to monitor the offline and online status of 449 smart terminals in real time 451 2. It should be able to discover whether there is a weak 452 password information of the smart terminal 454 3. It should be able to discover the risky ports of smart 455 terminals 457 4. It should be able to alert offline devices or the devices 458 with weak passwords and risky ports 460 2. Requirements for the management of terminal profiling 462 1. It should be able to visualize information of smart 463 terminals, including device type, IP address, open ports, 464 etc. 466 3. Requirements for the management of identifying applications 468 1. It should be able to automatically identify and manage the 469 device's open services and service ports 471 2. It should be able to automatically discover and identify the 472 application system of B/S architecture or CS architecture 473 running in the network where the IoT smart terminal is 474 located, including: service IP, service port, application 475 name 477 4. Requirements for the management of identifying asset information 478 of the device 480 1. It should be able to manage IP address, MAC address, device 481 manufacturer, device model, device type, device firmware 482 version number, device open port, and device online time for 483 smart terminals 485 2. It should be able to manage the communication protocol 486 information of geographic location information of terminals 488 5.4. Requirements for Access Log Audit 490 Access log audit requires the ability to audit all types of 491 operations, such as abnormal and malicious behavior of access. 493 1. It should record abnormal behavior log information of access in 494 real time and to provide analysis and audit functions. 496 2. It should record malicious behavior log information of access in 497 real time and to provide analysis and audit functions. 499 3. It should record the management, access and blocking of access 500 devices and other types of operations in real time , and can 501 provide analysis and audit functions 503 6. Security Considerations 505 This entire memo deals with security issues. 507 7. IANA Considerations 509 This documents has no IANA actions. 511 8. Informative References 513 [BACNET] American Society of Heating, Refrigerating and Air- 514 Conditioning Engineers (ASHRAE), "BACnet", 515 . 517 [CSA] "Security Guidance for Early Adopters of the Internet of 518 Things (IoT)", 2015, 519 . 523 [DALI] "DALI Explained", . 525 [DHS] "Strategic Principles For Securing the Internet of Things 526 (IoT)", 2016, 527 . 531 [GSMA] "GSMA IoT Security Guidelines and Assessment", 532 . 535 [ISO88021X] 536 ISO/IEC/IEEE, "Telecommunications and exchange between 537 information technology systems - Requirements for local 538 and metropolitan area networks - Part 1X: Port-based 539 network access control". 541 [ISOIEC23941] 542 ISO/IEC, "IoT management and control device control 543 protocol". 545 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 546 Levkowetz, Ed., "Extensible Authentication Protocol 547 (EAP)", DOI 10.17487/RFC3748, June 2004, 548 . 550 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 551 Kerberos Network Authentication Service (V5)", 552 DOI 10.17487/RFC4120, July 2005, 553 . 555 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 556 Authentication and Security Layer (SASL)", 557 DOI 10.17487/RFC4422, June 2006, 558 . 560 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 561 Security Version 1.2", DOI 10.17487/RFC6347, January 2012, 562 . 564 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 565 Kivinen, "Internet Key Exchange Protocol Version 2 566 (IKEv2)", DOI 10.17487/RFC7296, October 2014, 567 . 569 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 570 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 571 DOI 10.17487/RFC7401, April 2015, 572 . 574 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 575 Version 1.3", DOI 10.17487/RFC8446, August 2018, 576 . 578 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 579 Things (IoT) Security: State of the Art and Challenges", 580 DOI 10.17487/RFC8576, April 2019, 581 . 583 [ZB] "Zigbee Alliance", 2020, . 585 Authors' Addresses 587 Bin Wang (editor) 588 Hikvision 589 555 Qianmo Road, Binjiang District 590 Hangzhou 591 310051 592 China 594 Phone: +86 571 8847 3644 595 Email: wbin2006@gmail.com 596 Song Liu (editor) 597 Hikvision 598 555 Qianmo Road, Binjiang District 599 Hangzhou 600 310051 601 China 603 Phone: +86 571 8847 3644 604 Email: achelics@gmail.com 606 Li Wan (editor) 607 Hikvision 608 555 Qianmo Road, Binjiang District 609 Hangzhou 610 310051 611 China 613 Phone: +86 571 8847 3644 614 Email: dzwanli@126.com 616 Jun Li (editor) 617 CICS-CERT 618 No.35, Lugu Rd., Shijingshan Dist 619 Beijing 620 100040 621 China 623 Email: lijun@cics-cert.org.cn 625 Xing Wang (editor) 626 Hikvision 627 555 Qianmo Road, Binjiang District 628 Hangzhou 629 310051 630 China 632 Phone: +86 571 8847 3644 633 Email: xing.wang.email@gmail.com