6TiSCH R. Struik Internet-Draft Struik Security Consultancy Intended status: Informational Y. Ohba Expires: April 30, 2015 Toshiba S. Das ACS October 27, 2014 6TiSCH Security Architectural Elements, Desired Protocol Properties, and Framework draft-struik-6tisch-security-architecture-elements-01 Abstract This document describes 6TiSCH security architectural elements with high level requirements and the security framework that are relevant for the design of the 6TiSCH security solution. 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 April 30, 2015. 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 Struik, et al. Expires April 30, 2015 [Page 1] Internet-Draft 6tisch-security October 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Security Architecture Elements . . . . . . . . . . . . . . . 2 1.1. Device Types and Roles . . . . . . . . . . . . . . . . . 2 1.2. Device Enrollment Phases . . . . . . . . . . . . . . . . 3 1.3. Desired Protocol Properties . . . . . . . . . . . . . . . 3 2. Security Framework . . . . . . . . . . . . . . . . . . . . . 4 2.1. Single-Stage Authentication Framework . . . . . . . . . . 4 2.2. Two-Stage Authentication Framework . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Security Architecture Elements 1.1. Device Types and Roles There are two types of devices (or nodes) that are involved in the 6TiSCH security architecture: end devices that intend to join the LLN (commonly known as joining nodes) and network devices that help the joining node to be authenticated and authorized by the network. From a security operations perspective, each device has a distinct role in the network. An end device has normally a client role, while the network device can be a proxy or assume a server role. A proxy is an intermediate node that helps the end device to establish a communication with the server. An end device may move in and out of networks (that may be alien to it) and may have little network management functionality on board. However, it usually does have the right credential required for initializing the network joining process. A proxy is an intermediary node that that may be more tied into a relatively stable infrastructure and may have more support for network management functionality and generally has reliable access to back-end systems of the network. A server provides stable, highly available infrastructure and network management support and is capable of authenticating and authorizing a joining node. It is important to note that a network node may assume multiple roles at the same time and that a particular role may be assumed by multiple network nodes. Furthermoe, the roles of a network node may change over time and can be dynamic in nature along a node or a network's lifecycle. Struik, et al. Expires April 30, 2015 [Page 2] Internet-Draft 6tisch-security October 2014 1.2. Device Enrollment Phases Device Authentication: The joining node and network node authenticate each other and establish a shared key, so as to ensure on-going authenticated communications. This may involve a server as a third party. Authorization: The network node decides on whether/how to authorize a joining node (if denied, this may result in loss of bandwidth). Authorization decisions may involve other nodes in the network. Configuration/Parameterization: The network node distributes configuration information to the joined node, such as scheduling information, IP address assignment information, and network policies. This may originate from other network devices, for which it acts as proxy. This step may also include distribution of information from the joining node to the network node and, more generally, synchronization of information between these entities. 1.3. Desired Protocol Properties Security-Related: 1. Parties executing a security protocol should be explicitly aware of its security properties; 2. Compromise of keys or devices should have limited effect on security of other devices or services; 3. Attacks should not have a serious impact beyond the time interval/space during/in which these take place; 4. Security protocols should minimize the impact of network outages, denial of service attacks. Communication Flows: 1. Security protocols should allow to be run locally, without third party involvement, wherever possibl; 2. The number of message exchanges for a joining device should be reduced; 3. Message exchanges should be structured so as to allow parallel execution of protocol steps, wherever possible. Computational Cost: Struik, et al. Expires April 30, 2015 [Page 3] Internet-Draft 6tisch-security October 2014 1. Security protocols should not impose an undue computational burden, especially on joining devices (An exception here may arise, when recovering from an event seriously impacting availability of the network.) Device Capabilities: 1. Dependency on an accurate time-keeping mechanism should be reduced; 2. Computational/time latency trade-offs should be tweaked to benefit those of joining node, wherever possible; 3. Dependency on "homogeneous trust models" should be reduced, without jeopardizing the security properties; 4. Dependency on on-board trusted platforms and trusted I/O interfaces should be reduced. 2. Security Framework 2.1. Single-Stage Authentication Framework In the single-stage authentication and authorization framework, depicted in Figure 1, it is assumed that devices have access to certificates and that entities have access to the root CA certificate of their communicating parties (initial set-up requirement). Under these assumptions, the authentication step of the device enrollment process does not require online involvement of a third party. Authentication is performed between the joining node and the proxy using their certificates. Upon successful authentication, link-layer keys are established between the client and the proxy. The proxy will deny bandwidth if authorization is not successful. After successful authentication and authorization, configuration information is exchanged. When a device rejoins the network in the same authorization domain, the authorization step could be omitted if the server distributes the authorization state for the device to the proxys when the device initially joined the network. However, this generally still requires the exchange of updated configuration information, e.g., related to time schedules and bandwidth allocation. Struik, et al. Expires April 30, 2015 [Page 4] Internet-Draft 6tisch-security October 2014 {joining node} {neighbor} {server, etc.} +---------+ +---------+ +---------+ | Node | | Proxy | +--| CA |e.g., certificate | A | | B | | +---------+ issuance +---------+ +---------+ | +---------+ | | +--|Authoriz.|e.g., membership |<----Beaconing------| | +---------+ test | | | +---------+ |<--Authentication-->| +--| Routing |e.g., IP address | |<--Authorization-->| +---------+ assignment |<-------------------| | +---------+ | | +--| Gateway |e.g., backbone, |------------------->| | +---------+ cloud | |<--Configuration-->| +---------+ |<-------------------| +--|Bandwidth|e.g., PCE +---------+ schedule . . . . . . Figure 1: Single-stage authentication/authorization 2.2. Two-Stage Authentication Framework In the two-stage authentication and authorization framework, depicted in Figure 2, a joining node performs two authentication and authorization steps. The first step, called Phase-1 authentication, is performed between the joining node and the server via a proxy. Phase-1 authentication and authorization uses deployment-specific enrollment credentials and results in issuance of a certificate by the CA to the joining node. Here, the node's certificate and root CA certificates of its communicating parties are distributed from the server to the client. The second step, called Phase-2 authentication, follows the successful completion of Phase-1 authentication and authorization. Phase-2 authentication is performed between the joining node and the proxy using their certificates. Upon successful authentication, link-layer keys are established between the joining node and the proxy. The proxy will deny bandwidth if Phase-2 authorization is not successful. After successful authentication and authorization, configuration information is exchanged. Once a joining node obtains a certificate for Phase-2 authentication, no additional Phase-1 authentication and authorization is needed, i.e., only Phase-2 authentication and the configuration are required for rejoining the network via a proxy under the same authorization Struik, et al. Expires April 30, 2015 [Page 5] Internet-Draft 6tisch-security October 2014 domain. This reduces to the single-stage authentication framework discussed in the previous section. {joining node} {neighbor} {server, etc.} +---------+ +---------+ +---------+ | Node | | Proxy | +--| CA |e.g., certificate | A | | B | | +---------+ issuance +---------+ +---------+ | +---------+ | | +--|Authoriz.|e.g., membership |<----Beaconing--------| | +---------+ test | | | +---------+ |<-Ph1 Authentication & Authorization->+--| Routing |e.g., IP address | | | +---------+ assignment |<-Ph2 Authentication->| | +---------+ | | +--| Gateway |e.g., backbone, |--------------------->| | +---------+ cloud | |<-- Config. -->| +---------+ |<---------------------| +--|Bandwidth|e.g., PCE schedule . . . +---------+ . . . Figure 2: Two-stage authentication/authorization 3. 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 authentication protocols and provide integrity protection to EB frames. For use cases where certificates are used for authentication, pre- provisioning of absolute time to devices from a trustable time source using an out-of-band (OOB) mechanism is a general requirement. Struik, et al. Expires April 30, 2015 [Page 6] Internet-Draft 6tisch-security October 2014 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 authentication employing certificates to avoid an attack that can happen by a compromised server or CA certificate. 4. IANA Considerations There is no IANA action required for this document. 5. Acknowledgments TBD. 6. 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-02 (work in progress), July 2014. Authors' Addresses Rene Struik Struik Security Consultancy Email: rstruik.ext@gmail.com Yoshihiro Ohba 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 Struik, et al. Expires April 30, 2015 [Page 7] Internet-Draft 6tisch-security October 2014 Subir Das Applied Communication Sciences 1 Telcordia Drive Piscataway, NJ 08854 USA Email: sdas@appcomsci.com Struik, et al. Expires April 30, 2015 [Page 8]