6TiSCH S. Chasko Internet-Draft L+G Intended status: Informational S. Das Expires: September 23, 2014 ACS R. Marin-Lopez University of Murcia Y. Ohba, Ed. Toshiba P. Thubert cisco A. Yegin Samsung March 22, 2014 Security Framework and Key Management Protocol Requirements for 6TiSCH draft-ohba-6tisch-security-01 Abstract 6TiSCH is enabling IPv6 over the TSCH mode of the IEEE802.15.4e standard that allows the IEEE 802.15.4e TSCH wireless networks and nodes to connect to the backbone network via layer 3 meshes over IPv6. In this operation of network architecture, understanding the security framework and requirements for key management protocols are critical. This document discusses such security framework and key management protocol requirements by highlighting different phases of key management in which a new node can securely join the network under the purview of overall 6TiSCH architecture. 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 http://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." This Internet-Draft will expire on September 23, 2014. Chasko, et al. Expires September 23, 2014 [Page 1] Internet-Draft 6tisch-security March 2014 Copyright Notice Copyright (c) 2014 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Security Framework . . . . . . . . . . . . . . . . . . . . . 3 4. KMP requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Phase-1 KMP requirements . . . . . . . . . . . . . . . . 7 4.2. Phase-2 KMP requirements . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. External Informative References . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The emergence of radio technology enabled a large variety of new types of devices to be interconnected, at a very low marginal cost compared to wire, at any range from Near Field to interplanetary distances, and in circumstances where wiring could be less than practical, for instance rotating devices. At the same time, a new breed of Time Sensitive Networks is being developed to enable traffic that is highly sensitive to jitter and quite sensitive to latency. Such traffic is not limited to voice and video, but also includes command and control operations such as found in industrial automation or in-vehicular sensors and actuators. 6TiSCH aims at providing an interoperable standard with new capabilities, both in terms of scalability (number of IPv6 devices in a single subnet) and in terms of guarantees (delivery and Chasko, et al. Expires September 23, 2014 [Page 2] Internet-Draft 6tisch-security March 2014 timeliness). Both the ISA100.11a [ISA100] and Wireless HART [WirelessHART] protocols are gaining acceptance in the automation industry and demonstrate that a level of determinism can be achieved on a wireless medium with adequate guarantees for low speed control loops, used in mission critical Process Control applications. For industrial applications, security is not an option and a power efficient authentication mechanism is strictly required. For other usages such as rust control, intrusion detection or seismic activity monitoring, the capability to correlate inputs from multiple sources can be critical, and the value of the network directly augments with the number of connected devices. In order to scale to appropriate levels, the need for spatial reuse of the spectrum often implies routing capabilities over short range radios. Proprietary variations demonstrate that RPL can scale to multiple thousands of devices, but at the same time expose a new challenge for security that must enable deployments of any scale with security requirements that may vary widely. If the cost of the security in terms of network operations and system resources depends on that degree of security, then 6TiSCH should enable different profiles that can match different requirements and capabilities. Since 6TiSCH enables layer 3 meshes over IPv6, key management protocols defined at layer 3 or above can be directly applied to the networks and nodes that join the mesh network. However, understanding the security framework and requirements for key management protocols are critical before adopting an existing protocol or designing a new one that fits the operational needs for these types of networks. This document details such operations and discusses the security framework with requirements within the context of 6TiSCH architecture [I-D.ietf-6tisch-architecture]. 2. Acronyms In addition to the acronyms defined in [I-D.ietf-6tisch-terminology], the following acronyms are used in this document. KMP: Key Management Protocol SA: Security Association MAC: Media Access Control 3. Security Framework This section describes a security framework consisting of four phases of key management operation as shown in Figure 1. It is expected that each node in a mesh network runs through the four phases. Chasko, et al. Expires September 23, 2014 [Page 3] Internet-Draft 6tisch-security March 2014 +---------------------------------+ | Phase-0 (Implanting) | +---------------------------------+ | v +---------------------------------+ | Phase-1 (Initialization) | +---------------------------------+ | v +---------------------------------+ | Phase-2 (Link Establishment) | +---------------------------------+ | v +---------------------------------+ | Phase-3 (Operational) | +---------------------------------+ Figure 1: 4-Phase Key Management Model Each phase is explained as follows. o Phase-0 (Implanting Phase): In this phase, a node installs credentials used for subsequent phases in a physically secure and managed location before the node is placed to where it is expected to operate. Details on how Phase-0 can be achieved are outside the scope of this document. o Phase-1 (Initialization Phase): Phase-1 (Initializing Phase): In this phase, an authentication and key Establishment protocol called a Phase-1 KMP is conducted either between nodes or between a node and the authentication/authorization server using Phase-1 credentials. Both symmetric and asymmetric key credentials can be used as Phase-1 credentials. When phase-1 KMP is run between a node and an authentication/authorization server, a node (re)install credentials used for subsequent phases (e.g., Phase 2 and 3). The credentials installed during Phase-1 include Phase-2 credentials and Phase-3 credentials, and may also include long- term Phase-1 credentials if the initial Phase-1 credentials are intended for one-time use such as a temporary PIN. The Phase-1 credentials usually have longer lifetime than Phase-2 and Phase-3 credentials so that Phase-2 and Phase-3 credentials can be renewed using the Phase-1 credentials. When the authentication server is multiple hops away from the node, mutual authentication between the node and the authentication server may be conducted via a neighboring node acting as an authentication relay. There may be no link-layer security available between the node and its Chasko, et al. Expires September 23, 2014 [Page 4] Internet-Draft 6tisch-security March 2014 neighboring node in this phase. An authentication/authorization server is typically (but is not necessarily) co-located with the coordinator of the mesh network. Contacting the authentication/ authorization server is optional if Phase-2 credentials are installed during Phase-0 and do not need to be updated. o Phase-2 (Link Establishment Phase): In this phase, the node performs mutual authentication with its neighboring node using the Phase-2 credentials to establish SAs between adjacent nodes for protecting 802.15.4 MAC frames. The authentication and key establishment protocol used in this phase is referred as a Phase-2 KMP or a link establishment KMP. For highly scalable mesh networks consisting of thousands of mesh nodes, certificates are used as the Phase-2 credentials. The SA of a link between node i and node j maintains link-layer keys, i.e., 128-bit keys used in AES-CCM* [IEEE802154] mode, a variant of the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode, for encryption, authentication or authenticated encryption of 802.15.4 frames. In the following example, K_i denotes a link-layer key for protecting broadcast MAC frames originated at node i. K_ij denotes a link-layer key for protecting unicast MAC frames originated at node i and destined for node j. There are several ways link-layer keys can be formed, for example, the models are: 1. Per-Network key model K_ij=K_ji=K_i=K_j=K for all i, j (i!=j) 2. Per-Neighbor key model K_ij!=K_ji, K_ij=K_i, K_i!=K_j for all i,j (i!=j) 3. Pair-Wise key model K_ij=K_ji, Kij!=Kik, K_i!=K_j, for all i,j (i!=j, j!=k) In model 1, a network key that is shared by all nodes in the network is used for enciphering and deciphering outgoing and incoming unicast and broadcast MAC frames at any node. In model 2, each node has a unique key for enciphering outgoing unicast and broadcast MAC frames originated at the node and its neighbors use the key for deciphering incoming unicast and broadcast MAC frames received from that node. In model 3, each pair of nodes has a unique key for enciphering and deciphering unicast frames exchanged between them. In addition, each node in model 3 has a unique key for enciphering outgoing broadcast MAC frames originated at the node and its neighbors use the key for deciphering incoming broadcast MAC frames received from that node. Chasko, et al. Expires September 23, 2014 [Page 5] Internet-Draft 6tisch-security March 2014 One model may be sufficient among these three models depending on the required security level and the number of keys maintained by each node. o Phase-3 (Operational Phase): In this phase, the node is able to run various higher-layer protocols over IP over an established secure link. Additional authentication, authorization and key establishment may take place for the higher-layer protocols using Phase-3 credentials. A node in Phase-3 is able to process Phase-1 and Phase-2 KMPs. Example use cases are: * A Phase-3 node can initiate a Phase-1 KMP to update its Phase-2 or Phase-3 credentials. * A Phase-3 node can forward Phase-1 KMP messages originated from or destined for a Phase-1 node that is joining the mesh network through the Phase-3 node. * A Phase-3 node can initiate a Phase 2 KMP to establish a new link with a newly discovered neighbor node. Figure 2 shows an example sequence for authentication and authorization message exchanges for Phase-1 and Phase-2. The example sequence is explained as follows: 1. Initially all nodes are in Phase-1. 2. Nodes B and C run Phase-1 KMP with Node A which is acting as the authentication/authorization server) to obtain Phase-2 and Phase-3 credentials. 3. Nodes B and C run Phase-2 KMP with Node A. 4. Nodes D and E run Phase-1 KMP using Node B as an authentication relay. (Alternatively, Node E may use Node C as an authentication relay.) 5. Node D runs Phase-2 KMP with Node B. Node E runs Phase-2 KMP with Nodes B and C. 6. All nodes are operational. Chasko, et al. Expires September 23, 2014 [Page 6] Internet-Draft 6tisch-security March 2014 N)s - Node N is running Phase-1 KMP as a server N)c - Node N is running Phase-1 KMP as a client N)r - Node N is running Phase-1 KMP as a relay N)) - Node N is running Phase-2 KMP . .. ... N, N, N - Node N is in Phase-1, -2 and -3, respectively . . .. ... ... ... A A)s A)) A)s A A / \ / \ / \ / \ / \ . . . . .. .. ... ... ... ... ... ... B C B)c C)c B)) C)) B)r C B)) C)) B C / \ / / \ / / \ / . . . . . . . . .. .. ... ... D E D E D E D)c E)c D)) E)) D E (1) -> (2) -> (3) -> (4) -> (5) -> (6) Figure 2: Example Sequence 4. KMP requirements Since Phase-3 KMP requirements would depend on application protocols, we focus on Phase-1 and Phase-2 KMP requirements. 4.1. Phase-1 KMP requirements Requirements on Phase-1 KMP are listed below. R1-1: Phase-1 KMP MUST support mutual authentication. R1-2: Phase-1 KMP MUST support stateless authentication relay operation. R1-3:s Phase-1 KMP MUST support secure credential distribution. 4.2. Phase-2 KMP requirements Requirements on Phase-2 KMP are listed below. R2-1: Phase-2 KMP Nodes MUST mutually authenticate each other before establishing a link and forming a mesh network. An authentication/ authorization server is not a requirement for this operation. R2-2: Phase-2 KMP authentication credentials MAY be pre-provisioned or MAY be obtained via Phase-1 KMP. R2-3: Phase-2 KMP authentication credentials MUST have a lifetime. Chasko, et al. Expires September 23, 2014 [Page 7] Internet-Draft 6tisch-security March 2014 R2-4: Phase-2 KMP MUST support certificates for scalable operation. R2-5: Phase-2 KMP message exchanges MUST be integrity and replay protected after successful authentication. R2-6: Phase-2 KMP MUST have the capability to establish security association and unicast session keys after successful authentication to protect unicast MAC frames between nodes. R2-7: Phase-2 KMP MUST have the capability to establish security association and broadcast session keys after successful authentication to protect broadcast MAC frames between nodes. R2-8: Phase-2 KMP MUST support confidentiality to distribute the broadcast session keys securely. 5. Security Considerations In this section, security issues that can potentially impact the operation of IEEE 802.15.4e TSCH MAC are described. In TSCH MAC, time synchronization and channel hopping information are advertised in Enhanced Beacon (EB) frames [I-D.ietf-6tisch-terminology]. The advertised information is used by mesh nodes to determine the timeslots available for transmission and reception of MAC frames. A rogue node can inject forged EB frames and can cause replay and DoS attacks to TSCH MAC operation. To mitigate such attacks, all EB frames MUST be integrity protected. While it is possible to use a pre-installed static key for protecting EB frames to every node, the static key becomes vulnerable when the associated MAC frame counter continues to be used after the frame counter wraps. Therefore, the 6TiSCH solution MUST provide a mechanism by which mesh nodes can use the available time slots to run Phase-1 and Phase-2 KMPs and provide integrity protection to EB frames. For use cases where certificates are used for a Phase-1 KMP, pre- provisioning of absolute time to devices from a trustable time source using an out-of-band (OOB) mechanism is a general requirement. Accuracy of time depends on the OOB mechanism, including use of the time hard-coded into the installed firmware. The less time accuracy is, the more attack opportunities during Phase-1. In addition, use of CRL is another requirement for Phase-1 KMP employing certificates to avoid an attack that can happen by a compromised server or CA certificate. Chasko, et al. Expires September 23, 2014 [Page 8] Internet-Draft 6tisch-security March 2014 6. IANA Considerations There is no IANA action required for this document. 7. Acknowledgments We would like to thank Thomas Watteyne, Jonathan Simon, Maria Rita Palattella and Rene Struik for their valuable comments. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-terminology-01 (work in progress), February 2014. [I-D.ietf-6tisch-architecture] Thubert, P., Watteyne, T., and R. Assimiti, "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-architecture-01 (work in progress), February 2014. 8.2. External Informative References [IEEE802154] IEEE standard for Information Technology, "IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks", June 2011. [ISA100] ANSI/ISA-100.11a-2011, "Wireless systems for industrial automation: Process control and related applications", 2011. [WirelessHART] IEC 62591 Ed. 1.0 b:2010, "Industrial communication networks - Wireless communication network and communication profiles - WirelessHART", 2010. Chasko, et al. Expires September 23, 2014 [Page 9] Internet-Draft 6tisch-security March 2014 Authors' Addresses Stephen Chasko Landis+Gyr 3000 Mill Creek Ave. Alpharetta, GA 30022 USA Email: Stephen.Chasko@landisgyr.com Subir Das Applied Communication Sciences 1 Telcordia Drive Piscataway, NJ 08854 USA Email: sdas@appcomsci.com Rafa Marin-Lopez University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain Phone: +34 868 88 85 01 Email: rafa@um.es Yoshihiro Ohba (editor) Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan Phone: +81 44 549 2127 Email: yoshihiro.ohba@toshiba.co.jp Chasko, et al. Expires September 23, 2014 [Page 10] Internet-Draft 6tisch-security March 2014 Pascal Thubert Cisco Systems, Inc Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 497 23 26 34 Email: pthubert@cisco.com Alper Yegin Samsung Istanbul Turkey Email: alper.yegin@yegin.org Chasko, et al. Expires September 23, 2014 [Page 11]