Network Working Group A. He, Ed. Internet-Draft Huawei Intended status: Informational B. Sarikaya, Ed. Expires: September 10, 2015 Huawei USA March 9, 2015 IoT Security Bootstrapping: Survey and Design Considerations draft-he-6lo-analysis-iot-sbootstrapping-00 Abstract This document presents the importance of security bootstrapping for IoT networks, analyzes the state-of-the-art works in standard organizations and discusses what should be considered when designing the secure bootstrapping mechanism. 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 10, 2015. Copyright Notice Copyright (c) 2015 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. He & Sarikaya Expires September 10, 2015 [Page 1] Internet-Draft IoT Bootstrapping Analysis March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Analysis of Related State-of-the-art Works . . . . . . . . . 3 3.1. Security bootstrapping . . . . . . . . . . . . . . . . . 3 3.1.1. Authentication framework . . . . . . . . . . . . . . 4 3.1.2. Credential Material and Architecture . . . . . . . . 7 3.2. Higher Layer Protocol Use After/During Bootstrapping . . 9 4. Role of IoT Security Bootstrapping . . . . . . . . . . . . . 10 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 5.1. Able to clearly define security dependency and trust domains . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Cross-layer design . . . . . . . . . . . . . . . . . . . 12 5.3. Reduce human interaction to the minimum . . . . . . . . 12 5.4. Able to resist attacks . . . . . . . . . . . . . . . . . 13 5.5. Low computation cost and communication overhead . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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, intelligent transport system, etc. The size of IoT varies from tens to thousands depending on the application, and things in an IoT network might be produced by different vendors and they are normally heterogeneous with various constraints e.g. power supply, communication capability, CPU and memory. IEEE 802.15.4 specifies the physical layer and media access control for low-rate wireless personal area networks (LR-WPANs). It is widely used in wireless sensor networks nowadays and is foreseen as the most used lower layer protocol for low rate IoT networks with resource constrained devices. In IETF, 6LoWPAN (concluded) developed RFC 4944 [RFC4944] to describe how to transmit IPv6 packets over 802.15.4, and support mesh routing in LR-WPANs. 6lo defines generic IPv6 packet header compression method [RFC7400] for LR-WPANs. 6tisch tries to build adaptation protocols for IEEE 802.15.4e specification. Roll develops routing protocol RPL [RFC6550] for IPv6 based low power and lossy networks. Note that IEEE 802.15.4 can be applied to mobile nodes, routing protocols such as AODV [RFC3561], DSL [RFC4728], OLSR [RFC3626] by MANET group are also widely used. CoAP [RFC7252] from He & Sarikaya Expires September 10, 2015 [Page 2] Internet-Draft IoT Bootstrapping Analysis March 2015 CoRE defines a UDP based web transfer protocol for machine- to- machine (M2M) applications such as smart energy and building automation. The above mentioned protocols provide different selections of IoT protocol stacks to fulfill specific tasks based on IEEE 802.15.4. At the start-up phase of a network or after the provisioned communications have failed, bootstrapping is typically required to configure nodes at all layers, including anything from link-layer information (i.e., wireless channels, link-layer encryption keys) to application-layer information (i.e., network names, application encryption keys). It can be realized either manually via user interface or automatically via interaction between nodes. Traditional bootstrapping approaches tend to impose configuration burdens upon users. For example, users need to follow a series of instruction steps for configuration. Configuring IoT devices becomes more complicated since they don't always provide user interface to input all necessary information, and the scale of the IoT network can be large, dynamic or error prone. As a result, human intervention is expensive and not efficient in those situations. This motivates the need for self-organization and automatic self-bootstrapping in IoT. Enabling a plug & play framework not only reduces human efforts in configuring IoT but also improve the scalability and flexibility. This draft presents a survey of the state-of-the-art works on bootstrapping/networking in IETF, ZigBee Alliance, IEEE and Thread group, and the design considerations for security bootstrapping are derived. 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 Related State-of-the-art Works Bootstrapping is required at all layers, where different conditions and information should be transferred for different protocols. This section provides analysis on the existing bootstrapping works in standard organizations and summarizes the concerns. 3.1. Security bootstrapping Security bootstrapping includes the authentication of devices to establish trust relationships in a network, as well as transferring security parameters and keying materials. Security bootstrapping is He & Sarikaya Expires September 10, 2015 [Page 3] Internet-Draft IoT Bootstrapping Analysis March 2015 believed as the fundamental part of bootstrapping, because once secure and authentic channels are established, the bootstrapping of all other information can be conducted as ordinary secured communications. Accordingly, many works focus on security bootstrapping and device authentication. In IETF, [I-D.pritikin-anima-bootstrapping-keyinfra] is proposed in Anima, [I-D.sarikaya-6lo-bootstrapping-solution] is proposed in 6lo, [I-D.struik-6tisch-security-considerations] is in 6tisch, [I-D.kwatsen-netconf-zerotouch] is in Netconf, and [I-D.he-iot-security-bootstrapping] is proposed for bootstrapping IEEE 802.15.4 based IoT networks. ZigBee IP stack is developed by ZigBee Alliance and it supports EAP-TLS and PANA as authentication protocols. In Thread Group, a networking solution is developed. The devices are authenticated through pre-installed codes. IEEE 802.15.4 also defines two-step mechanism for nodes joining network with layer 2 authentication without considering IP infrastructure. 3.1.1. Authentication framework The arguments on authentication framework focus on EAP, PANA, HIP- DEX, 802.1X via EAPOL, and IKEv2. [I-D.oflynn-core-bootstrapping] relates the aforementioned authentication frameworks into IEEE 802.15.4 and requirements in order to use them for bootstrapping procedure. o If PANA is used, a new entity called PANA Relay Element should be added in the architecture and behavior of PANA RE needs to be defined [RFC6345]; New AVPs needed for PANA Relay Element operation for relaying messages from the client to the authenticator and vice versa are required to be specified. If PANA is used to securely distribute group key [RFC6786] from the PANA Authentication Agent to the PANA Client using AES Key Wrap with padding algorithm, an extension to PANA needs to be defined. o If HIP-DEX is used, the initiator should be able to get the IP address of the responder, either using DNS infrastructure or local configuration. o If 802.1X is used, a special value in the Frame Type subfield of the Frame Control Field of IEEE 802.15.4 MAC header should be assigned to indicate the type of the payload. Group addresses for 802.15.4 corresponding to EAPOL Group Address Assignments defined in Table 11.1 of [IEEE802.1x] are required, especially for EAPOL- Start packet. The mapping of MAC frames and security level to different types should be defined, for instance: which MAC frames of beacon, data, acknowledgment and MAC command as defined in [IEEE802.15.4] with what security levels are mapped to controlled He & Sarikaya Expires September 10, 2015 [Page 4] Internet-Draft IoT Bootstrapping Analysis March 2015 port, which MAC frames with what security levels are mapped to uncontrolled port and which MAC frames are never mapped to any of controlled/uncontrolled port (i.e., the payload of those frames are used by the MAC-layer itself and never used by upper layers). [I-D.garcia-core-security] discusses about using Internet Key Exchange protocol version 2 (IKEv2) as authentication method. It summarizes that IKEv2 can perform key exchanges and the setup of security associations without online connections to a trust center. It provides end-to-end security, and supports host mobility with MOBIKE extension. However, MOBIKE mandates the use of IPsec tunnel mode which requires to transmit an additional IP header in each packet. This additional overhead could be alleviated by using header compression methods or the Bound End-to-End Tunnel (BEET) mode [I-D.nikander-esp-beet-mode], a hybrid of tunnel and transport mode with smaller packet headers. 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 and fragmentation is needed when using IEEE 802.15.4 to exchange authentication messages. ZigBee Alliance 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]. This specification assumes Class 2 devices which have 50 KiB of RAM and 250 KiB of flash memory [RFC7228]. Some devices in such systems have more resources and processing power (e.g. ARM9 core, MiBs RAM/ Flash). For security bootstrapping, ZigBee IP uses EAP-TLS. Authentication that is not based on certificates reduces cost of certificate management and fewer messages are needed to be exchanged between client and server. [I-D.sarikaya-6lo-bootstrapping-solution] proposes to use raw public keys via EAP-TLS, thus extension to EAP- TLS is indicated. Note that EAP requires exchanging the device identity in plain text at the beginning, but how to protect the privacy information indicated in the device ID is out of concern of EAP methods. 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. He & Sarikaya Expires September 10, 2015 [Page 5] Internet-Draft IoT Bootstrapping Analysis March 2015 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. [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. The bootstrapping method in [I-D.kumar-6lo-selective-bootstrap] creates security risks for the network by 1. letting the devices have IP addresses for layer3 communication before authentication. 2. constructing routing topology before devices are authenticated. 3. establishing transport layer security before layer-2 security. However, such a protocol could be justified in some application domains like lightning control systems. There is work going on in the IEEE 802.15.9 task group which specifies a way to transport existing key management protocols (KMP) over the 802.15.4 frames. The new feature would allow running IKEv2, EAP,PANA, 802.1X, HIP and Dragonfly over the IEEE 802.15.4 and generate keys for 802.15.4 security and protect all messages between the two nodes [IEEE802.15.9]. It would be desired if the security bootstrapping procedure reuses the KMPs that supported by lower layers to reduce cost. Table 1 summarizes the authentication frameworks and credential materials of the aforementioned solutions. He & Sarikaya Expires September 10, 2015 [Page 6] Internet-Draft IoT Bootstrapping Analysis March 2015 +-------------------------------------+----------------+------------+ | Referenced solution | Authentication | Credential | | | method | material | +-------------------------------------+----------------+------------+ | [I-D.pritikin-anima-bootstrapping-k | 802.1x-EAPOL, | 802.1AR ce | | eyinfra] | EAP-TLS, EAP- | rtificate | | | IKEv2 | | | [I-D.sarikaya-6lo-bootstrapping-sol | EAP-TLS | Raw public | | ution] | (modified) | key | | [I-D.struik-6tisch-security-conside | Joining | Certificat | | rations] | Protocol | e | | | (undefined) | | | [I-D.kwatsen-netconf-zerotouch] | Unspecified | X.509 cert | | | (EAP-TLS might | ificate | | | be used) | | | [I-D.he-iot-security-bootstrapping] | EAP, PANA | Unspecifie | | | | d | | [I-D.kumar-6lo-selective-bootstrap] | Selected by | PSK | | | Commissioner | defined in | | | with CT | CT | | ZigBee IP stack based Smart Energy | EAP-TLS, PANA | Certificat | | | | e | | Thread networking | Unknown | Product | | | | install | | | | codes | +-------------------------------------+----------------+------------+ Table 1 3.1.2. Credential Material and Architecture The trust relationship can be established by exchanging credential materials, which can be asymmetric with user authentication or with certificate authority, or symmetric pre-shared key configured by network developer. In certificate authority (CA), a typical public key infrastructure (PKI) is used, meaning that a set of hardware, software, people, policies, and procedures are needed to create, manage, distribute, use, store, and revoke digital certificates. The public keys are obtained in PKI containers, and both ends are validated using trust anchors based on a certification authority (CA). [I-D.pritikin-anima-bootstrapping-keyinfra] uses 802.1AR certificate, [I-D.kwatsen-netconf-zerotouch] uses X.509 certificate. Certificate mechanism provides high security however it can add a complicated trust relationship that is difficult to validate. When it comes to large scale IoT networks, certificate management and distribution will raise scalability and flexibility issue. Besides, the time spent and CPU occupied by the cryptographic operations is non-trivial when this mechanism is implemented on computational He & Sarikaya Expires September 10, 2015 [Page 7] Internet-Draft IoT Bootstrapping Analysis March 2015 constraint devices. Since some IEEE802.15.4 technologies including 802.15.4e only allows 127 Octets maximum payload, fragmentation is unavoidable, which indicates that a large amount of data is transmitted and communication overhead is heavy. The public-key based handshake process of EAP-TLS is part of the bottleneck that significantly degrades the performance. Designers are forced to use highly efficient protocols for the sake of ensuring the computational complexity of security algorithms as low as possible. In today's IoT, most common architectures are fully centralized in a sense that all the security relationships within a segment are handled by a central party. The 802.1x framework, the architecture proposed in [I-D.pritikin-anima-bootstrapping-keyinfra] and the ZigBee IP smart energy solution are centralized. A centralized authentication architecture allows for central management of devices and keying materials as well as for the backup of cryptographic keys. As a result there is no high requirement on network devices in a centralized architecture. However it also represents a single point of failure and is more suitable for static network where the route to the trust center/AAA server is stable. The self-signed certificates are commonly used in smaller deployments where they are distributed to all involved protocol endpoints out-of- band, thus CA and certificate management are not required. This practice does, however, still require the overhead of the certificate generation even though none of the information found in the certificate is actually used. The raw public key method is proposed to generate light weight certificate, which can significantly reduce overhead. However, the self-signed certificate and raw public key only prove the possession of the private-public key pair and are unable to prove whether the owner is legitimate. The pre-shared key based mechanisms are more suitable for constrained environments, e.g. wireless communications, and limited CPU power devices. It enables mutual authentication, meanwhile requires less cryptographic operations and less communication overhead compared with certificate based mechanism. However, traditional approaches of key generation/distribution tend to impose configuration burdens upon users. For example, users need to follow a series of instruction steps for WiFi Protected Access 2, Pre-shared key (WPA2-PSK) configuration, even though the pre-shared key mode is the simplest option for using WPA. Establishing security among IoT devices becomes more complicated since they don't always provide user interface to input necessary security information. He & Sarikaya Expires September 10, 2015 [Page 8] Internet-Draft IoT Bootstrapping Analysis March 2015 As discussed, the authentication of self-signed certificate and pre- shared key mechanisms are distributed. Distributed architecture allows creating ad-hoc security domains that might not require a single online management entity and are operative in a much more stand-alone manner. In this case, hardware should be configured to be able to authenticate and verify other peers. In today's IoT, most common architectures are fully centralized in a sense that all the security relationships within a segment are handled by a central party. The Thread protocol is expected to use product install codes as authentication material. Currently not enough details are available on the Thread protocol. Physical unclonable function (PUF) arises as a promising authentication technology. PUF is a physical entity that is embodied in a physical structure and is easy to evaluate but hard to predict. Further, an individual PUF device must be easy to make but practically impossible to duplicate, even given the exact manufacturing process that produced it. In this respect it is the hardware analog of a one-way function. PUFs can serve as a root of the trust and can provide a key which cannot be easily reverse engineered. Temperature and aging have been given special attention on developing reliable PUF [MIT2014]. 3.2. Higher Layer Protocol Use After/During Bootstrapping Configurations of parameters for other protocols are important as well to ensure a successful networking. Those parameters are transferred upon a successful security bootstrapping. The IP address configuration is a major issue which must be solved before any other higher layer service can start. It can be locally pre-configured, auto-configured or managed from a third party tool. o Pre-configured: is mainly what is done today. No further network service is needed, the assignment is done from a planning/ commissioning tool instead. This method requires human interaction, devices with IP configured are trusted by default. scalability and flexibility cannot be satisfied in this case. o Auto-configuration: the device creates its IP address itself, applying one of the algorithms specified in the relevant standards, e.g. ZigBee IP solved this problem by using SLAAC IPv6 addresses based on the EUI-64; [I-D.pritikin-anima-bootstrapping-keyinfra] suggests to obtain an IP address using existing methods, such as SLAAC or DHCPv6. RPL He & Sarikaya Expires September 10, 2015 [Page 9] Internet-Draft IoT Bootstrapping Analysis March 2015 [RFC6550] is a special routing protocol that generates for each device an IP prefix based on the constructed routing topology, thus special attention should be paid as chicken/egg issue arises when relay of authentication is needed by the network level bootstrapping. The auto-configured IP address may need to perform a check for duplicates (i.e. APIPA17). Encoding of semantics into the address may need information from lower layer (see above) or from network service. Note, this only works for so-called link local-addresses which are valid only in one Ethernet domain. o Managed: pre-planned addresses are assigned by means of a third party database, such as DHCP, a central server. 4. Role of IoT Security Bootstrapping Figure 1 shows a network life cycle: after IoT devices being deployed in field, the security bootstrapping starts. Devices are authenticated, keying materials are exchanged for securing subsequent configuration/data exchange messages. The device gets an IP address and joins the network. +--------------------------------------+ | Device deployment | +----------------+---------------------+ | ------------+ +----------------+---------------------+ | | Network access authentication | | +----------------+---------------------+ | | +->Security Bootstrapping +----------------+---------------------+ | | Secured channel keying material | | +----------------+---------------------+ | | ------------+ +----------------+-------------------------+ | Secure communication in the network | +------------------------------------------+ Figure 1: IoT Life Cycle 5. Design Considerations IoT can be deployed in different environments for different applications, which calls for protocols with options where a set of options is selected to construct a protocol stack that fits for a given environment, e.g. home, enterprise or industrial. The deployment and configurations can also be divided into two types, one is for static network, and the other is for dynamic network. He & Sarikaya Expires September 10, 2015 [Page 10] Internet-Draft IoT Bootstrapping Analysis March 2015 IoT developed in buildings, homes, or industrial areas are often static. A general approach is that a network engineer plans the locations for each device and determines topology of network based on deployment environment and channel estimation. Then the key devices (e.g. sink nodes, or parent nodes of a routing protocol) are installed before deploying other devices. Upon successful installation, the device is plugged and security bootstrapping is run in either centralized or distributed manner with pre-configured credential material. The device is at work after all the protocols are successfully bootstrapped. When a new device joins an existing network, the joining device bootstrapping procedure is triggered by itself. In a dynamic network where devices come and go, their IPv6 addresses might also change. Bootstrapping/re-commissioning at network level is more frequently required than that in static network, hence minimum human interaction is highly preferred. Reducing communication overhead will improve the efficiency of networking, and this is especially useful for low bandwidth and low rate IEEE 802.15.4. Mains-powered devices can stay continuously connected to the network. Normally-off power strategy can be used for battery powered devices where the devices sleep long periods of time and stay disconnected and reattach to the network after it is woken up. Between these two extremes, there is low-power device mode where the devices need to be able to communicate on a relatively frequent basis [RFC7228].Bootstrapping protocol needs to be able to take into consideration these power levels in the design. The order of bootstrapping is another concern in designing the bootstrapping protocol. The devices could arbitrarily be bootstrapped as they join the network, especially in dynamic topologies. In static topologies the order could be completely installation and installer dependent and could be optimized to lower cost and could be independent of network topology [I-D.kumar-6lo-selective-bootstrap]. The order is also dependent on the architecture of authentication. For centralized architecture, incremental approach is recommended by [I-D.he-iot-security-bootstrapping] , [I-D.garcia-core-security] and [I-D.sarikaya-6lo-bootstrapping-solution], whereas a selective order can be specified by CT [I-D.kumar-6lo-selective-bootstrap] and special attention should be paid on the secured channel establishment via untrusted route. For decentralized architecture, the mutual- authentication is realized between equal peers in pure mesh topology without any preferred order and network keys can be distributed by cluster heads once clusters are formed. He & Sarikaya Expires September 10, 2015 [Page 11] Internet-Draft IoT Bootstrapping Analysis March 2015 Some mandatory considerations can be derived from different applications for IoT security bootstrapping mechanism: 5.1. Able to clearly define security dependency and trust domains Things of IoT are more related to private data, thus trust increases its importance. It is easy to introduce a new node in a deployed IoT to capture and analyze the data traffic. As a result, a. Security dependencies between different devices must be clarified. Circular dependencies must be avoided. b. The designed protocol should enable mutual authentication between devices running the security bootstrapping protocol. Proper authentication material and mechanism should be chosen. c. The security bootstrapping protocol processing devices should agree upon the security associations (e.g. key materials, algorithms etc.) for securing their communications before exchanging any protocol packets. 5.2. Cross-layer design The security bootstrapping method should take into account the features and requirements of full stack protocols that are selected for an IoT network. Security bootstrapping in collaboration with other networking protocols is likely to produce a comprehensive solution. Cooperative communication and scheduling among neighboring things at lower layer will reduce the possibility of network congestion and assist finishing bootstrapping efficiently. Different power modes should be considered by the designed protocol. As discussed in Section 3.2, higher layer protocols impact the procedure of bootstrapping. During network start-up, link local IP address should be assigned in order to run PANA/TLS to forward authentication messages by IoT routing protocols such as AODV and DSR in MANET. However, the RPL for LLN configures IP addresses for all the devices during/ at the end of routing procedure, which may create a chicken/egg issue when PANA/TLS are also used. 802.1X uses link layer address so no IP address is needed. 5.3. Reduce human interaction to the minimum Configuring IoT devices can be complicated since they don't always provide user interface to input all necessary information, and the scale of the IoT network can be large, dynamic or error prone. He & Sarikaya Expires September 10, 2015 [Page 12] Internet-Draft IoT Bootstrapping Analysis March 2015 Besides, IoT network users usually do not have expertise in networking, this motivates self-organizing IoT network protocol that start from security bootstrapping. As a result, the design of bootstrapping protocol should be able to reduce human interaction to the minimum. 5.4. Able to resist attacks The designed bootstrapping protocol should be able to resist attacks and protect CIA triad. Typical threat modeling approaches (e.g. STRIDE) should be used to guide the design of bootstrapping architecture and procedure. STRIDE categorizes attack into spoofing, Tampering with data, Repudiation, Information disclosure, Denial of service and Elevation of privilege. 5.5. Low computation cost and communication overhead The amount of transmitted data and the complexity of data processing should be optimized to the minimum to save computation and communication cost. 6. Security Considerations TBD 7. Acknowledgements TBD 8. References 8.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, . He & Sarikaya Expires September 10, 2015 [Page 13] Internet-Draft IoT Bootstrapping Analysis March 2015 [IEEE802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network Access Control", February 2010, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, February 2007. [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, January 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [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, August 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, 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, February 2008. [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008. [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 256/384 and AES Galois Counter Mode", RFC 5487, March 2009. He & Sarikaya Expires September 10, 2015 [Page 14] Internet-Draft IoT Bootstrapping Analysis March 2015 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, August 2011. [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. [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs", RFC 6786, November 2012. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 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. [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, June 2014. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, November 2014. [SEP2.0] ZigBee Alliance, "ZigBee IP Specification", March 2014, . 8.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. He & Sarikaya Expires September 10, 2015 [Page 15] Internet-Draft IoT Bootstrapping Analysis March 2015 [I-D.he-iot-security-bootstrapping] ana.hedanping@huawei.com, a., "Security Bootstrapping of IEEE 802.15.4 based Internet of Things", draft-he-iot- security-bootstrapping-00 (work in progress), January 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. [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., Behringer, M., and S. Bjarnason, "Bootstrapping Key Infrastructures", draft-pritikin-anima- bootstrapping-keyinfra-01 (work in progress), February 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.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. He & Sarikaya Expires September 10, 2015 [Page 16] Internet-Draft IoT Bootstrapping Analysis March 2015 Authors' Addresses Ana(Danping) He (editor) Huawei Building Q14, 156 Beiqing Road Beijing 100095 China Email: ana.hedanping@huawei.com Behcet Sarikaya (editor) Huawei USA 5340 Legacy Dr. Building 3 Plano, TX 75024 Email: sarikaya@ieee.org He & Sarikaya Expires September 10, 2015 [Page 17]