idnits 2.17.00 (12 Aug 2021) /tmp/idnits17316/draft-ohba-6tisch-security-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 22, 2014) is 2975 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ISA100' is mentioned on line 415, but not defined == Missing Reference: 'WirelessHART' is mentioned on line 419, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 409, but not defined == Unused Reference: 'RFC2119' is defined on line 392, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-01 == Outdated reference: draft-ietf-6tisch-architecture has been published as RFC 9030 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH S. Chasko 3 Internet-Draft L+G 4 Intended status: Informational S. Das 5 Expires: September 23, 2014 ACS 6 R. Marin-Lopez 7 University of Murcia 8 Y. Ohba, Ed. 9 Toshiba 10 P. Thubert 11 cisco 12 A. Yegin 13 Samsung 14 March 22, 2014 16 Security Framework and Key Management Protocol Requirements for 6TiSCH 17 draft-ohba-6tisch-security-01 19 Abstract 21 6TiSCH is enabling IPv6 over the TSCH mode of the IEEE802.15.4e 22 standard that allows the IEEE 802.15.4e TSCH wireless networks and 23 nodes to connect to the backbone network via layer 3 meshes over 24 IPv6. In this operation of network architecture, understanding the 25 security framework and requirements for key management protocols are 26 critical. This document discusses such security framework and key 27 management protocol requirements by highlighting different phases of 28 key management in which a new node can securely join the network 29 under the purview of overall 6TiSCH architecture. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 23, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Security Framework . . . . . . . . . . . . . . . . . . . . . 3 68 4. KMP requirements . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Phase-1 KMP requirements . . . . . . . . . . . . . . . . 7 70 4.2. Phase-2 KMP requirements . . . . . . . . . . . . . . . . 7 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 8.2. External Informative References . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 The emergence of radio technology enabled a large variety of new 82 types of devices to be interconnected, at a very low marginal cost 83 compared to wire, at any range from Near Field to interplanetary 84 distances, and in circumstances where wiring could be less than 85 practical, for instance rotating devices. 87 At the same time, a new breed of Time Sensitive Networks is being 88 developed to enable traffic that is highly sensitive to jitter and 89 quite sensitive to latency. Such traffic is not limited to voice and 90 video, but also includes command and control operations such as found 91 in industrial automation or in-vehicular sensors and actuators. 93 6TiSCH aims at providing an interoperable standard with new 94 capabilities, both in terms of scalability (number of IPv6 devices in 95 a single subnet) and in terms of guarantees (delivery and 96 timeliness). Both the ISA100.11a [ISA100] and Wireless HART 97 [WirelessHART] protocols are gaining acceptance in the automation 98 industry and demonstrate that a level of determinism can be achieved 99 on a wireless medium with adequate guarantees for low speed control 100 loops, used in mission critical Process Control applications. For 101 industrial applications, security is not an option and a power 102 efficient authentication mechanism is strictly required. 104 For other usages such as rust control, intrusion detection or seismic 105 activity monitoring, the capability to correlate inputs from multiple 106 sources can be critical, and the value of the network directly 107 augments with the number of connected devices. In order to scale to 108 appropriate levels, the need for spatial reuse of the spectrum often 109 implies routing capabilities over short range radios. Proprietary 110 variations demonstrate that RPL can scale to multiple thousands of 111 devices, but at the same time expose a new challenge for security 112 that must enable deployments of any scale with security requirements 113 that may vary widely. If the cost of the security in terms of 114 network operations and system resources depends on that degree of 115 security, then 6TiSCH should enable different profiles that can match 116 different requirements and capabilities. 118 Since 6TiSCH enables layer 3 meshes over IPv6, key management 119 protocols defined at layer 3 or above can be directly applied to the 120 networks and nodes that join the mesh network. However, 121 understanding the security framework and requirements for key 122 management protocols are critical before adopting an existing 123 protocol or designing a new one that fits the operational needs for 124 these types of networks. This document details such operations and 125 discusses the security framework with requirements within the context 126 of 6TiSCH architecture [I-D.ietf-6tisch-architecture]. 128 2. Acronyms 130 In addition to the acronyms defined in [I-D.ietf-6tisch-terminology], 131 the following acronyms are used in this document. 133 KMP: Key Management Protocol 135 SA: Security Association 137 MAC: Media Access Control 139 3. Security Framework 141 This section describes a security framework consisting of four phases 142 of key management operation as shown in Figure 1. It is expected 143 that each node in a mesh network runs through the four phases. 145 +---------------------------------+ 146 | Phase-0 (Implanting) | 147 +---------------------------------+ 148 | 149 v 150 +---------------------------------+ 151 | Phase-1 (Initialization) | 152 +---------------------------------+ 153 | 154 v 155 +---------------------------------+ 156 | Phase-2 (Link Establishment) | 157 +---------------------------------+ 158 | 159 v 160 +---------------------------------+ 161 | Phase-3 (Operational) | 162 +---------------------------------+ 164 Figure 1: 4-Phase Key Management Model 166 Each phase is explained as follows. 168 o Phase-0 (Implanting Phase): In this phase, a node installs 169 credentials used for subsequent phases in a physically secure and 170 managed location before the node is placed to where it is expected 171 to operate. Details on how Phase-0 can be achieved are outside 172 the scope of this document. 174 o Phase-1 (Initialization Phase): Phase-1 (Initializing Phase): In 175 this phase, an authentication and key Establishment protocol 176 called a Phase-1 KMP is conducted either between nodes or between 177 a node and the authentication/authorization server using Phase-1 178 credentials. Both symmetric and asymmetric key credentials can be 179 used as Phase-1 credentials. When phase-1 KMP is run between a 180 node and an authentication/authorization server, a node 181 (re)install credentials used for subsequent phases (e.g., Phase 2 182 and 3). The credentials installed during Phase-1 include Phase-2 183 credentials and Phase-3 credentials, and may also include long- 184 term Phase-1 credentials if the initial Phase-1 credentials are 185 intended for one-time use such as a temporary PIN. The Phase-1 186 credentials usually have longer lifetime than Phase-2 and Phase-3 187 credentials so that Phase-2 and Phase-3 credentials can be renewed 188 using the Phase-1 credentials. When the authentication server is 189 multiple hops away from the node, mutual authentication between 190 the node and the authentication server may be conducted via a 191 neighboring node acting as an authentication relay. There may be 192 no link-layer security available between the node and its 193 neighboring node in this phase. An authentication/authorization 194 server is typically (but is not necessarily) co-located with the 195 coordinator of the mesh network. Contacting the authentication/ 196 authorization server is optional if Phase-2 credentials are 197 installed during Phase-0 and do not need to be updated. 199 o Phase-2 (Link Establishment Phase): In this phase, the node 200 performs mutual authentication with its neighboring node using the 201 Phase-2 credentials to establish SAs between adjacent nodes for 202 protecting 802.15.4 MAC frames. The authentication and key 203 establishment protocol used in this phase is referred as a Phase-2 204 KMP or a link establishment KMP. For highly scalable mesh 205 networks consisting of thousands of mesh nodes, certificates are 206 used as the Phase-2 credentials. The SA of a link between node i 207 and node j maintains link-layer keys, i.e., 128-bit keys used in 208 AES-CCM* [IEEE802154] mode, a variant of the Counter with Cipher 209 Block Chaining - Message Authentication Code (CBC-MAC) Mode, for 210 encryption, authentication or authenticated encryption of 802.15.4 211 frames. In the following example, K_i denotes a link-layer key 212 for protecting broadcast MAC frames originated at node i. K_ij 213 denotes a link-layer key for protecting unicast MAC frames 214 originated at node i and destined for node j. There are several 215 ways link-layer keys can be formed, for example, the models are: 217 1. Per-Network key model 219 K_ij=K_ji=K_i=K_j=K for all i, j (i!=j) 221 2. Per-Neighbor key model 223 K_ij!=K_ji, K_ij=K_i, K_i!=K_j for all i,j (i!=j) 225 3. Pair-Wise key model 227 K_ij=K_ji, Kij!=Kik, K_i!=K_j, for all i,j (i!=j, j!=k) 229 In model 1, a network key that is shared by all nodes in the 230 network is used for enciphering and deciphering outgoing and 231 incoming unicast and broadcast MAC frames at any node. In model 232 2, each node has a unique key for enciphering outgoing unicast and 233 broadcast MAC frames originated at the node and its neighbors use 234 the key for deciphering incoming unicast and broadcast MAC frames 235 received from that node. In model 3, each pair of nodes has a 236 unique key for enciphering and deciphering unicast frames 237 exchanged between them. In addition, each node in model 3 has a 238 unique key for enciphering outgoing broadcast MAC frames 239 originated at the node and its neighbors use the key for 240 deciphering incoming broadcast MAC frames received from that node. 242 One model may be sufficient among these three models depending on 243 the required security level and the number of keys maintained by 244 each node. 246 o Phase-3 (Operational Phase): In this phase, the node is able to 247 run various higher-layer protocols over IP over an established 248 secure link. Additional authentication, authorization and key 249 establishment may take place for the higher-layer protocols using 250 Phase-3 credentials. A node in Phase-3 is able to process Phase-1 251 and Phase-2 KMPs. Example use cases are: 253 * A Phase-3 node can initiate a Phase-1 KMP to update its Phase-2 254 or Phase-3 credentials. 256 * A Phase-3 node can forward Phase-1 KMP messages originated from 257 or destined for a Phase-1 node that is joining the mesh network 258 through the Phase-3 node. 260 * A Phase-3 node can initiate a Phase 2 KMP to establish a new 261 link with a newly discovered neighbor node. 263 Figure 2 shows an example sequence for authentication and 264 authorization message exchanges for Phase-1 and Phase-2. The example 265 sequence is explained as follows: 267 1. Initially all nodes are in Phase-1. 269 2. Nodes B and C run Phase-1 KMP with Node A which is acting as the 270 authentication/authorization server) to obtain Phase-2 and 271 Phase-3 credentials. 273 3. Nodes B and C run Phase-2 KMP with Node A. 275 4. Nodes D and E run Phase-1 KMP using Node B as an authentication 276 relay. (Alternatively, Node E may use Node C as an 277 authentication relay.) 279 5. Node D runs Phase-2 KMP with Node B. Node E runs Phase-2 KMP 280 with Nodes B and C. 282 6. All nodes are operational. 284 N)s - Node N is running Phase-1 KMP as a server 285 N)c - Node N is running Phase-1 KMP as a client 286 N)r - Node N is running Phase-1 KMP as a relay 287 N)) - Node N is running Phase-2 KMP 288 . .. ... 289 N, N, N - Node N is in Phase-1, -2 and -3, respectively 291 . . .. ... ... ... 292 A A)s A)) A)s A A 293 / \ / \ / \ / \ / \ 294 . . . . .. .. ... ... ... ... ... ... 295 B C B)c C)c B)) C)) B)r C B)) C)) B C 296 / \ / / \ / / \ / 297 . . . . . . . . .. .. ... ... 298 D E D E D E D)c E)c D)) E)) D E 300 (1) -> (2) -> (3) -> (4) -> (5) -> (6) 302 Figure 2: Example Sequence 304 4. KMP requirements 306 Since Phase-3 KMP requirements would depend on application protocols, 307 we focus on Phase-1 and Phase-2 KMP requirements. 309 4.1. Phase-1 KMP requirements 311 Requirements on Phase-1 KMP are listed below. 313 R1-1: Phase-1 KMP MUST support mutual authentication. 315 R1-2: Phase-1 KMP MUST support stateless authentication relay 316 operation. 318 R1-3:s Phase-1 KMP MUST support secure credential distribution. 320 4.2. Phase-2 KMP requirements 322 Requirements on Phase-2 KMP are listed below. 324 R2-1: Phase-2 KMP Nodes MUST mutually authenticate each other before 325 establishing a link and forming a mesh network. An authentication/ 326 authorization server is not a requirement for this operation. 328 R2-2: Phase-2 KMP authentication credentials MAY be pre-provisioned 329 or MAY be obtained via Phase-1 KMP. 331 R2-3: Phase-2 KMP authentication credentials MUST have a lifetime. 333 R2-4: Phase-2 KMP MUST support certificates for scalable operation. 335 R2-5: Phase-2 KMP message exchanges MUST be integrity and replay 336 protected after successful authentication. 338 R2-6: Phase-2 KMP MUST have the capability to establish security 339 association and unicast session keys after successful authentication 340 to protect unicast MAC frames between nodes. 342 R2-7: Phase-2 KMP MUST have the capability to establish security 343 association and broadcast session keys after successful 344 authentication to protect broadcast MAC frames between nodes. 346 R2-8: Phase-2 KMP MUST support confidentiality to distribute the 347 broadcast session keys securely. 349 5. Security Considerations 351 In this section, security issues that can potentially impact the 352 operation of IEEE 802.15.4e TSCH MAC are described. 354 In TSCH MAC, time synchronization and channel hopping information are 355 advertised in Enhanced Beacon (EB) frames 356 [I-D.ietf-6tisch-terminology]. The advertised information is used by 357 mesh nodes to determine the timeslots available for transmission and 358 reception of MAC frames. A rogue node can inject forged EB frames 359 and can cause replay and DoS attacks to TSCH MAC operation. To 360 mitigate such attacks, all EB frames MUST be integrity protected. 361 While it is possible to use a pre-installed static key for protecting 362 EB frames to every node, the static key becomes vulnerable when the 363 associated MAC frame counter continues to be used after the frame 364 counter wraps. Therefore, the 6TiSCH solution MUST provide a 365 mechanism by which mesh nodes can use the available time slots to run 366 Phase-1 and Phase-2 KMPs and provide integrity protection to EB 367 frames. 369 For use cases where certificates are used for a Phase-1 KMP, pre- 370 provisioning of absolute time to devices from a trustable time source 371 using an out-of-band (OOB) mechanism is a general requirement. 372 Accuracy of time depends on the OOB mechanism, including use of the 373 time hard-coded into the installed firmware. The less time accuracy 374 is, the more attack opportunities during Phase-1. In addition, use 375 of CRL is another requirement for Phase-1 KMP employing certificates 376 to avoid an attack that can happen by a compromised server or CA 377 certificate. 379 6. IANA Considerations 381 There is no IANA action required for this document. 383 7. Acknowledgments 385 We would like to thank Thomas Watteyne, Jonathan Simon, Maria Rita 386 Palattella and Rene Struik for their valuable comments. 388 8. References 390 8.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [I-D.ietf-6tisch-terminology] 396 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 397 "Terminology in IPv6 over the TSCH mode of IEEE 398 802.15.4e", draft-ietf-6tisch-terminology-01 (work in 399 progress), February 2014. 401 [I-D.ietf-6tisch-architecture] 402 Thubert, P., Watteyne, T., and R. Assimiti, "An 403 Architecture for IPv6 over the TSCH mode of IEEE 404 802.15.4e", draft-ietf-6tisch-architecture-01 (work in 405 progress), February 2014. 407 8.2. External Informative References 409 [IEEE802154] 410 IEEE standard for Information Technology, "IEEE std. 411 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 412 and Physical Layer (PHY) Specifications for Low-Rate 413 Wireless Personal Area Networks", June 2011. 415 [ISA100] ANSI/ISA-100.11a-2011, "Wireless systems for industrial 416 automation: Process control and related applications", 417 2011. 419 [WirelessHART] 420 IEC 62591 Ed. 1.0 b:2010, "Industrial communication 421 networks - Wireless communication network and 422 communication profiles - WirelessHART", 2010. 424 Authors' Addresses 426 Stephen Chasko 427 Landis+Gyr 428 3000 Mill Creek Ave. 429 Alpharetta, GA 30022 430 USA 432 Email: Stephen.Chasko@landisgyr.com 434 Subir Das 435 Applied Communication Sciences 436 1 Telcordia Drive 437 Piscataway, NJ 08854 438 USA 440 Email: sdas@appcomsci.com 442 Rafa Marin-Lopez 443 University of Murcia 444 Campus de Espinardo S/N, Faculty of Computer Science 445 Murcia 30100 446 Spain 448 Phone: +34 868 88 85 01 449 Email: rafa@um.es 451 Yoshihiro Ohba (editor) 452 Toshiba Corporate Research and Development Center 453 1 Komukai-Toshiba-cho 454 Saiwai-ku, Kawasaki, Kanagawa 212-8582 455 Japan 457 Phone: +81 44 549 2127 458 Email: yoshihiro.ohba@toshiba.co.jp 459 Pascal Thubert 460 Cisco Systems, Inc 461 Village d'Entreprises Green Side 462 400, Avenue de Roumanille 463 Batiment T3 464 Biot - Sophia Antipolis 06410 465 FRANCE 467 Phone: +33 497 23 26 34 468 Email: pthubert@cisco.com 470 Alper Yegin 471 Samsung 472 Istanbul 473 Turkey 475 Email: alper.yegin@yegin.org