6TiSCH R. Struik Internet-Draft Struik Security Consultancy Intended status: Informational July 4, 2014 Expires: January 5, 2015 6TiSCH Security Architectural Elements draft-struik-6tisch-security-architecture-elements-00 Abstract This document describes security architectural elements that are relevant for the design of the 6TiSCH security architecture. (Note: this document is a work-in-progress and will provide more fine-tuned information with updated versions.) Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 January 5, 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 Struik Expires January 5, 2015 [Page 1] Internet-Draft 6tisch-security-architecture July 2014 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. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Device Roles . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Initiator and Responder Model . . . . . . . . . . . . . . 3 1.3. Cautionary Note - on Limitations of Cryptography . . . . 3 1.4. Desired Protocol Properties . . . . . . . . . . . . . . . 3 1.5. Device Enrolment Phases . . . . . . . . . . . . . . . . . 4 1.6. Security Definitions . . . . . . . . . . . . . . . . . . 5 1.7. Deployment Scenarios . . . . . . . . . . . . . . . . . . 6 2. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3. Other Related Protocols . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative references . . . . . . . . . . . . . . . . . . 7 6.2. Informative references . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Preliminaries 1.1. Device Roles When discussing security operations, it is useful to distinguish various device roles. Here, one should note that a device may assume more than one device role at the same time and that a particular role may be assumed by more than one device. Moreover, the mapping of device roles to devices may change over time (along a device's or network's lifecycle). We distinguish the following roles: 1. Client. This device may move in and out of networks (that may be alien to it) and may have little network management functionality on board. Key words: nomadic, promiscuous, constrained. 2. Access point. This device may be more tied into a relatively stable infrastructure and may have more support for network management functionality or have reliable access hereto (e.g., via a back-end system). Key words: anchor, semi-stable connectivity, access portal. Struik Expires January 5, 2015 [Page 2] Internet-Draft 6tisch-security-architecture July 2014 3. Server. This device provides stable infrastructure and network management support, either intra-domain or inter domain (thereby, offering homogeneous or even heterogeneous functionality). Key words: core function, high availability, human-operator support. 4. CA. This device vouches for trust credentials, usually in offline way. Key words: trust anchor. 1.2. Initiator and Responder Model All peer-to-peer protocols are role-symmetrical (i.e., the role of initiator/responder roles are interchangeable). Protocols involving a third party assume communications with this third party to take place via the access point (since being the device more tied into infrastructure). 1.3. Cautionary Note - on Limitations of Cryptography Cryptographic techniques may provide logical assurances as to a device's identity, where and when communications originated, whom it was intended for, whom this can be read by, etc. Cryptographic techniques do, however, only provide mechanical assurances and can generally not substitute human authorization decision elements (unless the latter are not important, such as with random, ad-hoc networks). 1.4. 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, if at all possible Struik Expires January 5, 2015 [Page 3] Internet-Draft 6tisch-security-architecture July 2014 2. The number of message exchanges for a joining client device should be reduced 3. Message exchanges should be structured so as to allow parallel execution of protocol steps, if possible Computational Cost: 1. Security protocols should not impose an undue computational burden, esp. on joining client 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 client, if possible 3. Dependency on "homogeneous trust models" should be reduced, without jeopardizing security properties 4. Dependency on on-board trusted platforms and trusted I/O interfaces should be reduced 1.5. Device Enrolment Phases 1. Device Authentication. Client A and Access Point B authenticate each other and establish a shared key (so as to ensure on-going authenticated communications). This may involve server KDC as third party. 2. Authorization. Access Point B decides on whether/how to authorize device A (if denied, this may result in loss of bandwidth). Authorization decision may be delegated to server KDC or other 3rd-party device. 3. Configuration/Parameterization. Access Point B distributes configuration information to Client A, such as * IP address assignment info; * Bandwidth/usage constraints; * Scheduling info (including on re-authentication policy details) Struik Expires January 5, 2015 [Page 4] Internet-Draft 6tisch-security-architecture July 2014 This may originate from other network devices, for which it acts as proxy. This step may also include distribution of information from Client A to Access Point B and, more generally, synchronization of information between these two entities. The device enrollment process is depicted in Figure Figure 1, where it is assumed that devices have access to certificates and where entities have access to the root CA key of its 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. {joining node} {neighbor} {server, etc.} +---------+ +---------+ +---------+ | Client | | Access | +--| CA |e.g., certificate | A | | Point 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: Networking Joining, with Only Authorization by Third Party Aggressive scheme: Initiate authorization/configuration processes as soon as (presumed) device identity becomes available (invisible to Client A). Access Point B can deny bandwidth if authorization negative. Note: Communication of configuration info depends on secure channel with Client A. 1.6. Security Definitions 1. Key Establishment: Protocol whereby a shared secret becomes available to two or more parties for subsequent cryptographic use Struik Expires January 5, 2015 [Page 5] Internet-Draft 6tisch-security-architecture July 2014 2. Key Transport: Key establishment technique where one party creates/obtains the secret and securely transfers it to other(s) 3. Key Agreement: Key establishment technique where the shared secret is derived based on information contributed by each of the parties involved, ideally so that no party can predetermine this secret value 4. Implicit Key Authentication: Assurance as to which specifically identified parties possibly may gain access to a specific key 5. Key Confirmation: Assurance that second (possibly unknown) party has possession of a particular key 6. Explicit Key Authentication: Combination of implicit key authentication and key confirmation 7. Unilateral Key Control: Key establishment protocol whereby one party can influence the shared secret 8. Forward Secrecy: Assurance that compromise of long-term keys does not compromise past session keys 9. Entity Authentication: Assurance of active involvement of second explicitly identified party in protocol 10. Mutual vs. Unilateral: Adjective indicating symmetry, resp. asymmetry, of assurances amongst parties 11. Identity Protection: Assurance as to which specifically identified parties may gain access to identity info 12. Certificate ? Credential that vouches for authenticity of binding between a public key and other information, including the identity of the owner of the public key in question 13. Key Possession? Assurance that a specific (possibly unknown) party has possession of a particular key Esoteric properties: Unknown Key Share Resilience, Session Key Retrieval, Key Compromise Impersonation 1.7. Deployment Scenarios Deployment scenarios discussed with industrial control user community: 1. Scenario #1: mix-and-match of nodes from different vendors Struik Expires January 5, 2015 [Page 6] Internet-Draft 6tisch-security-architecture July 2014 2. Scenario #2: addition of nodes to operational network 3. Scenario #3: security audit 4. Scenario #4: device repair and replacement (roaming in/out different user sites) 5. Scenario #5: network separation (devices joining wrong network) 6. Scenario #6: thwarting malicious attacks by (former) insiders 7. Scenario #7: thwarting attacks by outsiders via insiders (held at 'gunpoint') 8. Scenario #8: addition of subsystem ('skid') assembled elsewhere to operational network 2. Security Considerations This document is all about security. 3. Other Related Protocols 4. IANA Considerations 5. Acknowledgements Discussions amongst participants in the 6TiSCH security conference calls to-date helped to shape this document. 6. References 6.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012. Struik Expires January 5, 2015 [Page 7] Internet-Draft 6tisch-security-architecture July 2014 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, June 2014. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [I-D.ietf-6tisch-coap] Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Interaction using CoAP", draft-ietf-6tisch-coap-00 (work in progress), May 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-02 (work in progress), June 2014. [I-D.wang-6tisch-6top-sublayer] Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top)", draft-wang-6tisch-6top- sublayer-00 (work in progress), February 2014. [I-D.ietf-6tisch-6top-interface] Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Interface", draft-ietf-6tisch- 6top-interface-00 (work in progress), March 2014. 6.2. Informative references [I-D.garcia-core-security] Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and R. Struik, "Security Considerations in the IP-based Internet of Things", draft-garcia-core-security-06 (work in progress), September 2013. [I-D.ietf-dice-profile] Hartke, K. and H. Tschofenig, "A DTLS 1.2 Profile for the Internet of Things", draft-ietf-dice-profile-01 (work in progress), May 2014. [I-D.kumar-dice-dtls-relay] Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay for Constrained Environments", draft-kumar-dice-dtls- relay-01 (work in progress), April 2014. Struik Expires January 5, 2015 [Page 8] Internet-Draft 6tisch-security-architecture July 2014 [I-D.thubert-6lowpan-backbone-router] Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 6lowpan-backbone-router-03 (work in progress), February 2013. [IEEE802.15.4-2011] Institute for Electrical and Electronics Engineers, "IEEE 802.15.4-2011, IEEE Standard for Local and Metropolitan Area Networks - Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", September 2011. [IEEE802.15.4e-2012] Institute for Electrical and Electronics Engineers, "IEEE 802.15.4e-2012, IEEE Standard for Local and Metropolitan Area Networks - Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs), Amendment 1: MAC Sublayer", April 2012. [Wireless-HART] International Electrotechnical Commission, "IEC 62591, Ed. 2.0: Industrial Communication Networks - Wireless Communication Network and Communication Profiles - WirelessHART (Draft)", November 2013. [ISA100.11a] International Electrotechnical Commission, "IEC 62734, Ed. 1: Industrial Communication Networks - Wireless Communication Network and Communication Profiles - ISA 100.11a (Draft)", May 2013. [ZigBee-IP] ZigBee Alliance, "ZigBee IP Specification (ZigBee Public Document 13-002r00)", February 2013. Author's Address Rene Struik Struik Security Consultancy Email: rstruik.ext@gmail.com Struik Expires January 5, 2015 [Page 9]