Network Working Group B. Sarikaya Internet-Draft Y. Li Intended status: Informational Huawei Expires: September 22, 2016 M. Sethi Ericsson R. Cragie ARM March 21, 2016 Secure IoT Bootstrapping: A Survey draft-sarikaya-t2trg-sbootstrapping-00 Abstract This document presents a survey of secure bootstrapping mechanisms available for smart objects that are part of an Internet of Things (IoT) network. It aims to provide a structured classification of the available mechanisms. The document does not prescribe any one secure bootstrapping mechanism and rather presents IoT developers with different options to choose from, depending on their use-case, security requirements and the user interface available on their smart objects. 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 22, 2016. Copyright Notice Copyright (c) 2016 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 Sarikaya, et al. Expires September 22, 2016 [Page 1] Internet-Draft IoT Bootstrapping Analysis March 2016 (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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Analysis of available mechanisms . . . . . . . . . . . . . . 3 3.1. Managed/Centralized . . . . . . . . . . . . . . . . . . . 4 3.2. P2P/Adhoc . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 6 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction An Internet of Things (IoT) network is composed of connected things that cooperate together to accomplish tasks such as smart buildings, smart environment monitoring system, and intelligent transport systems. The size of an IoT network varies from a couple of devices to tens of thousands depending on the application. A smart object, or a things, or a device in an IoT network is typically produced by a variety of vendors and they are normally heterogeneous in terms of the constraints on their power supply, communication capability, computation capacity and memory available. Before classifying and describing the various methods of bootstrapping, it is important define what is meant by the term security bootstrapping. There have been several varying definitions that have been used in different drafts and research papers. For the purpose of this document, we define Security bootstrapping as follows: "it is the process by which a thing/device/smart object in an IoT network securely becomes operational at a given location and point of time." This definition is broad on purpose since the term IoT itself represents a very diverse spectrum of application scenarios. So for example, pairing of phones over bluetooth to exchange files, and securely connecting IEEE 802.15.4 sensors in a factory to the backend both require some form of secure bootstrapping Sarikaya, et al. Expires September 22, 2016 [Page 2] Internet-Draft IoT Bootstrapping Analysis March 2016 to become operational. Secure bootstrapping must result in either delivery or generation of some keying material for secure operation. This is different form simply joining a network with DHCP to communicate. It is also important to note that a device which simply connects to a service or entity using certificates and TLS/DTLS is not considered as bootstrapping and rather authentication. This no different than using your laptop browser and connecting to an online service over HTTPS. For the purpose of this draft, the focus is on secure bootstrapping rather than secure authentication. While some bootstrapping approaches are more user-intensive and require extensive user-involvement by scanning QR codes or entering passwords; others maybe more automated, such as those that rely on mobile networks [I-D.sethi-gba-constrained]. 2. Terminology 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 [RFC2119]. 3. Analysis of available mechanisms We classify available bootstrapping solutions into the following three major categories: o Managed/Centralized/AAA: These mechanisms rely on a centralized node or server for bootstrapping the IoT devices. There is generally an implicit assumption that the devices being bootstrapped have some connectivity to the server or node that is responsible for bootstrapping the device. o P2P/Adhoc: These mechanisms are traditionally used for establishing secure communication between two devices for ad-hoc communication, such as pairing two smart phones. These methods do not rely on centralized server for bootstrapping. o Miscellaneous: These methods rely on some components from both centralized and P2P mechanisms. For example, they may use Public- keys and certificates but instead of relying on a centralized server, the devices being bootstrapped might simply exchange their public-key over an out-of-band channel to then derive share- secrets for further secure communication. Sarikaya, et al. Expires September 22, 2016 [Page 3] Internet-Draft IoT Bootstrapping Analysis March 2016 3.1. Managed/Centralized This section provides some examples of centralized methods. Extensible Authentication Protocol (EAP) is an authentication framework that supports multiple authentication methods. EAP is designed for use in network access authentication and typically runs directly over data link layers without IP. Several EAP methods have been standardized for different purposes. One widely used method is the EAP-TLS [RFC7250] which enables mutual authentication and distribute keying material to secure subsequent communications. However it only supports certificate-based mutual authentication, thus public key infrastructure is required. The ZigBee Alliance has specified an IPv6 stack aimed at IEEE 802.15.4 devices mainly used in smart meters developed primarily for SEP 2.0 (Smart Energy Profile) application layer traffic [SEP2.0]. For secure bootstrapping, ZigBee IP uses EAP-TLS. EAP-PSK [RFC4764] is another EAP method. It realizes mutual authentication and session key derivation using a Pre-Shared Key (PSK). Normally four messages are exchanged in the authentication process. Once the authentication is successful, EAP-PSK provides a protected communication channel. EAP-IKEv2 [RFC5106] is an EAP method based on IKEv2. It provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on different credentials including asymmetric key pairs, symmetric keys and passwords. Besides, it is possible to use a different authentication credential in each direction. For example, the EAP server authenticates itself using public/private key pair and the EAP peer using symmetric key. As a result different combinations of credentials are expected to be used in practice. Compared with EAP-TLS and EAP-PSK, EAP-IKEv2 supports mobility and different authentication techniques. Generic Bootstrapping Architecture (GBA) is another bootstrapping method that falls in centralized category. GBA is part of the 3GPP standard [3gppts33220] and is based on 3GPP Authentication and Key Agreement (3GPP AKA). GBA is an application independent mechanism to provide a client application (running on the User equipment (UE)) and any application server with a shared session secret. This shared session secret can subsequently be used to authenticate and protect the communication between the client application and the application server. GBA authentication is based on the permanent secret shared between the UE's Universal Integrated Circuit Card (UICC), for example SIM card, and the corresponding profile information stored within the cellular network operator's Home Subscriber System (HSS) Sarikaya, et al. Expires September 22, 2016 [Page 4] Internet-Draft IoT Bootstrapping Analysis March 2016 database. [I-D.sethi-gba-constrained] describes a resource- constrained implementation of GBA for IoT applications. Open Mobile Alliance (OMA) Light-weight M2M standard also defines secure bootstrapping for resource-constrained IoT devices with a centralized Bootstrapping Server (BS). The current standard defines the following four bootstrapping modes: o Factory Bootstrap: An IoT device in this case is configured with all the necessary bootstrap information during manufacturing and prior to its deployment. o Bootstrap from Smartcard: An IoT device retrieves and processes all the necessary bootstrap data from a Smartcard. o Client Initiated Bootstrap: This mode provides a mechanism for an IoT client device to retrieve the bootstrap information from a Bootstrap Server. This requires the client device to have an account at the Bootstrap Server and credentials to obtain the necessary information securely. o Server Initiated Bootstrap: In this bootstrapping mode, the bootstrapping server configures all the bootstrap information on the IoT device without receiving a request from the client. This means that the bootstrap server needs to know if a client IoT Device is ready for bootstrapping before it can be configured. For example, a network may inform the bootstrap server of a new connecting IoT client device. The Kerberos protocol [RFC4120] is a network authentication protocol that allows several endpoints to communicate over an insecure network. Kerberos relies on a symmetric cryptography scheme and requires a trusted third party, that guarantees the identities of the various actors. It relies on the use of "tickets" for nodes to prove identity to one another in a secure manner. There has been research work on using Kereberos for IoT devices[kerberosiot]. ANIMA bootstrapping: TBD 3.2. P2P/Adhoc P2P or adhoc methods are used for bootstrapping typically for creating local associations. These local associations may later be used for connecting an IoT device to a centralized server. These bootstrapping mechanisms typically rely on an out-of-band (OOB) channel in order to prevent man-in-the-middle (MitM) attacks. Contextual and location-dependent information on the OOB channel is assumed to be secret from anyone not present at the location where Sarikaya, et al. Expires September 22, 2016 [Page 5] Internet-Draft IoT Bootstrapping Analysis March 2016 the bootstrapping takes place.Based on how the OOB channel is used, the P2P methods can be further classified into two sub categories: o Key derivation: Contextual information received over the OOB channel is used for shared key derivation. For example, [proximate] relies on the common radio environment of the devices being paired to derive the shared secret which would then be used for secure communication. o Key confirmation: A Diffie-Hellman key exchange occurs over the insecure network and the established key is authenticate with the help of the OOB channel. For example, Bluetooth simple pairing [SimplePairing] use the OOB channel to ask the user to compare pins and approve the completed exchange. P2P/Adhoc methods might use a discrete OOB channel, such as Bluetooth simple pairing that relies on pin codes. Alternatively these secure bootstrapping methods might rely on noisy sensory inputs such as audio. These protocols have to cope with a fuzzy secret, i.e. noisy secret input that differs between the devices being bootstrapped. 3.3. Miscellaneous As stated earlier, some secure bootstrapping methods rely on components from both adhoc and centralized categories. We discuss some examples in this section. [I-D.kumar-6lo-selective-bootstrap] presents a selective bootstrapping/commissioning method by introducing the concept of Commissioning Tool (CT). In this method the devices are let to connect to the network and execute 6LowPAN neighbor discovery protocol and have an IPv6 address before they are authenticated. Then the devices are selected one by one in some order to communicate with the CT via untrusted constructed route. Once the ID of joining device is authenticated, CT sends the layer-2 key material to the device via secured channel, which is established by DTLS by exchanging credential material installed during manufacturing. Raw Public Key [RFC7250] defines how raw public keys can be used to authenticate constrained devices or in mutual authentication using EAP-TLS or DTLS. Raw public key TLS/DTLS extension simplifies client_certificate_type and server_certificate_type to carry only SubjectPublicKeyInfo structure with the raw public key instead of many other parameters found in the certificates. The device and the authentication server (AS) exchange client_hello and server_hello messages and send their raw public keys. The device and AS validate Sarikaya, et al. Expires September 22, 2016 [Page 6] Internet-Draft IoT Bootstrapping Analysis March 2016 the keys by comparing the pre-configured values [I-D.sarikaya-6lo-bootstrapping-solution]. Raw public key approach when used with DTLS offers a simple secure bootstrapping solution especially for smart energy and building automation applications. It can be easily integrated with the Constrained Application Protocol (CoAP) where there is already a CoAP server which can also be the authentication server. 4. Discussion It is evident that there are many different methods of secure bootstrapping available. The choice on of the method is constrained by the type of device being bootstrapped. Depending on the link- layer technology used, and the User Interface (UI) available, one or more of the above mentioned categories might be suitable. In this section we discuss some general guidelines that would help in selecting the right bootstrapping method. TBD 5. Security Considerations The whole draft deals with security considerations. 6. Acknowledgements TBD 7. References 7.1. Normative References [IEEE802.15.4] IEEE Standard, , "IEEE Std. 802.15.4-2011", October 2011, . [IEEE802.15.9] IEEE P802.15.9/D01, "IEEE Draft Recommended Practice for transport of key management protocol (KMP) datagrams", November 2014, . [IEEE802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network Access Control", February 2010, . Sarikaya, et al. Expires September 22, 2016 [Page 7] Internet-Draft IoT Bootstrapping Analysis March 2016 [kerberosiot] Hardjono, , "Kerberos for Internet-of-Things", February 2014, . [proximate] Mathur, , Miller, , Varshavsky, , Trappe, , and Mandayam, "Proximate: proximity-based secure pairing using ambient wireless signals.", June 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, . [RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, DOI 10.17487/RFC3626, October 2003, . [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, . [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007, . [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . Sarikaya, et al. Expires September 22, 2016 [Page 8] Internet-Draft IoT Bootstrapping Analysis March 2016 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol- Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, DOI 10.17487/RFC5106, February 2008, . [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, . [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 256/384 and AES Galois Counter Mode", RFC 5487, DOI 10.17487/RFC5487, March 2009, . [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, DOI 10.17487/RFC6345, August 2011, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., 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, DOI 10.17487/RFC6550, March 2012, . [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs", RFC 6786, DOI 10.17487/RFC6786, November 2012, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . Sarikaya, et al. Expires September 22, 2016 [Page 9] Internet-Draft IoT Bootstrapping Analysis March 2016 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, . [SEP2.0] ZigBee Alliance, "ZigBee IP Specification", March 2014, . [SimplePairing] Bluetooth, SIG, "Simple pairing whitepaper", Technical report , 2007. 7.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.he-iot-security-bootstrapping] ana.hedanping@huawei.com, a. and B. Sarikaya, "Security Bootstrapping of IEEE 802.15.4 based Internet of Things", draft-he-iot-security-bootstrapping-01 (work in progress), May 2015. [I-D.kumar-6lo-selective-bootstrap] Kumar, S. and P. Stok, "Security Bootstrapping over IEEE 802.15.4 in selective order", draft-kumar-6lo-selective- bootstrap-00 (work in progress), March 2015. Sarikaya, et al. Expires September 22, 2016 [Page 10] Internet-Draft IoT Bootstrapping Analysis March 2016 [I-D.kwatsen-netconf-zerotouch] Watsen, K., Hanna, S., Clarke, J., and M. Abrahamsson, "Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)", draft-kwatsen-netconf-zerotouch-01 (work in progress), February 2014. [I-D.nikander-esp-beet-mode] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 (work in progress), August 2008. [I-D.oflynn-core-bootstrapping] Sarikaya, B., Ohba, Y., Cao, Z., and R. Cragie, "Security Bootstrapping of Resource-Constrained Devices", draft- oflynn-core-bootstrapping-03 (work in progress), November 2010. [I-D.pritikin-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Behringer, M., and S. Bjarnason, "Bootstrapping Key Infrastructures", draft- pritikin-anima-bootstrapping-keyinfra-02 (work in progress), July 2015. [I-D.sarikaya-6lo-bootstrapping-solution] Sarikaya, B., "Secure Bootstrapping Solution for Resource- Constrained Devices", draft-sarikaya-6lo-bootstrapping- solution-00 (work in progress), June 2013. [I-D.sethi-gba-constrained] Sethi, M., Lehtovirta, V., and P. Salmela, "Using Generic Bootstrapping Architecture with Constrained Devices", draft-sethi-gba-constrained-01 (work in progress), February 2014. [I-D.struik-6tisch-security-considerations] Struik, R., "6TiSCH Security Architectural Considerations", draft-struik-6tisch-security- considerations-01 (work in progress), January 2015. [MIT2014] Herder, C., Farinaz Koushanfar, F., and S. Srinivas Devadas, "Physical Unclonable Functions and Applications: A Tutorial", Proceedings of the IEEE , vol. 102, no. 8, pp. 1126-1141, August 2014. Sarikaya, et al. Expires September 22, 2016 [Page 11] Internet-Draft IoT Bootstrapping Analysis March 2016 Authors' Addresses Behcet Sarikaya Huawei 5340 Legacy Dr. Building 3 Plano, TX 75024 USA Email: sarikaya@ieee.org Yizhou Li Huawei 101 Software Avenue Nanjing 210012 China Email: sarikaya@ieee.org Mohit Sethi Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: sarikaya@ieee.org Robert Cragie ARM 110 Fulbourn Road Cambridge CB1 9NJ UK Email: sarikaya@ieee.org Sarikaya, et al. Expires September 22, 2016 [Page 12]