LWIG Working Group M. Sethi Internet-Draft V. Lehtovirta Intended status: Informational P. Salmela Expires: August 17, 2014 Ericsson February 13, 2014 Using Generic Bootstrapping Architecture with Constrained Devices draft-sethi-gba-constrained-01 Abstract This document discusses the use of the 3GPP Generic Bootstrapping Architecture (GBA) for authenticating and securing constrained devices. While GBA re-uses the 3GPP credentials, it does not require mobile network access, such as LTE, but requires only IP connectivity. Though building devices that employ GBA is obviously well known, this document specifically focuses on techniques necessary to minimize memory and energy consumption which is essential for constrained device networks. 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 17, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Sethi, et al. Expires August 17, 2014 [Page 1] Internet-Draft GBA Bootstrapping for constrained devices February 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Rational for using GBA . . . . . . . . . . . . . . . . . . 5 2. Reason for low power implementation of GBA . . . . . . . . . . 6 3. Implementation Considerations . . . . . . . . . . . . . . . . 7 3.1. Full HTTP stack is not needed . . . . . . . . . . . . . . 7 3.2. Resource-Constrained AES implementations are widely available . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Purging unnecessary functionality from memory after bootstrapping . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Complete State Machine or Complex Error Handling Are Not Needed . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 5. Future standardization work . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Informative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Sethi, et al. Expires August 17, 2014 [Page 2] Internet-Draft GBA Bootstrapping for constrained devices February 2014 1. Introduction Generic Bootstrapping Architecture (GBA) is part of the 3GPP standard [3gppts33220] 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 an 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) database. The permanent shared secret is used to generate a time- limited master key on the UE and the network operator. The UE and network operator derive a session key from the master key, and the network operator distributes this to the appropriate application server. This session key can then allow authentication and protection of the communication channel between the UE and application server. Figure 1 provides a high-level overview of GBA. Sethi, et al. Expires August 17, 2014 [Page 3] Internet-Draft GBA Bootstrapping for constrained devices February 2014 User Equipment Network Operator Application Server | | | |---- Authentication request --->| | | | | | | | |<--------- Challenge -----------| | | | | | | | |---------- Response ----------->| | | | | | | | |<- Bootstrapping ID, lifetime --| | | | | | | | |-------- Service request with Bootstrapping ID ----->| | | | | | | | |<-- Bootstrapping --| | | ID | | | | | |--- Session key --->| | | | | | | |<------------------- Confirmation to UE -------------| | | | | | | |<======== Secure Session Key Established ===========>| Figure 1: High Level Overview of GBA As shown in Figure 1, the UE initially identifies itself to the network operator and requests for authentication. The network operator responds by sending a challenge that can be correctly responded to, only with the permanent secret stored on the UICC. The UE responds to the challenge using the permanent secret on the UICC. The network operator then verifies the response and if it is found to be valid, it derives a master key and returns a bootstrapping ID to the UE. The UE then derives a session key from the master key and initiates a secure connection with the application server with which it wants to communicate and provides the bootstrapping ID obtained in the previous step. The application server uses the bootstrapping ID to obtain a session key from the network operator. The session key is derived from the master key by the network operator. The network operator authenticates the application server before generating and revealing the session key. Once the application server is authenticated, it receives the session key. The application authenticates the original message from UE with this session key. If Sethi, et al. Expires August 17, 2014 [Page 4] Internet-Draft GBA Bootstrapping for constrained devices February 2014 authenticated correctly, the application server sends a confirmation message to the UE indicating that it can now protect the communication with the session key. While in this scenario, the UE is responsible for initiating secure communication with the application server, the GBA standard also allows the application server to inform the UE to perform GBA authentication for access to the requested resource. In 3GPP terminology, the application server is referred to as Network Application Function (NAF) and the cellular operator interface is referred to as Bootstrapping Server Function (BSF). The bootstrapping ID is known as the Bootstrapping Transaction Identifier (B-TID) The current GBA standard requires HTTP and TCP along with crypto algorithms like AES and MD5 to be supported on the UE. While the implementation details may be obvious for a UE, using GBA for authentication and channel security on resource-constrained devices may be non-trivial. This draft provides implementation guidelines for using GBA authentication on resource-constrained devices. 1.1. Terminology This draft uses terminologies for constrained devices defined in [I-D.ietf-lwig-terminology]. 1.2. Rational for using GBA In principle, GBA can be used to protect any application traffic, e.g. with TLS, as GBA provides shared keys for applications to use. Using shared keys avoids the need for complex calculations of asymmetric crypto and the need for verifying certificate chains and checking revocation lists. Instead, GBA relies on the security infrastructure of the network operator. Even though GBA re-uses the credentials stored on the UICC, use of GBA does not require mobile network access, such as LTE, but requires only IP connectivity to the network operator infrastructure. As the credentials of the UICC are used by GBA, there is no need to remember or store passwords to authenticate to applications, and in principle a button-free authentication can be implemented. Sethi, et al. Expires August 17, 2014 [Page 5] Internet-Draft GBA Bootstrapping for constrained devices February 2014 2. Reason for low power implementation of GBA As explained in [I-D.draft-ietf-lwig-cellular-00] there are many situations where focus on a low energy consuming implementation is unnecessary. This would be the case, when for example, the devices are connected to the main, or receive power over wired communications media, such as in Power-over-Ethernet (PoE) devices. Such devices require a limited amount of optimization for energy efficiency. Similarly, devices that are directly connected to the mains do not require extreme optimizations and/or hacks for saving power. Also devices that can gather power from energy harvesting do not necessarily need optimization techniques. However, wirelessly connected battery powered sensors and actuators are the future and existence of wired infrastructure for communication or power might be impossible or impractical. Such devices require highly efficient implementations of security and network protocols as changing batteries frequently is not possible because of the sheer number of devices and the fact that some of these devices may be physically inaccessible once installed. Unfortunately, much of our current network and security technology is built with different objectives in mind. Networked devices are assumed to be "always on", and require frequent re-charging. However, most sensor and actuator applications require long battery lifetimes, in the order of years or even a decade, if not longer. While some devices may already reach multi-year lifetimes with continuous improvement in low-power electronics and radio technology, it is rather reasonable to note that battery lifetimes are generally too short currently. Therefore, to use GBA as a mechanism for secure bootstrapping for constrained device applications, a more focused effort is required to ensure an energy-efficient implementation. This memo is a first step for defining considerations and guidelines to achieve an energy-efficient GBA implementation. Sethi, et al. Expires August 17, 2014 [Page 6] Internet-Draft GBA Bootstrapping for constrained devices February 2014 3. Implementation Considerations In this section we describe implementation guidelines that apply to GBA on constrained devices in particular but can be used in general for implementing other similar related network protocols. 3.1. Full HTTP stack is not needed GBA relies on HTTP digest authentication and requires the client to implement an HTTP stack. Although HTTP client libraries for constrained devices [small-http] are available, they are often unnecessary. This is because the number of HTTP messages required for a GBA-run is small and having an entire library consumes more memory than the templates for these messages. Thus, the required messages can be handcrafted and sent over TCP. Thanks to the plain text nature of HTTP/1.1 this is rather easy to do. An example of a minimalistic HTTP packet is shown here: char httpFirstRequestFormat[82] = "GET /naf/resource HTTP/1.1\r\n" "Host: p123.example.net:8080\r\n" "Connection: Keep-Alive\r\n" "\r\n"; Similarly, the response can easily be parsed from the packets received from the transport layer without necessarily performing all error checks. If an unknown packet or unknown data is received, the application can simply re-start from the first exchange. 3.2. Resource-Constrained AES implementations are widely available AES is rather easy to implement. There are many open source implementations available specifically for resource-constrained environments [gladman], [avr-crypto-lib]. There are several resources [jpkaps06],[shammid] that show that AES can be implemented with low memory and energy consumption. Also many constrained devices and platforms such as the MicaZ motes are equipped with an AES hardware engine as part of the IEEE 802.15.4 (Zigbee)-compliant RF module. 3.3. Purging unnecessary functionality from memory after bootstrapping Once a GBA bootstrapping round has finished, only the session key (KsNAF) and B-TID need to be retained in the memory. Optinally, the master key (Ks) and the key derivation function can be retained in the memory if the device will be connecting to multiple NAFs. If a GBA run is only used for authentication, then all GBA related code can be purged from the memory. This means that any libraries or code used for application, transport or cryptography during a GBA run can Sethi, et al. Expires August 17, 2014 [Page 7] Internet-Draft GBA Bootstrapping for constrained devices February 2014 be purged and loaded back into the memory when the lifetime of the key expires. This is especially useful with long lived session keys as the device can switch to other application (CoAP) and routing/ transport (RIPL/UDP) protocol after secure bootstrapping. 3.4. Complete State Machine or Complex Error Handling Are Not Needed A typical GBA implementation requires a state-machine to track messages that have been sent and received from the BSF and NAF. However, implementing such a state-machine with appropriate error handling can be rather complex for resource-constrained device. It is therefore advisable for such devices to implement a simple hard fail-over starting from the first message in case of an error, unknown packet or timeout. However, there also needs to be a limit to the number of fail-overs as the device might drain its battery from too many failed GBA authentication tries. Sethi, et al. Expires August 17, 2014 [Page 8] Internet-Draft GBA Bootstrapping for constrained devices February 2014 4. Implementation Status In this section we describe our GBA implementation that was developed for prototyping GBA on constrained devices using the principles described in the previous section. We used an Arduino Mega prototyping board [mega] and an Ethernet Shield for communication. The Mega board has an 8-bit ATmega2560 microprocessor. For AES, we used Brian Gladman's byte oriented AES implementation [gladman]. Similarly, we used easily available C implementations of SHA256 [sha256] and MD5 [md5]. The default Ethernet and TCP libraries available with the Arduino platform were used for communication. We tested this GBA implementation against standard 3GPP BSF and NAF interfaces running on our public servers. The sequence of messages for the resource-constrained (sensor/actuator) device in our implementation is as follows: Sethi, et al. Expires August 17, 2014 [Page 9] Internet-Draft GBA Bootstrapping for constrained devices February 2014 Sensor/ Actuator BSF NAF | | | |-------------- HTTP GET /naf/resource -------------->| | | | | | | |<------------------- 401 Unauthorized ---------------| | | | | | | |--- HTTP GET /bsf/bootstrap --->| | | | | | | | |<------ 401 Unauthorized -------| | | | | | | | |--- HTTP GET with username/ --->| | | password from AKA | | | | | | | | |<------- 200 with B-TID --------| | | | | | | | |---- HTTP GET username=B-TID password=KsNAF -------->| | | | | | | |<----------------------------200 OK -----------------| | | | | | | |<=========== Secure Session Key Established ========>| Figure 2: Prototype message sequence The sensor/actuator begins by contacting the service with which it wishes to communicate (NAF in 3GPP terminology). This means that the sensor sends a HTTP GET for the resource which it wishes to access. The service/NAF in-turn replies with a HTTP 401 Unauthorized with WWW-Authenticate indicating that it requires digest authentication for access to that resource. The HTTP response header also contains the realm prefixed with "3GPP-Bootstrapping@" to indicate that a GBA run can be performed to obtain the appropriate keys for digest authentication. The sensor then contacts the BSF hosted by the operator by sending a HTTP GET. This again results in a 401 unauthorized with the HTTP header containing "algorithm=AKAv1-MD5" indicating that AKA authentication needs to be run. The sensor then creates and sends another HTTP GET containing the username and password from AKA to the BSF. The BSF now replies with an 200 OK message whose body contains the B-TID and the lifetime for which the Sethi, et al. Expires August 17, 2014 [Page 10] Internet-Draft GBA Bootstrapping for constrained devices February 2014 B-TID and the derived master key (Ks) would be valid. Finally, the sensor contacts the service/NAF with a HTTP GET containing the B-TID as the username and KsNAF as the password. KsNAF is obtained from the master key Ks and the fully qualified domain name (FQDN) of the NAF. If the service/NAF replies with a 200 OK, the sensor is assured of successful authentication. The sensor and NAF can then use the session key for TLS/DTLS in PSK mode. This key can also be used for message level encryption and/or integrity protection by using, for example, the EAX [mihir04] mode. Some approximate results from our prototype are listed in the table below: +----------------------------------------+-------+ | RAM consumption | <5 kB | | | | | ROM consumption | 44 kB | | | | | Time for 1 GBA run | 1.5 s | | | | | Energy (W =U * I * t) | 150mJ | | | | | Additional HTTP messages sent/received | 8 | +----------------------------------------+-------+ Prototype Details Table 1 U=Operating Voltage (5V), I=Current drawn (0.02A for Atmega2560), t=Execution time (1.5 s) The energy estimate and time for 1 GBA run would vary significantly depeding on the network access (which in our case was Ethernet). Sethi, et al. Expires August 17, 2014 [Page 11] Internet-Draft GBA Bootstrapping for constrained devices February 2014 5. Future standardization work While we have shown how the current GBA standard can be used as a method for secure bootstrapping of constrained devices, it would also useful in future for 3GPP and IETF to define GBA over protocols other than HTTP/TCP. Sethi, et al. Expires August 17, 2014 [Page 12] Internet-Draft GBA Bootstrapping for constrained devices February 2014 6. Security Considerations GBA is used for authenticating a device based on the 3GPP subscription credentials stored in the device. Normally the credentials are stored on a UICC, but also embedded UICCs (eUICC) are possible. eUICCs are targeted for scenarios where the 3GPP subscription should be changeable remotely, without having to physically exchange the card in the device. Both UICCs and eUICCs provide hardware based protection for the subscription credentials used for authentication in 3GPP networks. However, in addition it is also essential to protect the access to the (e)UICC from applications to protect against Man-in-the-Middle (MitM) type of attacks [3gpptr33905]. If a UICC or eUICC is not available, GBA digest is an option [3gppts33220]. GBA digest uses SIP digest credentials, basically a username/password pair and secret deducted from TLS, to do GBA. The security requirement defined by 3GPP for the SIP digest credentials are that they need to be securely stored within the terminal. Sethi, et al. Expires August 17, 2014 [Page 13] Internet-Draft GBA Bootstrapping for constrained devices February 2014 7. Acknowledgments The authors would like to thank Bengt Sahlin, Jari Arkko and Ari Keranen for the interesting discussions on this topic. Sethi, et al. Expires August 17, 2014 [Page 14] Internet-Draft GBA Bootstrapping for constrained devices February 2014 8. IANA Considerations This document has no IANA actions. Sethi, et al. Expires August 17, 2014 [Page 15] Internet-Draft GBA Bootstrapping for constrained devices February 2014 9. Informative References [3gpptr33905] 3GPP, "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Recommendations for Trusted Open Platforms", September 2012, . [3gppts33220] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) (Release 12)", March 2013, . [I-D.draft-ietf-lwig-cellular-00] Arkko, J., Eriksson, A., and A. Keranen, "Building Power- Efficient CoAP Devices for Cellular Networks", draft-ietf-lwig-cellular-00 (work in progress), December 2013. [I-D.ietf-lwig-terminology] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained Node Networks", draft-ietf-lwig-terminology-06 (work in progress), August 2013. [avr-crypto-lib] "AVR Crypto-lib", December 2013, . [gladman] "Byte Oriented AES (Low Resource Version)", December 2013, . [jpkaps06] Kaps, JP. and B. Sunar, "Energy comparison of AES and SHA-1 for ubiquitous computing", Emerging Directions in Embedded and Ubiquitous Computing. Springer Berlin , 2006. [md5] "MD5", December 2013, . [mega] "Arduino Mega", December 2013, . [mihir04] Bellare, M., Rogaway, P., and D. Wagner, "The EAX mode of operation", Fast Software Encryption. Springer Berlin Heidelberg , 2004. Sethi, et al. Expires August 17, 2014 [Page 16] Internet-Draft GBA Bootstrapping for constrained devices February 2014 [sha256] "SHA256", December 2013, . [shammid] Didla, S., Ault, A., and S. Bagchi, "Optimizing AES for embedded devices and wireless sensor networks", 4th International Conference on Testbeds and research infrastructures for the development of networks & communities , 2008. [small-http] "HttpClient for Arduinos", December 2013, . Sethi, et al. Expires August 17, 2014 [Page 17] Internet-Draft GBA Bootstrapping for constrained devices February 2014 Authors' Addresses Mohit Sethi Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: mohit.m.sethi@ericsson.com Vesa Lehtovirta Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: vesa.lehtovirta@ericsson.com Patrik Salmela Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: patrik.salmela@ericsson.com Sethi, et al. Expires August 17, 2014 [Page 18]