Extensible Authentication Protocol (EAP) in next-generation networks

With EAP being a fundamental part of 5G and the strong interest in using EAP as a unifying authentication framework in IoT, its importance is likely to increase.

Ericsson has played a key role in driving the recent development of EAP methods to current best practices for security and privacy, as well as expanding the use of EAP to mobile networks and the Internet of Things (IoT). But how has the security and privacy of EAP recently evolved? And how do different EAP methods compare? Let’s deep dive into its recent progress and discuss how EAP might evolve in the future.

The Extensible Authentication Protocol (EAP)

EAP is an authentication framework used by networks for authenticating devices (the EAP peers) before they are authorized to access the internet and other network services. EAP itself is not an authentication mechanism – it is a framework that supports a large number of authentication methods. Over the years, many different EAP methods have been standardized, including some vendor-specific methods. EAP is commonly run directly over the link layer before IP connectivity is established. Each link layer defines how it encapsulates EAP packets and each EAP method defines how it is encapsulated in EAP packets. EAP is standardized by the Internet Engineering Task Force (IETF), currently in the EMU working group.

The main advantage of EAP is its flexibility. When a backend authentication server is used, the access network (including the authenticator) is just acting as a pass-through to the backend authentication server (the EAP server), which implements the authentication methods. To connect to the network, the EAP peer typically uses a Network Access Identifier (NAI) such as @operator.net or @industry.net, and the authenticator finds the correct EAP server based on the realm (operator.net or industry.net). By using an anonymous NAI, the username of the device is never sent in cleartext. The interface between authenticator and the EAP server is typically RADIUS or DIAMETER. The EAP server might forward the EAP messages to a different authentication server (used, for example, in 3GPP roaming). Figure 1 shows a typical enterprise deployment of EAP for Ethernet and Wi-Fi access authentication. Modern EAP methods support mutual authentication and derive several keys: Master Session Key (MSK) shared between the EAP peer and the authenticator and Extended MSK (EMSK) shared between the EAP peer and the EAP server.

Figure 1: EAP with backend EAP servers in an IEEE 802 network.

The EAP protocol is defined in RFC 3748. Other aspects of the EAP framework such as a state machine, network discovery and selection, EAP key hierarchy, man-in-the-middle attacks, and channel bindings are discussed in companion documents, and all modern EAP methods are defined in their own specifications.

EAP Authentication Framework and its role in 5G

In 4G and earlier cellular networks, EAP authentication was used for non-3GPP access networks such as Wi-Fi connected to a 4G core network. Furthermore, EAP authentication was limited to the 3GPP specific EAP-AKA method using a pre-shared key stored in a USIM. While the term SIM card is often used in popular media, the USIM is technically just an application that can reside on a removable UICC, an embedded UICC, or integrated in a Trusted Execution Environment (TEE).

In 5G, EAP authentication is always possible for both 3GPP and non-3GPP access. Access authentication in 5G is called primary authentication while the term secondary authentication is used for user connections to set up user plane connections to data networks outside of the mobile operator domain. EAP can be used for both primary and secondary authentication as defined in 3GPP TS 33.501.

Public 5G networks are the traditional type of mobile networks owned and controlled by a mobile network operator (MNO) and intended to be used by the public, with millions of subscribers on a typical nationwide network. For public 5G networks, EAP-AKA or 5G-AKA (5G AKA without EAP encapsulation) can be used for primary authentication and any EAP method such as EAP-AKA, EAP-TLS, or EAP-TTLS can be used for secondary authentication.

Private 5G networks are an exciting new technology and are quickly gaining traction. These networks use the same underlying technology as public 5G networks but are intended to be used by a single enterprise or organization such as industrial facilities, hospitals, ports, and other mission-critical infrastructure. With ample bandwidth, high data rates, ultra-low latency, and high reliability, private 5G networks are essential for many smart manufacturing installations. Private networks come in several different deployment models. They can be built and maintained by an MNO or by the organization using it in a so-called standalone network. Common for all private 5G networks is that any EAP method can be used also for primary authentication, i.e., access authentication. The default mechanism for certificate-based authentication in private 5G networks is EAP-TLS and 3GPP has already mandated support for EAP-TLS 1.3. Another alternative is EAP Tunneled Transport Layer Security (EAP-TTLS), which uses TLS as a tunnel. After the server authenticated TLS connection has been established, the client is typically authenticated using a legacy password mechanism.

An update of EAP-AKA’ describes the EAP using the latest version of the 3GPP Authenticated Key Agreement (AKA) used in 5G. It has been standardized by IETF as RFC 9048 and is referenced by 3GPP. EAP-AKA-PFS is currently being standardized by the IETF, it augments EAP-AKA’ with forward secrecy and will hopefully be supported in future 5G releases.

Two security properties that are now established best practices are client identity protection and forward secrecy. Forward secrecy protects against key compromise which can happen due to bugs, side-channel, hacking attacks, or insiders anywhere in the supply chain. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. Forward secrecy is therefore a requirement for zero-trust. Another well-established best practice is that security and privacy should be mandatory, not optional. Modern authentication mechanisms such as EAP-TLS 1.3 and WPA3 (used in WiFi) mandates forward secrecy. Table 1 provides an overview of authentication methods that can be used in 5G networks. As of now, mechanisms following best practice security and privacy can only be used for primary authentication in private networks. If a mechanism without forward secrecy (5G-AKA, EAP-AKA’) is used the effects of key compromise are devastating. An attacker can passively eavesdrop on all future and past communication and impersonate both the 5G UE and the 5G network. An attacker can, for example, decrypt communication that was recorded in the past and inject messages into an ongoing 5G connection between the real UE and the real network. Ericsson will drive the inclusion of forward secrecy mechanisms aligning with zero-trust principles for public 5G networks in future 3GPP releases.

Table 1: Overview of authentication methods that can be used in 5G networks.

The use of EAP in IoT

Enabling internet access is one of the primary procedures necessary for bootstrapping IoT devices. IoT deployments are highly heterogeneous when it comes to device and radio capabilities, user interfaces, network architectures, and business models. IoT security in constrained environments comes with many restrictions in terms of cost, energy consumption, memory, processing, and latency. As IoT devices handle a lot of sensitive information and interact with the environment, the security requirements are very high, but due to the heterogeneity and restrictions, many current IoT deployments have obvious security weaknesses that can be used to attack the IoT deployment itself or other infrastructure through distributed denial-of-service attacks.

EAP makes a lot of sense in many of these IoT scenarios and there has recently been significant interest and activity regarding the use of EAP for IoT. Several of the current methods such as EAP-TLS and EAP-TTLS are suitable for many kinds of IoT deployments, but they were not designed for IoT. EAP-TLS and EAP-TTLS lack features desirable in many IoT deployments and the large message sizes make them unsuitable for constrained IoT radio.

IETF is currently working on transport of EAP over the Constrained Application Protocol (CoAP) which specifies how to use EAP to key Object Security for Constrained RESTful Environments (OSCORE). IETF is likely to continue working on more EAP methods tailored for IoT bootstrapping that combines authentication with bootstrapping, as well as EAP methods with very small messages for constrained IoT based on Ephemeral Diffie-Hellman Over COSE (EDHOC) and Compact TLS 1.3 (cTLS).

EAP Transport Layer Security (EAP-TLS)

EAP Transport Layer Security (EAP-TLS) uses the TLS handshake for certificate-based authentication over EAP. EAP-TLS is supported in almost all network equipment and operating systems and widely used for authentication and key establishment in IEEE 802.3 (Ethernet), IEEE 802.11 (Wi-Fi) and IEEE 802.1AE (MACsec) networks using IEEE 802.1X. Unfortunately, the underlying TLS version, 1.2, requires a large amount of hardening to be secure. EAP-TLS 1.2 (EAP-TLS with TLS 1.2) specification mandates support of several weak algorithms and options, perfect-forward secrecy and revocation is optional, and the optional identity protection is seldomly used as is it both slow and open to bidding-down attacks.

The latest version EAP-TLS 1.3 (EAP-TLS with TLS 1.3) was published as RFC 9190 in February 2022. It is a major update that fixes these shortcomings, as well as improves performance. It is implemented in several operating systems and network equipment, and long term is expected to completely replace the earlier version. NIST requires support of TLS 1.3 by January 2024 everywhere without exceptions. If followed, this means that the obsolete TLS 1.2 is not negotiated. Figure 2 shows the message flow for a successful authentication with EAP-TLS 1.3

Figure 2: Successful mutual authentication with EAP-TLS 1.3.

EAP-TLS is also the basis for many other TLS-based EAP methods such as EAP-FAST, EAP-TTLS, TEAP, and PEAP. IETF is working on updating all the other TLS-based EAP methods to TLS 1.3. The specification for these updates will likely be published in late 2022.

Large certificates and long certificate chains have become a problem for some deployments of EAP as authenticators often drop an EAP session after only 40-50 roundtrips. As large TLS flights are fragmented into many EAP packets, authentication with unusually large certificates and long certificate chains might not be possible. The problem is expected to get worse when Post-Quantum Cryptography is deployed as both public keys and signatures will be significantly larger than RSA and ECC which are the commonly used algorithms today. IETF has published the guidance document RFC 9191, illustrating the problem and potential solutions.

The future of EAP

IETF has started discussions on making an update to the base EAP specification RFC 3748. The original document is holding up well, but there are several strong reasons why an update is needed. Several of the companion documents such as the EAP state machines have become essential parts of the EAP framework. RFC 3748 is also very focused on IEEE technologies which does not give a correct view of current usage in 5G and non-IEEE IoT technologies. Security and privacy requirements have increased significantly since 2004, mandatory identity protection and perfect forward secrecy are now seen as requirements but are only briefly mentioned in RFC 3748. IETF is also discussing how to enable simpler, secure, and automatic certificate management for EAP peers and servers using TLS-based EAP methods. The certificate management is currently not standardized which may lead to interoperability issues. Current implementation puts a lot of responsibility on the administrators and misconfigurations have led to vulnerabilities.

We believe that EAP has a bright future. It is already the dominating authentication framework in IEEE technologies. With EAP being a fundamental part of 5G and the strong interest to use EAP as a unifying authentication framework in IoT, the importance of EAP is likely to increase.

Want to learn more?

Read John’s previous blog post: The evolution of cryptography in mobile networks and how to secure them in the future.

Read more about our network security research.

Explore IoT.