Core B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track February 18, 2013 Expires: August 22, 2013 Security Bootstrapping Solution for Resource-Constrained Devices draft-sarikaya-core-secure-bootsolution-00 Abstract We present a solution to initially configure the network of resource constrained nodes securely, a.k.a., security bootstrapping. The solution is based on EAP-TLS authentication with the use of raw public keys as certificates. 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 August 22, 2013. Copyright Notice Copyright (c) 2013 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. Sarikaya Expires August 22, 2013 [Page 1] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Secure Bootstrapping Architecture . . . . . . . . . . . . . . 3 3. Secure Bootstrapping Solution using Raw Public Keys . . . . . 4 4. Transporting EAP Messages . . . . . . . . . . . . . . . . . . 6 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Sarikaya Expires August 22, 2013 [Page 2] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 1. Introduction Bootstrapping is any processing required before the network can operate. The bootstrapping problem is not specific to any MAC or PHY. This problem exists across any two nodes which have no previous knowledge of each other. In particular, this problem is complicated when the nodes are resource-constrained and may not have an advanced user interface. Bootstrapping needs to be secure to make sure that the network operation is secure and hence secure bootstrapping ensures that only the authorized nodes can get access to the network. Because of this secure bootstrapping needs to preceed IP address configuration. [I-D.jennings-core-transitive-trust-enrollment] defines a protocol that enables sensors to securely connect into a system that uses them. The protocol which is being defined is based on the Device using HTTP or COAP [I-D.ietf-core-coap] to communicate with the Controller. This seems to assume that the device is already configured with an IP address. Such an assumption violates the assumption we have in this document on secure bootstrapping. Transport Layer Security (TLS) is commonly used protocol to secure web browsing, emailing, or other client-server applications. In TLS, the client and the server present their certificates and authenticate each other. Recently, raw public key extension is defined to be used as certificates [I-D.ietf-tls-oob-pubkey]. In this document we use the raw public keys in EAP-TLS. The document continues in Section 2 on bootstrapping architecture, in Section 3 on secure bootstrapping solution, in Section 4 on transporting EAP messages, in Section 5 on future work. 2. Secure Bootstrapping Architecture Security bootstrapping architecture is structured in a hierarchy of nodes going from the least resource constraint to the most resource constraint. At the top there is a root node. The root node is called Coordinator or Trust Center in Zigbee and 6LowPAN Border Router (6LBR) in 6LoWPAN ND. At the next level there are interior Routers. Routers are able to run a routing protocol between other routers and the root. Routers are called 6LowPAN Routers (6BR) in 6LoWPAN ND. At the lowest level there are the nodes. The nodes do not run a routing protocol. They can connect to the nearest router over a Sarikaya Expires August 22, 2013 [Page 3] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 single radio link. The nodes are called End Devices in Zigbee and hosts in 6LoWPAN ND. Routers first join the network as a node and go through security bootstrapping operations in order to create a Master Session Key (MSK). Next, routers execute routing protocol, e.g. [RFC6550] specific steps to create session keys with their neighbors and to establish upstream and downstream next hop parents. At each node hierarachy level described above, there are lower-layer and higher-layer protocols to bootstrap their ciphering keys, where the lower-layer refers to layers below IP layer including IEEE 802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer refers to IP layer and the above. In general, required bootstrapping procedures depend on the bootstrapping protocols to use. Section Section 3 describes the bootstrapping procedures where EAP (Extensible Authentication Protocol) [RFC3748] and other protocols are used as the bootstrapping protocols. 3. Secure Bootstrapping Solution using Raw Public Keys When a new resource-constrained device is deployed, it configures its global unique IPv6 address first. This is done by 6LoWPAN Neighbor Discovery (6LoWPAN-ND)'s Router Solicitation/Router Advertisement message exchange [RFC6775]. The newly generated IPv6 address can not be used until the joining device is authenticated and securely joins the network. After the authentication, the joining device receives the current group key of the network, so that the IPv6 registration and further communication can be protected by the link layer ciphering e.g. 802.15.4, then it can start using its global unique IPv6 address for communication. For authentication, Extensible Authentication Protocol (EAP) MUST be used. EAP authentication framework is explained in [RFC5247]. The EAP method EAP-TLS [RFC5216] can be used for the resource- constrained device authentication. Instead of X.509 certificates, raw public key of the device MUST be used. EAP-TLS is executed between the joining device and the AAA server which acts as the Authentication Server (AS). After a successful authentication, the device and the AAA server establish a Master Session Key (MSK), and then the AAA server exports the MSK to the authenticator. Upon receipt of the MSK, the authenticator distributes the group key to the joining device within the authentication success message. The group key is encrypted by a Key Encryption Key derived from the MSK. The resource-constrained device initiates the EAP authentication Sarikaya Expires August 22, 2013 [Page 4] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 process by sending a message of initiation to the authenticator, i.e. the root node or 6LBR. The root node requests the identity from the device by sending an EAP-Request/Identity packet. The device replies with an EAP-Response/Identity containing the device's ID. The identity information includes the device's network access ID (NAI). When the root node receives NAI of the device, it sends the identity information to the AS. The AS starts the EAP-TLS authentication process by sending a EAP- TLS/Start packet which is an EAP-Request packet with EAP-Type=EAP-TLS to the device. The device generates a client random number and responds with an EAP-Response/TLS-Client-Hello message which contains the TLS version, a client random number, a set of cipher suites. Only one cipher suite MUST be offered in Client-Hello message with RC4-SHA1. EAP-Response packet MUST have the EAP-Type value set at EAP-TLS Figure 1. The device MUST add an extension of type client certificate type and server certificate type defined in [I-D.ietf-tls-oob-pubkey] to Client-Hello message. Both of these types MUST be set to RawPublicKey. Upon receipt of Client Hello, if the AS supports raw public key extension, it generates a server random number, a new session ID, server certificate type set to RawPublicKey and includes only the SubjectPublicKeyInfo part of the certificate with its raw public key, rather than the whole certificate in the Certificate message and then sends them to the device with an EAP-Request/TLS-Server-Hello message. Server-Key-Exchange message contains a temporary key for the client to encrypt Client Key Exchange message. For the device, the server adds certificate request message to ask for the device's RawPublicKey using client certificate type message. Device receives AS's RawPublicKey. Device SHOULD verify the key using out of band mechanisms. Device sends Client Certificate message containing the device's RawPublicKey. With the client and server random number, the device generates a pre_master_secret, then sends it in Client-Key-Exchange field of EAP-Response/ TLS-Client-Finished message to the AS encrypting pre_master_secret with the temporary key in Server-Key-Exchange message. Device includes Change Cypher Spec message to indicate that all messages that follow Client Finished message will be encrypted. The AS derives the Master Session Key (MSK) and replies with EAP- Request/TLS-Server-Finished message. In this message, the server includes Change Cypher Spec message to indicate that the server will beging encrypting messages with the keys negotiated. The device also derives the MSK after receiving the Server Finished and acknowledges Sarikaya Expires August 22, 2013 [Page 5] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 with EAP-Response/EAP-TLS message. The AS then exports the MSK to the authenticator in RADIUS Access- Accept message, the authenticator subsequently sends the EAP-Success message to the device. The AS MUST send the group key in this message and the EAP-TLS ends. Device Authenticator Authentication | Server Device connects to | | Network | | |<----TLS-Start---------|<---EAP-Request--------| |-TLS-ClientHello------>|----EAP-Response------>| |client certificate type| | |server certificate type| | |<-TLS Server Hello-----|<----EAP-Request-------| | |server certificate type| | | Server Certificate | | |client certificate type| | | Certificate Request | | | Server Key Exchange | | | Server Hello Done | |TLS-ClientCertificate->|----EAP-Response------>| |Client Key Exchange | | |Change Cipher Spec | | |Client Finished | | ||----EAP-Response------>| | EAP-Success |<----EAP-Success-------| |Authentication finished| | Figure 1: Authentication Call Flow 4. Transporting EAP Messages EAP can be transported between the device and the authenticator either in Layer 3 using PANA [RFC5191] or in Layer 2 using IEEE 802.1X [802.1x]. EAP is transported using RADIUS [RFC2865] between the authenticator and authentication server. When a device is not a direct neighbor of the authenticator, its parent node MUST act as relay. Different EAP encapsulation protocols Sarikaya Expires August 22, 2013 [Page 6] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 have different mechanisms for the relay function, such as the PANA Relay Element (PRE). After the keys are established from a successful EAP method (such as EAP-TLS), the device runs neighbor discovery protocol to get an IPv6 address assigned [RFC6775]. Data transfer can be secured using DTLS or IPSec. Keys derived from EAP TLS are used in either generating DTLS ciphering keys after a successful DTLS handshake or IPSec ESP ciphering keys after a successful IKEv2 handshake. 5. Future Work The nodes in a constrained network called devices have wide range of capabilities and are used in diverse number of applications. Different secure bootstrapping solutions may apply to different applications and different types of nodes. In all cases, it is assumed in this document that the devices are IPv6 enabled. The solution described in Section 3 has the most stringent requirements on the devices and therefore is not suitable on less constrained nodes. It seems that the devices used in smart metering may have enough resources to run the bootstrapping protocol and they do not suffer from power constraints compared with most other devices such as light switches. One possible optimization in Figure 1 applies to the case where the device does not have a RawPublicKey. In this case the device sends only server_certificate_type set to RawPublicKey in Client-Hello message. In response, AS sends its RawPublicKey in Server Hello message. As a result the messages are much simpler than in Figure 1. Further optimizations to the EAP-TLS call flow in Figure 1 are TBD. Simpler devices such as light switches, environmental sensors, etc. may have much less resources, much less constrained IPv6 stack and they may not stay on for long periods of times required from the execution of the secure bootstrapping protocol. Identification of a set of applications with similar device capabilities is TBD. Modification of the protocol defined in Section 3 to define a secure bootstrapping protocol for each set is TBD. Sarikaya Expires August 22, 2013 [Page 7] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 6. Security Considerations When security bootstrapping resource constraint nodes is undertaken, several attacks are possible and security bootstrapping methods described in this document do not protect the nodes against such attacks. These attacks are similar to the ones described in [RFC3971] and mainly stem from unsecured link layer. Link layer must be secured on each node before the node can begin security bootstrapping. If a bootstrapping protocol does not rely on a pre-shared key for peer authentication, it must rely on an online or offline third-party (e.g., an authentication server, a key distribution center in Kerberos, a certification authority in PKI, a private key generator in ID-based cryptography and so on) to prevent man-in-the-middle attacks during peer authentication. Depending on use cases, a resource-constrained device may not always have access to an online third-party for peer authentication. Depending on use cases, a bootstrapping protocol may deal with authorization separately from authentication in terms of timing and signaling path. For example, two resource-constrained devices A and B may perform mutual authentication using authentication credentials provided by an offline third-party X whereas resource-constrained device A obtains authorization for running a particular application with resource-constrained device B from an online third-party Y before or after the authentication. In some use cases, authentication and authorization are tightly coupled, e.g., successful authentication also means successful authorization. A bootstrapping protocol supports various types of authentication and authorization or different bootstrapping protocols may be used for different types of authentication and authorization. If authorization information includes cryptographic keys, a special care must be taken for dealing with the keys, e.g., guidelines for AAA-based key management are described in [RFC4962]. A recommissioning use case may require revocation and re-installation of authentication credentials (i.e., a certificate or a shared secret and identity information, etc.) to a large number of resource- constrained devices that are already deployed. Re-installation of authentication credentials must be as secure as the initial installation regardless of whether the re-installation is done manually or automatically. If resource-constrained devices use a multicast group key for peer authentication or message authentication or encryption, the group key must be securely distributed to the current members of the group for both initial key distribution and key update. Protocols designed for Sarikaya Expires August 22, 2013 [Page 8] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 group key management such as GSAKMP [RFC4535], GDOI [RFC3547] and MIKEY [RFC3830] may be used for group key distribution. Alternatively, key wrap attributes for securely encapsulating group key may be defined in network access authentication protocols such as PANA [RFC5191] and EAP-TTLSv0 [RFC5281]. Those protocols use an end- to-end, point-to-point communication channel with a pair-wise security association between a key distribution center and each key recipient. Further considerations may be needed for more efficient group key management to support a large number of resource- constrained devices. 7. IANA Considerations This memo includes no request to IANA. 8. Contributors TBD. 9. Acknowledgements TBD. 10. References 10.1. Normative References [802.15.4] IEEE Std 802.15.4-2006, "Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs)", September 2006. [I-D.ietf-tls-oob-pubkey] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Out-of-Band Public Key Validation for Transport Layer Security (TLS)", draft-ietf-tls-oob-pubkey-07 (work in progress), February 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", Sarikaya Expires August 22, 2013 [Page 9] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 RFC 2865, June 2000. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [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. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. 10.2. Informative References [802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network Access Control", February 2010. [C1222] American National Standard, "Protocol Specification For Interfacing to Data Communication Networks", ANSI C12.22- 2008, 2008. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-13 (work in progress), December 2012. [I-D.jennings-core-transitive-trust-enrollment] Jennings, C., "Transitive Trust Enrollment for Constrained Devices", draft-jennings-core-transitive-trust-enrollment-01 (work in progress), October 2012. [NISTIR7628VOL1] The Smart Grid Interoperability Panel - Cyber Security Sarikaya Expires August 22, 2013 [Page 10] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 Working Group, "Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements", NISTIR 7628, vol. 1, 2010. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Sarikaya Expires August 22, 2013 [Page 11] Internet-Draft draft-sarikaya-core-secure-bootsolution February 2013 Extended Master Session Key (EMSK)", RFC 5295, August 2008. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [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. [ROMER04] Romer, K. and F. Mattern, "The design space of wireless sensor networks", IEEE Wireless Communications, vol. 11, no. 6, pp. 54-61, December 2004. [SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical Requirements Document", April 2010. Author's Address Behcet Sarikaya Huawei USA 5340 Legacy Dr. Plano, TX 75024 Email: sarikaya@ieee.org Sarikaya Expires August 22, 2013 [Page 12]