Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)

Abstract

Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles.¶

This specification updates RFC 9048, the EAP-AKA' authentication method, with an optional extension. Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead.¶

1. Introduction

Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Such attacks are conceivable, for instance, during the manufacturing process of cards, or during the transfer of cards and associated information to the operator. Since the publication of reports about such attacks, manufacturing and provisioning processes have gained much scrutiny and have improved.¶

However, the danger of resourceful attackers attempting to gain information about SIM cards is still a concern. They are a high-value target and concern a large number of people. Note that the attacks are largely independent of the used authentication technology; the issue is not vulnerabilities in algorithms or protocols, but rather the possibility of someone gaining unlawful access to key material. While the better protection of manufacturing and other processes is essential in protecting against this, there is one question that we as protocol designers can ask. Is there something that we can do to limit the consequences of attacks, should they occur?¶

The authors want to provide a public specification of an extension that helps defend against one aspect of pervasive surveillance. This is important, given the large number of users such practices may affect. It is also a stated goal of the IETF to ensure that we understand the surveillance concerns related to IETF protocols and take appropriate countermeasures [RFC7258]. This document does that for EAP-AKA'.¶

This specification updates [RFC9048], the EAP-AKA' authentication method, with an optional extension and strengthens the identity privacy requirements. While optional, the use of this extension is strongly RECOMMENDED.¶

The extension, when negotiated, provides Forward Secrecy (FS) for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead. This is beneficial, because active attacks demand much more resources to launch, and can generally be detected much easier. As with other protocols, an active attacker with access to the long-term key material will of course be able to attack all future communications, but risks detection, particularly if done at scale. The attacker is forced to attempt to exfiltrate key material, if it can, on a continuous basis, as opposed to learning it once [RFC7624].¶

Attacks against AKA authentication via compromising the long-term secrets in the SIM cards have been an active discussion topic in many contexts. Forward secrecy is on the list of features for the next release of 3GPP (5G Phase 2), and this document provides a basis for providing this feature in a particular fashion.¶

It should also be noted that 5G network architecture [TS.33.501] includes the use of the EAP framework for authentication. While any methods can be run, the default authentication method within that context will be EAP-AKA'. As a result, improvements in EAP-AKA' security have a potential to improve security for large number of users.¶

2. Protocol Design and Deployment Objectives

The extension specified here re-uses large portions of the current structure of 3GPP interfaces and functions, with the rationale that this will make the construction more easily adopted. In particular, the construction maintains the interface between the Universal Subscriber Identification Module (USIM) and the mobile terminal intact. As a consequence, there is no need to roll out new credentials to existing subscribers. The work is based on an earlier paper [TrustCom2015], and uses much of the same material, but applied to EAP rather than the underlying AKA method.¶

It has been a goal to implement this change as an extension of the widely supported EAP-AKA' method, rather than a completely new authentication method. The extension is implemented as a set of new, optional attributes, that are provided alongside the base attributes in EAP-AKA'. Old implementations can ignore these attributes, but their presence will nevertheless be verified as part of base EAP-AKA' integrity verification process, helping protect against bidding down attacks. This extension does not increase the number of rounds necessary to complete the protocol.¶

The use of this extension is at the discretion of the authenticating parties. It should be noted that FS and defenses against passive attacks are by no means a panacea, but they can provide a partial defense that increases the cost and risk associated with pervasive surveillance.¶

While adding forward secrecy to the existing mobile network infrastructure can be done in multiple different ways, the authors believe that the approach chosen here is relatively easily deployable. In particular:¶

• As noted above, no new credentials are needed; there is no change to SIM cards.¶
• FS property can be incorporated into any current or future system that supports EAP, without changing any network functions beyond the EAP endpoints.¶
• Key generation happens at the endpoints, enabling highest grade key material to be used both by the endpoints and the intermediate systems (such as access points that are given access to specific keys).¶
• While EAP-AKA' is just one EAP method, for practical purposes forward secrecy being available for both EAP-TLS [RFC5216] [RFC9190] and EAP-AKA' ensures that for many practical systems forward secrecy can be enabled for either all or significant fraction of users.¶

3. Background

4. Requirements Language

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

5. Protocol Overview

Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange [RFC7748]. To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate temporary keys according to the negotiated ciphersuite, e.g., for X25519 this is done as specified in [RFC7748]. This method is referred to as ECDHE, where the last 'E' stands for Ephemeral. The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 [TS.33.501].¶

The enhancements in the EAP-AKA' FS protocol are compatible with the signaling flow and other basic structures of both AKA and EAP-AKA'. The intent is to implement the enhancement as optional attributes that legacy implementations can ignore.¶

The purpose of the protocol is to achieve mutual authentication between the EAP server and peer, and to establish keying material for secure communication between the two. This document specifies the calculation of key material, providing new properties that are not present in key material provided by EAP-AKA' in its original form.¶

Figure 2 below describes the overall process. Since our goal has been to not require new infrastructure or credentials, the flow diagrams also show the conceptual interaction with the USIM card and the 3GPP authentication server (HSS). The details of those interactions are outside the scope of this document, however, and the reader is referred to the 3GPP specifications.¶

6. Extensions to EAP-AKA'

MK       = PRF'(IK'|CK',"EAP-AKA'"|Identity)
MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)
K_encr   = MK[0..127]
K_aut    = MK[128..383]
K_re     = MK_ECDHE[0..255]
MSK      = MK_ECDHE[256..767]
EMSK     = MK_ECDHE[768..1279]

7. Security Considerations

This section deals only with the changes to security considerations as they differ from EAP-AKA', or as new information has been gathered since the publication of [RFC9048].¶

The possibility of attacks against key storage offered in SIM or other smart cards has been a known threat. But as the discussion in Section 3.3 shows, the likelihood of practically feasible attacks such as breaches in the smart card supply chain has increased. Many of these attacks can be best dealt with improved processes, e.g., limiting the access to the key material within the factory or personnel, etc. But not all attacks can be entirely ruled out for well-resourced adversaries, irrespective of what the technical algorithms and protection measures are. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles.¶

If a mechanism without forward secrecy such as (5G-AKA, EAP-AKA') is used the effects of key compromise are devastating. The serious consequences of breach somewhere in the supply chain or after delivery that are possible when 5G-AKA or EAP-AKA' is used but not when something with forward secrecy like EAP-AKA-FS is used are:¶

1. A passive attacker can eavesdrop (decrypt) all future 5G communication (control and user plane both directions),¶
2. A passive attacker can decrypt 5G communication that they previously recorded in the past (control and user plane both directions), and¶
3. An active attacker can impersonate UE and Network and inject messages in an ongoing 5G connection between the real UE and the real network (control and user plane both directions).¶

Best practice security today is to mandate forward secrecy (as is done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, IKEv2, SSH, QUIC, WireGuard, Signal, etc.). It is RECOMMENDED to long term completely phase out AKA without forward secrecy.¶

This extension can provide assistance in situations where there is a danger of attacks against the key material on SIM cards by adversaries that cannot or who are unwilling to mount active attacks against large number of sessions. The extension also provides protection against active attacks as they are forced to be a Man-In-The-Middle (MITM) during the AKA run and subsequent communication between the parties. Without forward secrecy an active attacker that has compromised the long-term key can inject messages in an connection between the real Peer and the real server without being a man-in-the-middle. This extension is most useful when used in a context where EAP keys are used without further mixing that can provide Forward Secrecy. For instance, when used with IKEv2 [RFC7296], the session keys produced by IKEv2 have this property, so better characteristics of EAP keys is not that useful. However, typical link layer usage of EAP does not involve running Diffie-Hellman, so using EAP to authenticate access to a network is one situation where the extension defined in this document can be helpful.¶

This extension generates keying material using the ECDHE exchange in order to gain the FS property. This means that once an EAP-AKA' authentication run ends, the session that it was used to protect is closed, and the corresponding keys are forgotten, even someone who has recorded all of the data from the authentication run and session and gets access to all of the AKA long-term keys cannot reconstruct the keys used to protect the session or any previous session, without doing a brute force search of the session key space.¶

Even if a compromise of the long-term keys has occurred, FS is still provided for all future sessions, as long as the attacker does not become an active attacker. Of course, as with other protocols, if the attacker has learned the keys and does become an active attacker, there is no protection that that can be provided for future sessions. Among other things, such an active attacker can impersonate any legitimate endpoint in EAP-AKA', become a MITM in EAP-AKA' or the extension defined in this document, retrieve all keys, or turn off FS. Still, past sessions where FS was in use remain protected.¶

Achieving FS requires that when a connection is closed, each endpoint MUST forget not only the ephemeral keys used by the connection but also any information that could be used to recompute those keys.¶

Using EAP-AKA' FS once provides forward secrecy. Forward secrecy limits the effect of key leakage in one direction (compromise of a key at time T2 does not compromise some key at time T1 where T1 < T2). Protection in the other direction (compromise at time T1 does not compromise keys at time T2) can be achieved by rerunning ECDHE frequently. If a long-term authentication key has been compromised, rerunning EAP-AKA' FS gives protection against passive attackers. Using the terms in [RFC7624], forward secrecy without rerunning ECDHE does not stop an attacker from doing static key exfiltration. Frequently rerunning EC(DHE) forces an attacker to do dynamic key exfiltration (or content exfiltration).¶

8. IANA Considerations

This extension of EAP-AKA' shares its attribute space and subtypes with EAP-SIM [RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC9048].¶

Two new values (TBA1, TBA2) in the skippable range need to be assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS (Section 6.2 in the "Attribute Types" registry under the "EAP-AKA and EAP-SIM Parameters" group.¶

Also, a new registry "EAP-AKA' AT_KDF_FS Key Derivation Function Values" should be created to represent FS Key Derivation Function types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA' with ECDHE and P-256" types (1 and 2, see Section 6.3) need to be assigned, along with one reserved value. The initial contents of this registry is illustrated in Table 1; new values can be created through the Specification Required policy [RFC8126].¶

9. References

Appendix A. Change Log

RFC Editor: Please remove this appendix.¶

The -09 version of the WG draft has the following changes:¶

• Scalable Vector Graphics (SVG) versions for all figures has been added and the figures has been slightly modified to render nicely with aasvg.¶
• A reference has been added to the Section in SEC1 describing how to do decompression.¶
• The strengthened identity protection requirements are now mentioned in the introduction.¶
• Corrections and clarifications were made in the IANA considerations. The table in the IANA section has been made into a proper xml table.¶
• Reference updates.¶
• Various editorial improvements.¶

The -08 version of the WG draft has the following changes:¶

• Further clarification of key calculation in Section 6.3.¶
• Support for the NIST P-256 group has been made mandatory in Section 6.4, in order to align the requirements with 3GPP SUCI encryption requirements.¶
• The interaction between AT_KDF and AT_KDF_FS has been specified more clearly, including specifying how future specifications need to specify the treatment of new combinations.¶
• Addition of a discussion about the impacts of potential future quantum computing attacks with specific impacts to this extension.¶
• Addition of a discussion about metadata/unprotected data in Section 7.4.¶
• Reference updates.¶
• Various editorial improvements.¶

The -07 version of the WG draft has the following changes:¶

• The impact of forward secrecy explanation has been improved in the abstract and security considerations.¶
• The draft now more forcefully explains why the authors believe it is important to migrate existing systems to use forward secrecy, and makes a recommendation for this migration.¶
• The draft does no longer refer to issues within the smart cards but rather the smart card supply chain.¶
• The rationale for chosen algorithms is explained.¶
• Also, the authors have checked the language relating to the public value encoding, and believe it is exactly according to the references ([RFC7748] Section 6.1 and [SEC2] Section 2.7.1)¶

The -06 version of the WG draft is a refresh and a reference update. However, the following should be noted:¶

• The draft now uses "forward secrecy" terminology and references RFC 7624 per recommendations on mailing list discussion.¶
• There's been mailing list discussion about the encoding of the public values; the current text requires confirmation from the working group that it is sufficient.¶

The -05 version of the WG draft takes into account feedback from the working group list, about the number of bytes needed to encode P-256 values.¶

The -04 version of the WG draft takes into account feedback from the May 2020 WG interim meeting, correcting the reference to the NIST P-256 specification.¶

The -03 version of the WG draft is first of all a refresh; there are no issues that we think need addressing, beyond the one for which there is a suggestion in -03: The specification now suggests an alternate group/curve as an optional one besides X25519. The specific choice of particular groups and algorithms is still up to the working group.¶

The -02 version of the WG draft took into account additional reviews, and changed the document to update RFC 5448 (or rather, its successor, [RFC9048]), changed the wording of the recommendation with regards to the use of this extension, clarified the references to the definition of X25519 and Curve25519, clarified the distinction to ECDH methods that use partially static keys, and simplified the use of AKA and SIM card terminology. Some editorial changes were also made.¶

The -00 and -01 versions of the WG draft made no major changes, only updates to some references.¶

The -05 version is merely a refresh while the draft was waiting for WG adoption.¶

The -04 version of this draft made only editorial changes.¶

The -03 version of this draft changed the naming of various protocol components, values, and notation to match with the use of ECDH in ephemeral mode. The AT_KDF_FS negotiation process was clarified in that exactly one key is ever sent in AT_KDF_ECDHE. The option of checking for zero key values IN ECDHE was added. The format of the actual key in AT_PUB_ECDHE was specified. Denial-of-service considerations for the FS process have been updated. Bidding down attacks against this extension itself are discussed extensively. This version also addressed comments from reviewers, including the August review from Mohit Sethi, and comments made during IETF-102 discussion.¶

Acknowledgments

The authors would like to note that the technical solution in this document came out of the TrustCom paper [TrustCom2015], whose authors were J. Arkko, K. Norrman, M. Näslund, and B. Sahlin. This document uses also a lot of material from [RFC4187] by J. Arkko and H. Haverinen as well as [RFC5448] by J. Arkko, V. Lehtovirta, and P. Eronen.¶

The authors would also like to thank Ben Campbell, Tim Evans, Zhang Fu, Russ Housley, Tero Kivinen, Eliot Lear, Vesa Lehtovirta, Kathleen Moriarty, Prajwol Kumar Nakarmi, Anand R. Prasad, Michael Richardson, Göran Rune, Bengt Sahlin, Joseph Salowey, Mohit Sethi, Rene Struik, Sean Turner, Helena Vahidi Mazinani, and many other people at the IETF, GSMA and 3GPP groups for interesting discussions in this problem space.¶