RFC 9678

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

📅 published March 2025, from ietf

RFC 9678 💖 Forward Secrecy Extension to EAP-AKA' (EAP-AKA' FS) 🦋

Okay bestie, let's get into it! ✨ This RFC is by J. Arkko, K. Norrman, and J. Preuß Mattsson, all from Ericsson 💅. It's a Standards Track document (so it's an actual official spec, not just vibes 👑), published March 2025, and it's ISSN 2070-1721 🌈. It updates RFC 9048 and RFC 5448 🎀, which means it adds a new optional extension on top of those two existing EAP-AKA' documents rather than replacing them. It doesn't obsolete anything. 🫶

Here's the whole pitch: the big idea is Forward Secrecy, which is basically the "even if someone steals your key later, they can't read the stuff you already sent" energy 🔐✨. This extension gives EAP-AKA' that protection. Bonus: it also makes passive surveillance way less useful for future sessions, so attackers have to go active instead, and active attacks are way harder to pull off quietly 🕵️‍♀️💀.

Title block vibes: Standards Track, March 2025, updates 9048 + 5448, Ericsson crew. 🌸

Status of This Memo 📝

This is an Internet Standards Track document 🔥. It's a product of the IETF and represents the community consensus, and it got public review and IESG approval 💜. If you want more on how Internet Standards work, check Section 2 of RFC 7841 🧚. Errata and feedback live at https://www.rfc-editor.org/info/rfc9678 🍓.

Copyright (c) 2025 IETF Trust and the document authors, all rights reserved 💅. The usual BCP 78 and IETF Trust Legal Provisions apply, so read those if you're wondering about your rights 📜. If you pull code components out of this doc, they need the Revised BSD License text from Section 4.e of the Trust Legal Provisions and come with no warranty 🫶.

Table of Contents 🗺️

1.  Introduction
2.  Requirements Language
3.  Protocol Design and Deployment Objectives
4.  Background
  4.1.  AKA
  4.2.  EAP-AKA' Protocol
  4.3.  Attacks Against Long-Term Keys in Smart Cards
5.  Protocol Overview
6.  Extensions to EAP-AKA'
  6.1.  AT_PUB_ECDHE
  6.2.  AT_KDF_FS
  6.3.  Forward Secrecy Key Derivation Functions
  6.4.  ECDHE Groups
  6.5.  Message Processing
    6.5.1.  EAP-Request/AKA'-Identity
    6.5.2.  EAP-Response/AKA'-Identity
    6.5.3.  EAP-Request/AKA'-Challenge
    6.5.4.  EAP-Response/AKA'-Challenge
    6.5.5.  EAP-Request/AKA'-Reauthentication
    6.5.6.  EAP-Response/AKA'-Reauthentication
    6.5.7.  EAP-Response/AKA'-Synchronization-Failure
    6.5.8.  EAP-Response/AKA'-Authentication-Reject
    6.5.9.  EAP-Response/AKA'-Client-Error
    6.5.10. EAP-Request/AKA'-Notification
    6.5.11. EAP-Response/AKA'-Notification
7.  Security Considerations
  7.1.  Deployment Considerations
  7.2.  Security Properties
  7.3.  Denial of Service
  7.4.  Identity Privacy
  7.5.  Unprotected Data and Privacy
  7.6.  Forward Secrecy within AT_ENCR
  7.7.  Post-Quantum Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🌟

Okay so the revelations about pervasive surveillance brought up a LOT of attacks 😭. Some of them went after the USIM card supply chain, which is the stuff inside your SIM 📱. The AKA long-term key can get exposed in a few places:

  • during manufacturing of USIM cards 🏭,
  • during the transfer of cards and their info to the operator 🚚, and
  • while the system is running 🏃‍♀️.

After those reports came out (see [Heist2015]), manufacturing and provisioning got a LOT more scrutiny and honestly they've gotten better 🙌. But the long-term keys are still juicy high-value targets, so resourceful attackers are still a real concern 👀. The thing is, the attacks don't really depend on which auth tech you use. The problem isn't broken algorithms or protocols, it's somebody getting access to key material they shouldn't have 🔑. The IETF also wants to take surveillance concerns seriously and respond to them, as laid out in [RFC7258] 💜.

Strong protection of manufacturing and other processes is essential, obviously 🛡️. But protocol mechanisms can help too, and that's the whole point here 💅.

This document updates [RFC9048], "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", by adding an optional extension that gives you ephemeral key exchange 🦋. That means the impact of a long-term key compromise gets minimized, and identity privacy gets stronger too 🙈. Since so many people use AKA in mobile networks, this matters a ton ✨.

When it's negotiated, the extension gives you Forward Secrecy (FS) [DOW1992] for the session key made during the EAP-AKA' authentication run 🔐. So an attacker who gets the long-term key from a USIM card still can't get past session keys 🙅‍♀️. The Diffie-Hellman exchange in the extension also means that if an attacker wants future session keys, they have to be active, even if they already have the long-term key 💀. And active attacks are way more expensive to run and way easier to catch 🚨. Of course, an active attacker with the long-term key can still attack future communications, but they risk getting detected, especially if they try it at scale 👀.

Also, 5G network architecture [TS.33.501] uses the EAP framework for authentication 📶. You can run any method you want, but the default in that context is EAP-AKA' 👑. So making EAP-AKA' more secure can help a whole lot of people 🫶.

2. 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. 💖

3. Protocol Design and Deployment Objectives 🎯

Here's the design tea ☕. The extension reuses a big chunk of the existing 3GPP interface and function structure, because that makes it way easier for people to actually adopt 🙌. Specifically, the USIM-to-mobile-terminal interface stays exactly the same. So you don't need to roll out new credentials to existing subscribers 🎉. The work builds on an earlier paper (see [TrustCom2015]) and reuses much of the same material, but it's applied to EAP instead of the underlying AKA method 🧠.

The goal was to make this an extension of the widely supported EAP-AKA' method instead of a whole new auth method 💅. The extension is a set of new, optional attributes sent alongside the base EAP-AKA' attributes ✨. Old implementations can just ignore them, BUT their presence still gets checked as part of the base EAP-AKA' integrity verification, which helps protect against bidding down attacks 🛡️. And the extension doesn't add any extra rounds to the protocol, so it's not slower 🏎️💨.

Using the extension is up to the authenticating parties 🤝. FS and defenses against passive attacks don't solve everything, but they're a partial defense that raises the cost and risk of pervasive surveillance 📈.

Adding FS to existing mobile network infrastructure can be done in lots of ways, but this document picks a solution that's pretty easy to deploy 🍓. Specifically:

  • No new credentials are needed, since there's no change to USIM cards 💳.
  • The FS property can go into any current or future system that supports EAP, without changing any network functions beyond the EAP endpoints 🌐.
  • Key generation happens at the endpoints, so the highest grade key material can be used by the endpoints and by intermediate systems (like access points that get access to specific keys) 🔑.
  • EAP-AKA' is just one EAP method, but FS is available for both EAP-TLS [RFC5216] [RFC9190] and EAP-AKA'. For a lot of real systems, that means FS can be turned on for all or a big chunk of users 🎀.

4. Background 📚

The reader is assumed to have a basic understanding of the EAP framework [RFC3748] 🧚‍♀️.

Part 1 of 7 done! 🌈 More parts coming, so stay tuned bestie 💜

4.1. AKA

We use the term "Authentication and Key Agreement" (or "AKA") for the main authentication and key agreement protocol used by 3GPP mobile networks from the third generation (3G) and onward. Later generations add new features to AKA, but the core remains the same. It is based on challenge-response mechanisms and symmetric cryptography. In contrast to its earlier GSM counterparts, AKA provides long key lengths and mutual authentication. The phone typically executes AKA in a USIM. A USIM is technically just an application that can reside on a removable Universal Integrated Circuit Card (UICC), an embedded UICC, or integrated in a Trusted Execution Environment (TEE). In this document, we use the term "USIM card" to refer to any Subscriber Identity Module (SIM) capable of running AKA.

Okay so AKA is the big main authentication and key agreement protocol that 3GPP mobile networks use, starting from 3G and going up 🦋. Newer generations keep adding bits to it, but the core is literally the same, no cap ✨. It's built on challenge-response stuff and symmetric crypto, and compared to the old GSM versions it gives you long key lengths and mutual authentication 💅. The phone usually runs AKA inside a USIM. A USIM is basically just an app 📱, and it can live on a removable UICC, an embedded UICC, or inside a Trusted Execution Environment (TEE) 🧚. In this doc, when we say "USIM card," we mean any Subscriber Identity Module (SIM) that can run AKA 🎀.

The goals of AKA are to mutually authenticate the USIM and the so-called home environment, which is the authentication Server in the subscriber's home operator's network, and to establish key material between the two.

The whole point is that the USIM and the home environment authenticate each other 🫶, and they set up key material between them 🔑. The home environment is the authentication Server living in the subscriber's home operator's network, so it's giving main character energy 👑.

AKA works in the following manner:

  • The USIM and the home environment have agreed on a long-term symmetric key beforehand.
  • The actual authentication process starts by having the home environment produce an authentication vector, based on the long-term key and a sequence number. The authentication vector contains a random part RAND, an authenticator part AUTN used for authenticating the network to the USIM, an expected result part XRES, a 128-bit session key for the integrity check IK, and a 128-bit session key for the encryption CK.
  • The authentication vector is passed to the serving network, which uses it to authenticate the device.
  • The RAND and the AUTN are delivered to the USIM.
  • The USIM verifies the AUTN, again based on the long-term key and the sequence number. If this process is successful (the AUTN is valid and the sequence number used to generate the AUTN is within the correct range), the USIM produces an authentication result RES and sends it to the serving network.
  • The serving network verifies that the result from the USIM matches the expected value in the authentication vector. If it does, the USIM is considered authenticated, and the IK and CK can be used to protect further communications between the USIM and the home environment.

Here's how AKA goes down, step by step 💫:

  • First up, the USIM and the home environment already agreed on a long-term symmetric key ahead of time 🔐.
  • Next, the home environment makes an authentication vector using that long-term key and a sequence number 🌸. That vector holds a random part RAND, an authenticator part AUTN (used to authenticate the network to the USIM), an expected result part XRES, a 128-bit session key for integrity (IK), and a 128-bit session key for encryption (CK) 🎀.
  • The authentication vector gets passed along to the serving network, and the serving network uses it to authenticate the device 📡.
  • RAND and AUTN get delivered to the USIM 💌.
  • The USIM checks AUTN, again using the long-term key and the sequence number 🔍. If that works out (AUTN is valid and the sequence number is in the right range), the USIM makes an authentication result RES and sends it back to the serving network 🦋.
  • The serving network checks that the RES from the USIM matches the expected value in the authentication vector ✅. If it matches, the USIM counts as authenticated, and IK and CK can then be used to protect any further chat between the USIM and the home environment 🔥. Periodt 💅.

4.2. EAP-AKA' Protocol

When AKA is embedded into EAP, the authentication processing on the network side is moved to the home environment. The 3GPP Authentication Database (AD) generates authentication vectors. The 3GPP authentication Server takes the role of EAP Server. The USIM combined with the mobile phone takes the role of client. The difference between EAP-AKA [RFC4187] and EAP-AKA' [RFC9048] is that EAP-AKA' binds the derived keys to the name of the access network. Figure 1 describes the basic flow in the EAP-AKA' authentication process. The definition of the full protocol behavior, along with the definition of the attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in [RFC9048] and [RFC4187]. Note the use of EAP terminology from hereon. That is, the 3GPP serving network takes on the role of an EAP access network.

Okay, so when AKA gets stuffed inside EAP 🎀, the network-side auth work gets moved over to the home environment 🏠. The 3GPP Authentication Database (AD) is the one making the authentication vectors 🗂️, and the 3GPP authentication Server plays the EAP Server 👑. The USIM plus the mobile phone is the client 📱. The difference between EAP-AKA [RFC4187] and EAP-AKA' [RFC9048] is that EAP-AKA' ties the derived keys to the name of the access network 🔗. Figure 1 shows the basic flow of the EAP-AKA' process 🦋. The full protocol behavior, plus the definitions of AT_RAND, AT_AUTN, AT_MAC, and AT_RES, live in [RFC9048] and [RFC4187] 📚. From here on we're using EAP terms, so the 3GPP serving network is basically an EAP access network 💜.

    Peer                                                        Server
      |                                                            |
      |                                       EAP-Request/Identity |
      |<-----------------------------------------------------------+
      |                                                            |
      | EAP-Response/Identity                                      |
      | (Includes user's Network Access Identifier (NAI))          |
      +----------------------------------------------------------->|
      |    +-------------------------------------------------------+--+
      |    | The Server determines the network name and ensures that  |
      |    | the given access network is authorized to use the        |
      |    | claimed name.  The Server then runs the EAP-AKA'         |
      |    | algorithms generating RAND and AUTN, and derives session |
      |    | keys from CK' and IK'.  RAND and AUTN are sent as        |
      |    | AT_RAND and AT_AUTN attributes, whereas the network name |
      |    | is transported in the AT_KDF_INPUT attribute.  AT_KDF    |
      |    | signals the used key derivation function.  The session   |
      |    | keys are used to create the AT_MAC attribute.            |
      |    +-------------------------------------------------------+--+
      |                                                            |
      |                                 EAP-Request/AKA'-Challenge |
      |           (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) |
      |<-----------------------------------------------------------+
   +--+------------------------------------------------------+     |
   | The Peer determines what the network name should be,    |     |
   | based on, e.g., what access technology it is using.     |     |
   | The Peer also retrieves the network name sent by the    |     |
   | network from the AT_KDF_INPUT attribute.  The two names |     |
   | are compared for discrepancies, and if they do not      |     |
   | match, the authentication is aborted.  Otherwise, the   |     |
   | network name from the AT_KDF_INPUT attribute is used    |     |
   | in running the EAP-AKA' algorithms, verifying AUTN from |     |
   | AT_AUTN and Message Authentication Code (MAC) from the  |     |
   | AT_MAC attributes.  The Peer then generates RES.  The   |     |
   | Peer also derives session keys from CK'/IK.  The AT_RES |     |
   | and AT_MAC attributes are constructed.                  |     |
   +--+------------------------------------------------------+     |
      |                                                            |
      | EAP-Response/AKA'-Challenge                                |
      | (AT_RES, AT_MAC)                                           |
      +----------------------------------------------------------->|
      |      +-----------------------------------------------------+--+
      |      | The Server checks the RES and MAC values received in   |
      |      | AT_RES and AT_MAC, respectively.  Success requires     |
      |      | both compared values match, respectively.              |
      |      +-----------------------------------------------------+--+
      |                                                            |
      |                                                EAP-Success |
      |<-----------------------------------------------------------+
      |                                                            |

Figure 1: EAP-AKA' Authentication Process 🌈

4.3. Attacks Against Long-Term Keys in Smart Cards

The general security properties and potential vulnerabilities of AKA and EAP-AKA' are discussed in [RFC9048].

An important question in that discussion relates to the potential compromise of long-term keys, as discussed earlier. Attacks on long-term keys are not specific to AKA or EAP-AKA', and all security systems fail, at least to some extent, if key material is stolen. However, it would be preferable to retain some security even in the face of such attacks. This document specifies a mechanism that reduces the risks of compromising key material belonging to previous sessions, before the long-term keys were compromised. It also forces attackers to be active even after the compromise.

Okay this part is lowkey important 🙈. The general security stuff and the possible vulnerabilities of AKA and EAP-AKA' are covered in [RFC9048] 📖. The big question there is what happens if long-term keys get compromised, like we mentioned earlier 😭. Attacks on long-term keys aren't special to AKA or EAP-AKA', and honestly every security system falls apart to some degree if key material gets stolen 💀. Still, it'd be way better to keep some security even when that happens 🛡️. This doc specifies a mechanism that cuts down the risk of compromised key material from previous sessions, the ones that happened before the long-term keys got compromised 🔐. It also makes attackers stay active even after the compromise 🏃‍♀️✨.

5. Protocol Overview ✨

okay so bestie, forward secrecy (FS) for EAP-AKA' comes from an Elliptic Curve Diffie-Hellman (ECDH) exchange [RFC7748] 🦋 to get FS, the exchange has to be run in an ephemeral way, meaning both sides make temporary keys based on the ciphersuite they agreed on. for X25519, that's done the way [RFC7748] spells out 💅 people call this "ECDHE," and that last "E" stands for "Ephemeral" 🫶 the two elliptic curves that get registered first, plus their wire formats, were picked to line up with the curves and formats for Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP [TS.33.501]. it's giving consistency 🌸

the FS enhancements in EAP-AKA' are built to be compatible with the signaling flow and the other basic structures of both AKA and EAP-AKA'. the plan is to ship the enhancement as optional attributes that legacy implementations just ignore 🧚

the whole point of the protocol is to get mutual authentication between the EAP Server and the Peer, and to set up key material so they can talk securely 🔐 this document explains how the key material gets calculated, and that gives you properties that the original EAP-AKA' key material never had 😭✨

Figure 2 walks through the whole process 🎀 the goal was to avoid needing any new infrastructure or credentials, so the flow diagrams also show how things conceptually interact with the USIM card and the home environment. quick reminder: the home environment is the 3GPP Authentication Database (AD) and Server 💜 the details of those interactions are outside the scope of this document, though, so for those you'll want to check the 3GPP specifications (for 5G, that's specified in 3GPP [TS.33.501]) 🍓

USIM           Peer                        Server              AD
  |              |                            |                |
  |              |           EAP-Req/Identity |                |
  |              |<---------------------------+                |
  |              |                            |                |
  |              | EAP-Resp/Identity          |                |
  |              | (Privacy-Friendly)         |                |
  |              +--------------------------->|                |
  |      +-------+----------------------------+----------------+----+
  |      | The Server now has an identity for the Peer.  The Server |
  |      | then asks the help of the AD to run EAP-AKA algorithms,  |
  |      | generating RAND, AUTN, XRES, CK, and IK.  Typically, the |
  |      | AD performs the first part of derivations so that the    |
  |      | authentication Server gets the CK' and IK' keys already  |
  |      | tied to a particular network name.                       |
  |      +-------+----------------------------+----------------+----+
  |              |                            |                |
  |              |                            | ID, key deriv. |
  |              |                            | function,      |
  |              |                            | network name   |
  |              |                            +--------------->|
  |              |                            |                |
  |              |                            |    RAND, AUTN, |
  |              |                            | XRES, CK', IK' |
  |              |                            |<---------------+
  |      +-------+----------------------------+----------------+----+
  |      | The Server now has the needed authentication vector.  It |
  |      | generates an ephemeral key pair, and sends the public    |
  |      | key of that key pair and the first EAP method message to |
  |      | the Peer. In the message the AT_PUB_ECDHE attribute      |
  |      | carries the public key and the AT_KDF_FS attribute       |
  |      | carries other FS-related parameters. Both of these are   |
  |      | skippable attributes that can be ignored if the Peer     |
  |      | does not support this extension.                         |
  |      +-------+----------------------------+----------------+----+
  |              |                            |                |
  |              |     EAP-Req/AKA'-Challenge |                |
  |              |  AT_RAND, AT_AUTN, AT_KDF, |                |
  |              |   AT_KDF_FS, AT_KDF_INPUT, |                |
  |              |       AT_PUB_ECDHE, AT_MAC |                |
  |              |<---------------------------+                |
  +--+--------------+----------------------------+---------+      |
  | The Peer checks if it wants to do the FS extension.    |      |
  | If yes, it will eventually respond with AT_PUB_ECDHE   |      |
  | and AT_MAC.  If not, it will ignore AT_PUB_ECDHE and   |      |
  | AT_KDF_FS and base all calculations on basic EAP-AKA'  |      |
  | attributes, continuing just as in EAP-AKA' per RFC     |      |
  | 9048 rules.  In any case, the Peer needs to query the  |      |
  | auth parameters from the USIM card.                    |      |
  +--+--------------+----------------------------+---------+      |
  |              |                            |                |
  |   RAND, AUTN |                            |                |
  |<-------------+                            |                |
  |              |                            |                |
  | CK, IK, RES  |                            |                |
  +------------->|                            |                |
  +--+--------------+----------------------------+---------+      |
  | The Peer now has everything to respond.  If it wants   |      |
  | to participate in the FS extension, it will then       |      |
  | generate its key pair, calculate a shared key based on |      |
  | its key pair and the Server's public key.  Finally, it |      |
  | proceeds to derive all EAP-AKA' key values and         |      |
  | constructs a full response.                            |      |
  +--+--------------+----------------------------+---------+      |
  |              |                            |                |
  |              | EAP-Resp/AKA'-Challenge    |                |
  |              | AT_RES, AT_PUB_ECDHE,      |                |
  |              | AT_MAC                     |                |
  |              +--------------------------->|                |
  |      +-------+----------------------------+----------------+--+
  |      | The Server now has all the necessary values.  It       |
  |      | generates the ECDHE shared secret and checks the RES   |
  |      | and MAC values received in AT_RES and AT_MAC,          |
  |      | respectively.  Success requires both to be found       |
  |      | correct.  Note that when this document is used,        |
  |      | the keys generated from EAP-AKA' are based on CK, IK,  |
  |      | and the ECDHE value.  Even if there was an attacker    |
  |      | who held the long-term key, only an active attacker    |
  |      | could have determined the generated session keys; in   |
  |      | basic EAP-AKA' the generated keys are only based on CK |
  |      | and IK.                                                |
  |      +-------+----------------------------+----------------+--+
  |              |                            |                |
  |              |                EAP-Success |                |
  |              |<---------------------------+                |
  |              |                            |                |

Figure 2: EAP-AKA' FS Authentication Process

6. Extensions to EAP-AKA' 🌈

6.1. AT_PUB_ECDHE 💖

The AT_PUB_ECDHE attribute carries an ECDHE value 🦋

the format of the AT_PUB_ECDHE attribute is shown below 👑

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | AT_PUB_ECDHE  | Length        | Value                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

here's what each field does 🧚

AT_PUB_ECDHE: This is set to 152.

Length: This is the length of the attribute, set the same way as other attributes in EAP-AKA [RFC4187]. The length is expressed in multiples of 4 bytes. The length includes the attribute type field, the Length field itself, and the Value field (along with any padding).

Value: This value is the sender's ECDHE public key. The value depends on the AT_KDF_FS attribute and is calculated as follows:

  • For X25519, the length of this value is 32 bytes, encoded as specified in Section 5 of [RFC7748].
  • For P-256, the length of this value is 33 bytes, encoded using the compressed form specified in Section 2.3.3 of [SEC1].

Because the length of the attribute must be a multiple of 4 bytes, the sender pads the Value field with zero bytes when necessary. To retain the security of the keys, the sender SHALL generate a fresh value for each run of the protocol 🔥 no reusing the same one, bestie 🫶😭

6.2. AT_KDF_FS 💜

Okay bestie, AT_KDF_FS is the attribute that says which FS key generation function the Server (or the Peer) wants to use, when the FS extension is in play. 🦋 It also tells everyone which ECDHE group comes along for the ride. A brand new attribute is needed for this because AT_KDF already carries the basic KDF value, and that value is still used together with the FS KDF value. The basic KDF value is also what Peers that cannot or do not want this extension keep using. 🫶

This document only specifies the behavior for these combinations of basic KDF values and FS KDF values:

  • the basic KDF value in AT_KDF is 1, as specified in [RFC5448] and [RFC9048] and
  • the FS KDF values in AT_KDF_FS are 1 or 2, as specified below and in Section 6.3.

Any future specifications that add either new basic KDFs or new FS KDF values need to specify how they are treated and what combinations are allowed. ✨ This requirement is an update to how [RFC5448] and [RFC9048] may be extended in the future. Future-proofing, iykyk. 🔮

Here's the layout of the AT_KDF_FS attribute:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | AT_KDF_FS     | Length        | FS Key Derivation Function    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each field does:

  • AT_KDF_FS: This is set to 153.
  • Length: This is the length of the attribute, and it MUST be set to 1.
  • FS Key Derivation Function: This is an enumerated value representing the FS Key Derivation Function (KDF) that the Server (or Peer) wishes to use. See Section 6.3 for the functions specified in this document. Note: this field has a different name space than the similar field in the AT_KDF attribute KDF defined in [RFC9048].

Servers MUST send one or more AT_KDF_FS attributes in the EAP-Request/AKA'-Challenge message. ✨ These attributes represent the desired functions, ordered by preference, with the most preferred function being the first attribute. The most preferred function is the only one the Server includes a public key value for, however. So, for a set of AT_KDF_FS attributes, there is always only one AT_PUB_ECDHE attribute. 💖

Upon receiving a set of these attributes:

  • If the Peer supports and is willing to use the FS KDF indicated by the first AT_KDF_FS attribute, and is willing and able to use the extension defined in this document, the function will be used without any further negotiation. Easy breezy. 🌸
  • If the Peer does not support this function or is unwilling to use it, it responds to the Server with an indication that a different function is needed. Similarly, with the negotiation process defined in [RFC9048] for AT_KDF, the Peer sends an EAP-Response/AKA'-Challenge message that contains only one attribute, AT_KDF_FS, with the value set to the desired alternative function from among the ones suggested by the Server earlier. If there is no suitable alternative, the Peer has a choice of either falling back to EAP-AKA' or behaving as if the AUTN had been incorrect and failing authentication (see Figure 3 of [RFC4187]). The Peer MUST fail the authentication if there are any duplicate values within the list of AT_KDF_FS attributes (except where the duplication is due to a request to change the KDF; see below for further information). 🙈
  • If the Peer does not recognize the extension defined in this document or is unwilling to use it, it ignores the AT_KDF_FS attribute. 🦋

Upon receiving an EAP-Response/AKA'-Challenge message with an AT_KDF_FS attribute from the Peer, the Server checks that the suggested AT_KDF_FS value was one of the alternatives in its offer. The first AT_KDF_FS value in the message from the Server is not a valid alternative. If the Peer has replied with the first AT_KDF_FS value, the Server behaves as if the AT_MAC of the response had been incorrect and fails the authentication. For an overview of the failed authentication process on the Server side, see Section 3 and Figure 2 in [RFC4187]. Otherwise, the Server re-sends the EAP-Response/AKA'-Challenge message, but adds the selected alternative to the beginning of the list of AT_KDF_FS attributes and retains the entire list following it. Note that this means the selected alternative appears twice in the set of AT_KDF values. Responding to the Peer's request to change the FS KDF is the only valid situation where such duplication may occur. 🎀

When the Peer receives the new EAP-Request/AKA'-Challenge message, it MUST check that the requested change, and only the requested change, occurred in the list of AT_KDF_FS attributes. If so, it continues. If not, it behaves as if AT_MAC were incorrect and fails the authentication. If the Peer receives multiple EAP-Request/AKA'-Challenge messages with differing AT_KDF_FS attributes without having requested negotiation, the Peer MUST behave as if AT_MAC were incorrect and fail the authentication. 💀

6.3. Forward Secrecy Key Derivation Functions 🔥

Two new FS KDF types are defined: "EAP-AKA' with ECDHE and X25519", represented by value 1, and "EAP-AKA' with ECDHE and P-256", represented by value 2. 👑 These values represent a particular choice of KDF and, at the same time, select the ECDHE group to be used. Two for one, the ultimate glow-up. ✨

The FS KDF type value is only used in the AT_KDF_FS attribute. When the FS extension is used, the AT_KDF_FS attribute determines how to derive the MK_ECDHE key, the K_re key, the Master Session Key (MSK), and the Extended Master Session Key (EMSK). The AT_KDF_FS attribute should not be confused with the different range of KDFs that can be represented in the AT_KDF attribute as defined in [RFC9048]. When the FS extension is used, the AT_KDF attribute only specifies how to derive the Master Key (MK), the K_encr key, and the K_aut key. Don't mix these two up, bestie. 🙃

Key derivation in this extension produces exactly the same keys for internal use within one authentication run as EAP-AKA' [RFC9048] does. For instance, the K_aut that is used in AT_MAC is still exactly as it was in EAP-AKA'. The only change to key derivation is in the re-authentication keys and the keys exported out of the EAP method, MSK and EMSK. As a result, EAP-AKA' attributes such as AT_MAC keep working even when this extension is in use. 🫶

When the FS KDF field in the AT_KDF_FS attribute is set to 1 or 2 and the KDF field in the AT_KDF attribute is set to 1, the MK and accompanying keys are derived as follows:

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]

Here's the decoder ring for the notation above:

  • [n..m] denotes the substring from bit n to m.
  • PRF' is a new pseudorandom function specified in [RFC9048].
  • K_encr is the encryption key (128 bits).
  • K_aut is the authentication key (256 bits).
  • K_re is the re-authentication key (256 bits).
  • MSK is the Master Session Key (512 bits).
  • EMSK is the Extended Master Session Key (512 bits).

Note: MSK and EMSK are outputs from a successful EAP method run [RFC3748].

The CK and IK are produced by the AKA algorithm. The IK' and CK' are derived from the IK and CK as specified in [RFC9048]. 🌈

The value "EAP-AKA'" is an ASCII string that is 8 characters long. It is used as is, without any trailing NUL characters. Similarly, "EAP-AKA' FS" is an ASCII string that is 11 characters long, also used as is. 🍓

Requirements for how to securely generate, validate, and process the ephemeral public keys depend on the elliptic curve. Curve-specific rules, let's gooo. 🧚

For P-256, the SHARED_SECRET is the shared secret computed as specified in Section 5.7.1.2 of [SP-800-56A]. Requirements are defined in Section 5 of [SP-800-56A], in particular Sections 5.6.2.3.4, 5.6.3.1, and 5.6.3.3. At least partial public key validation MUST be done for the ephemeral public keys. The uncompressed y-coordinate can be computed as described in Section 2.3.4 of [SEC1]. 🔐

For X25519, the SHARED_SECRET is the shared secret computed as specified in Section 6.1 of [RFC7748]. Both the Peer and the Server MAY check for the zero-value shared secret as specified in Section 6.1 of [RFC7748].

Note: If performed inappropriately, the way that the shared secret is tested for zero can provide an ability for attackers to listen to CPU power usage side channels. Refer to [RFC7748] for a description of how to perform this check in a way that it does not become a problem. 😭

If validation of the other party's ephemeral public key or the shared secret fails, a party MUST behave as if the current EAP-AKA' process starts again from the beginning. 🔁

The rest of the computation proceeds as defined in Section 3.3 of [RFC9048].

6.4. ECDHE Groups 🌸

Picking a suitable group for the elliptic curve computation is necessary. The choice of group is made at the same time as the decision to use a particular KDF in the AT_KDF_FS attribute. Bundle deal, bestie. 💅

For "EAP-AKA' with ECDHE and X25519", the group is the Curve25519 group specified in [RFC7748]. The support for this group is REQUIRED. ⭐

For "EAP-AKA' with ECDHE and P-256", the group is the NIST P-256 group (SEC group secp256r1), specified in Section 3.2.1.3 of [SP-800-186] or alternatively, Section 2.4.2 of [SEC2]. The support for this group is REQUIRED. 🌈

The term "support" here means that the group MUST be implemented. 🫶

6.5. Message Processing 🦋

This section covers the changes to message processing when this extension is used in EAP-AKA'. It specifies when a message may be transmitted or accepted, which attributes are allowed in a message, which attributes are required in a message, and other message-specific details, where those details differ for this extension from the base EAP-AKA' or EAP-AKA protocol. Unless otherwise specified here, the rules from [RFC9048] or [RFC4187] apply. Think of this section as the fine print that makes everything click. 📝

6.5.1. EAP-Request/AKA'-Identity

There are no changes for the EAP-Request/AKA'-Identity, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these attributes in a received message MUST be ignored. 🙈

6.5.2. EAP-Response/AKA'-Identity

There are no changes for the EAP-Response/AKA'-Identity, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these attributes in a received message MUST be ignored. The Peer identifier SHALL comply with the privacy-friendly requirements of [RFC9190]. An example of a compliant way of constructing a privacy-friendly Peer identifier is using a non-null SUCI [TS.33.501]. Privacy protection, obsessed. 🔒💜

6.5.3. EAP-Request/AKA'-Challenge ✨

Okay so the Server sends the EAP-Request/AKA'-Challenge for a full authentication, following [RFC4187] and [RFC9048] 💅. The attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked on reception as specified in [RFC4187] 🔥. They're also needed for backwards compatibility, so no skipping them, bestie 🫶.

In the EAP-Request/AKA'-Challenge, there is no message-specific data covered by the MAC for the AT_MAC attribute 🧚. The AT_KDF_FS and AT_PUB_ECDHE attributes MUST be included 💖. The AT_PUB_ECDHE attribute carries the Server's public Diffie-Hellman key 🦋. If either AT_KDF_FS or AT_PUB_ECDHE is missing on reception, the Peer MUST treat it as if neither one was sent and assume that the extension defined in this document is not in use 😭. Like, it's all or nothing, periodt 💀.

The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING, AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID, and other attributes may be included as specified in Section 9.3 of [RFC4187] 🌸.

When processing this message, the Peer MUST process AT_RAND, AT_AUTN, AT_KDF_FS, and AT_PUB_ECDHE before processing other attributes 👑. The Peer derives keys and verifies AT_MAC only if these attributes are verified to be valid ✨. If the Peer is unable or unwilling to perform the extension specified in this document, it proceeds as defined in [RFC9048] 🌈. Finally, if there is an error, see Section 6.3.1 of [RFC4187] 🎀.

6.5.4. EAP-Response/AKA'-Challenge ✨

The Peer sends an EAP-Response/AKA'-Challenge in response to a valid EAP-Request/AKA'-Challenge message, as specified by [RFC4187] and [RFC9048] 🦋. If the Peer supports and is willing to perform the extension specified in this protocol, and the Server had made a valid request involving the attributes specified in Section 6.5.3, the Peer responds per the rules specified below 💅. Otherwise, the Peer responds as specified in [RFC4187] and [RFC9048] and ignores the attributes related to this extension 🙈. If the Peer has not received attributes related to this extension from the Server, and has a policy that requires it to always use this extension, it behaves as if the AUTN were incorrect and fails the authentication 💀. Not me reading that policy line and going "oof" 😭.

The AT_MAC attribute MUST be included and checked as specified in [RFC9048] 🔥. In the EAP-Response/AKA'-Challenge, there is no message-specific data covered by the MAC 🧚. The AT_PUB_ECDHE attribute MUST be included and carries the Peer's public Diffie-Hellman key 💖.

The AT_RES attribute MUST be included and checked as specified in [RFC4187] 🫶. When processing this message, the Server MUST process AT_RES before processing other attributes 👑. The Server derives keys and verifies AT_MAC only when this attribute is verified to be valid 🌸.

If the Server has proposed the use of the extension specified in this protocol, but the Peer ignores and continues the basic EAP-AKA' authentication, the Server makes a policy decision of whether this is allowed 🤔. If this is allowed, it continues the EAP-AKA' authentication to completion ✨. If it is not allowed, the Server MUST behave as if authentication failed 😭.

The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA, and other attributes may be included as specified in Section 9.4 of [RFC4187] 🦋.

6.5.5. EAP-Request/AKA'-Reauthentication ✨

There are no changes for the EAP-Request/AKA'-Reauthentication, but note that the re-authentication process uses the keys generated in the original EAP-AKA' authentication, which employs key material from the Diffie-Hellman procedure if the extension specified in this document is in use 🔥.

6.5.6. EAP-Response/AKA'-Reauthentication ✨

There are no changes for the EAP-Response/AKA'-Reauthentication, but as discussed in Section 6.5.5, re-authentication is based on the key material generated by EAP-AKA' and the extension defined in this document 💅.

6.5.7. EAP-Response/AKA'-Synchronization-Failure ✨

There are no changes for the EAP-Response/AKA'-Synchronization-Failure, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message 🙅. The appearance of these attributes in a received message MUST be ignored 🫠.

6.5.8. EAP-Response/AKA'-Authentication-Reject ✨

There are no changes for the EAP-Response/AKA'-Authentication-Reject, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message 🙅. The appearance of these attributes in a received message MUST be ignored 🫠.

6.5.9. EAP-Response/AKA'-Client-Error ✨

There are no changes for the EAP-Response/AKA'-Client-Error, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message 🙅. The appearance of these attributes in a received message MUST be ignored 🫠.

6.5.10. EAP-Request/AKA'-Notification ✨

There are no changes for the EAP-Request/AKA'-Notification 🌈.

6.5.11. EAP-Response/AKA'-Notification ✨

There are no changes for the EAP-Response/AKA'-Notification 🌈.

7. Security Considerations 💀

This section deals only with changes to security considerations for EAP-AKA' or new information that has been gathered since the publication of [RFC9048] 🔥. Lowkey the most important part of the whole doc, so read it slow 🫶.

As discussed in Section 1, FS is an important countermeasure against adversaries who gain access to long-term keys 🔐. The long-term keys can be best protected with good processes, e.g., restricting access to the key material within a factory or among personnel, etc. ✨ Even so, not all attacks can be entirely ruled out 😭. For instance, well-resourced adversaries may be able to coerce insiders to collaborate, despite any technical protection measures 💀. The zero trust principles suggest that we assume that breaches are inevitable or have potentially already occurred and that we need to minimize the impact of these breaches (see [NSA-ZT] and [NIST-ZT]) 🛡️. One type of breach is key compromise or key exfiltration 🙈.

If a mechanism without ephemeral key exchange (such as 5G-AKA or EAP-AKA') is used, the effects of key compromise are devastating 💀. There are serious consequences to not properly providing FS for the key establishment, for the control plane and the user plane, and for both directions:

  1. An attacker can decrypt 5G communication that they previously recorded 😱.
  2. A passive attacker can eavesdrop (decrypt) all future 5G communication 👀.
  3. An active attacker can impersonate the User Equipment (UE) or the network and inject messages in an ongoing 5G connection between the real UE and the real network 🚨.

At the time of writing, best practice security is to mandate FS (as is done in Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS 1.3, Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell (SSH), QUIC, WireGuard, Signal, etc.) 🔐. In deployments, it is recommended that EAP-AKA methods without FS be phased out in the long term 🌅.

The FS extension provides assistance against passive attacks from attackers that have compromised the key material on USIM cards 💳. Passive attacks are attractive for attackers performing large-scale pervasive monitoring as they require far fewer resources and are much harder to detect 👁️. The extension also provides protection against active attacks as the attacker is forced to be on-path during the AKA run and subsequent communication between the parties 🕸️. Without FS, an active attacker that has compromised the long-term key can inject messages in a connection between the real Peer and the real Server without being on-path 😤. This extension is most useful when implemented in a context where the MSK or EMSK are used in protocols not providing FS 🎯. For instance, if used with IKEv2 [RFC7296], the session keys produced by IKEv2 will in any case have this property, so the improvements from the use of EAP-AKA' FS are not that useful 🤷‍♀️. However, typical link-layer usage of EAP does not involve running another key exchange with forward secrecy 🙃. Therefore, using EAP to authenticate access to a network is one situation where the extension defined in this document can be helpful 💖.

The FS extension generates key 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 destroyed 🧨. 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 🌟.

The extension does not provide protection against active attackers that mount an on-path attack on future EAP-AKA' runs and have access to the long-term key 😬. They will be able to eavesdrop on the traffic protected by the resulting session key(s) 👂. Still, past sessions where FS was in use remain protected 🛡️.

Using EAP-AKA' FS once provides FS 💅. FS 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], FS 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) 🔄.

7.1. Deployment Considerations 🎀

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

Similarly, other parts of the system matter 🧩. For instance, when the keys generated by EAP are transported to a pass-through authenticator, such transport must also provide forward secure encryption with respect to the long-term keys used to establish its security 🔒. Otherwise, an adversary may attack the transport connection used to carry keys from EAP, and use this method to gain access to current and past keys from EAP, which, in turn, would lead to the compromise of anything protected by those EAP keys 😱.

Of course, these considerations apply to any EAP method, not only this one 💜.

7.2. Security Properties 🎀

okay so these are the security properties of EAP-AKA' that this extension changes. 🔐✨

Protected ciphersuite negotiation 💅

EAP-AKA' already has a negotiation mechanism for picking the KDFs, and this extension upgrades it. The upgraded version is still secure against bidding-down attacks. 🙅‍♀️ There are two specific needs in this mechanism:

Negotiating KDFs within the extension 🧩 The mechanism lets the offered KDF change, but that change shows up in the final EAP-Req/AKA'-Challenge message the Server sends to the Peer. That message is authenticated with AT_MAC, and it carries both the chosen option and the original offered list. The Peer refuses to accept a change it didn't start itself. So both parties know a change is happening, and they both know what the original offer was. Iconic transparency 👑

Negotiating the use of this extension 🦋 The Server offers this extension by including AT_KDF_FS and AT_PUB_ECDHE in the EAP-Request/AKA'-Challenge message. Both attributes are protected by AT_MAC, so if an adversary tries to change or drop them, it gets caught. 🚨

The one exception is if the adversary holds the long-term key and is willing to run an active attack. Then they could forge the negotiation so that no FS is provided. Ngl, that's the scary part, but an attacker with those powers could already impersonate anyone and do on-path attacks, and no technical fix can solve that. 😭 Even so, as the Introduction explains, an attacker with the long-term keys still has to be on-path for every AKA run and all the communication after it. That makes mass surveillance a lot more of a hassle. 🙈

The security of the extension also depends on a policy choice. As discussed in Section 6.5.4, when the Peer and the Server are both willing to do this extension but the other side doesn't want to use it, each side decides what to do. Allowing that fallback is nice for backwards compatibility with equipment that doesn't support the extension yet. 🍓 If the extension is not supported or not negotiated, then obviously no FS can be provided.

Now if turning off this extension isn't allowed by policy, then legacy equipment that doesn't support this protocol can't be used anymore. That might be the right move when support is super widespread, or when a particular version of a mobile network requires it. 📱👑

Key derivation 🔑

This extension provides FS. Summed up roughly (it's described in a bunch of places in this spec): an attacker who has the long-term keys still can't get the session keys of ended past sessions, as long as those sessions deleted all the relevant session key material. ✨ This extension doesn't change the properties related to re-authentication. No new Diffie-Hellman run happens during the re-authentication that EAP-AKA' allows. 🙌 However, if this extension was being used when the original EAP-AKA' authentication happened, then the keys used for re-authentication (K_re) are based on the Diffie-Hellman keys. So they're just as safe against exposure of the long-term key as the original authentication was. 💜

7.3. Denial of Service 🛡️

We have to talk about Denial-of-Service (DoS) attacks and how they affect this protocol, bestie. 🥺 The math in public key cryptography takes computing power, and an attacker could use that to overwhelm either the Peer or the Server. Some forms of DoS are always possible. Still, these factors help reduce the risk for public key cryptography and EAP-AKA' FS:

  • In a 5G context, other parts of the connection setup already use public key cryptography. So doing extra operations in EAP-AKA' is an additional concern, but it doesn't change the overall situation. That means the relevant system components need to be sized properly, and detection and management mechanisms need to be in place to reduce the effect of attacks. 📶
  • This specification is built so the USIM and the Peer can be separated on the client side, and the Server and AD can be separated on the network side. This makes sure the most sensitive (or legacy) system components can't be the target of an attack. For example, EAP-AKA' and public key cryptography both run on the phone, not on the low-power USIM card. 📱🔋
  • EAP-AKA' is designed so the first real message in the authentication process comes from the Server. That message won't be sent unless the user has been identified as an active subscriber of that operator. The initial identity can be spoofed before authentication succeeds, but that makes an attack less efficient. 🧚
  • Last but not least, this memo specifies an order in which computations and checks must occur. For example, when processing the EAP-Request/AKA'-Challenge message, the AKA authentication must be checked and succeed before the Peer goes on to calculate or process the FS-related parameters (see Section 6.5.4). The same goes for an EAP-Response/AKA'-Challenge (see Section 6.5.4). This way, the parties have to prove they hold the long-term key in some way, and only then do the FS calculations get switched on. That limits DoS to specific, identified subscribers. 🎯 Botnets and other malicious parties could still abuse real subscribers and their key material, but those attacks are at least:
    • a. limited in terms of the subscribers they control, and
    • b. identifiable, so the affected subscribers can be blocked. 🚫

7.4. Identity Privacy 🙈

As Section 6.5 specifies, the Peer identity sent in the Identity Response message needs to follow the privacy-friendly requirements in [RFC9190]. Privacy is a whole vibe, so this one matters. 💖

7.5. Unprotected Data and Privacy 🕵️‍♀️

Unprotected data and metadata can reveal sensitive information, so you have to choose what goes in there very carefully. 🫶 This especially applies to AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE reveal which cryptographic algorithms are being used. If those depend on the Peer identity, they leak info about the Peer. 😬 AT_KDF_INPUT reveals the network name, although that's done on purpose to bind the authentication to a particular context. 🎀

An attacker watching network traffic can use these kinds of info for traffic flow analysis or to track an endpoint. Yikes. 👀

7.6. Forward Secrecy within AT_ENCR 🔐

The keys K_encr and K_aut get calculated and used before the shared secret from the ephemeral key exchange is available. 🧠

K_encr and K_aut are used to encrypt and compute a MAC in the EAP-Req/AKA'-Challenge message, especially the DH g^x ephemeral public key. At that point, the Server doesn't have the matching g^y from the Peer yet, so it can't compute the shared secret. Then K_aut is used as the authentication key for the shared secret. 🔑

Here's the catch, though. For K_encr, none of the encrypted data sent in the EAP-Req/AKA'-Challenge message in the AT_ENCR attribute gets forward secrecy. That data may include re-authentication pseudonyms. So an adversary who compromises the long-term key could link re-authentication protocol runs when pseudonyms are used, within a sequence of runs that follows a full EAP-AKA' authentication. 😭 There would be no linking across different full authentication runs. If that pseudonym linkage risk isn't acceptable, one way to avoid it is to always require full EAP-AKA' authentication. 💅

7.7. Post-Quantum Considerations 🌈

As of publishing this document, it's unclear when, or even if, a quantum computer big and powerful enough to break ECC will exist. ⏳ Deployments that need to plan decades into the future should move to Post-Quantum Cryptography (PQC) in the not-too-distant future. Other systems may use PQC once the quantum threat is more imminent. 🔮 Current PQC algorithms have limitations compared to ECC, and their data sizes could be a problem for some constrained systems. If a Cryptographically Relevant Quantum Computer (CRQC) gets built, it could recover the SHARED_SECRET from the ECDHE public keys. Scary stuff 💀

Still, this would not affect EAP-AKA''s ability to authenticate properly, with or without this extension. Symmetric key cryptography stays safe even if CRQCs are built, so an adversary still won't be able to disrupt authentication, because that requires computing a correct AT_MAC value. That computation needs the K_aut key, which is based on MK, CK', and IK', but not on SHARED_SECRET. 🙌

The other output keys do include SHARED_SECRET via MK_ECDHE. But they still include CK' and IK', which are based entirely on symmetric cryptography. So an adversary with a quantum computer still can't compute the other output keys either. 🎉

However, if the adversary also knows the long-term key, they could then compute CK', IK', SHARED_SECRET, and any derived output keys. That means a powerful enough quantum computer would take away this protocol extension's ability to provide forward secrecy. It would make it necessary to update the current ECC algorithms in this document to PQC algorithms. This document doesn't add such algorithms, but a future update can. 🛠️

Symmetric algorithms used in EAP-AKA' FS, like HMAC-SHA-256 and the algorithms used to generate AT_AUTN and AT_RES, are practically secure even against large, robust quantum computers. 💪 EAP-AKA' FS is currently only specified for use with ECDHE key exchange algorithms, but using any Key Encapsulation Method (KEM), including PQC KEMs, can be specified in the future. The key exchange is described in Diffie-Hellman terms, but it follows a KEM interface. So AT_PUB_ECDHE would then contain either the Server's ephemeral public key or the SHARED_SECRET encapsulated with the Server's public key. 🦋 Note that using a KEM might require other changes too, like including the Server's ephemeral public key in the key derivation. That keeps the property that both parties contribute randomness to the session key. 🫶

8. IANA Considerations ✨

okay bestie, so this extension of EAP-AKA' shares its attribute space and subtypes with three other protocols, and they're giving family reunion 🦋

  • "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)" [RFC4186],
  • "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)" [RFC4187], and
  • "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')" [RFC9048].

IANA got two new values in the "Attribute Types (Skippable Attributes 128-255)" registry, under the "EAP-AKA and EAP-SIM Parameters" group. Iconic 💅

  • 152: AT_PUB_ECDHE (Section 6.1)
  • 153: AT_KDF_FS (Section 6.2)

IANA also made a brand new registry, "EAP-AKA' AT_KDF_FS Key Derivation Function Values", to hold the FS KDF types 🔥 The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA' with ECDHE and P-256" types got values 1 and 2 (see Section 6.3), and one value is reserved. Here's how the starting contents look in Table 1. New values can be added through the Specification Required policy [RFC8126]. Expert reviewers should make sure the referenced specification is clearly identified and stable, and that the new addition actually makes sense for that category of allocation 🧐

      +=========+================================+===========+
      | Value   | Description                    | Reference |
      +=========+================================+===========+
      | 0       | Reserved                       | RFC 9678  |
      +---------+--------------------------------+-----------+
      | 1       | EAP-AKA' with ECDHE and X25519 | RFC 9678  |
      +---------+--------------------------------+-----------+
      | 2       | EAP-AKA' with ECDHE and P-256  | RFC 9678  |
      +---------+--------------------------------+-----------+
      | 3-65535 | Unassigned                     | RFC 9678  |
      +---------+--------------------------------+-----------+

        Table 1: EAP-AKA' AT_KDF_FS Key Derivation Function
                  Values Registry Initial Contents

9. References 📚

the reading list, bestie. I've kept every entry word for word so nothing gets lost in translation 🫶

9.1. Normative References

9.2. Informative References

Acknowledgments 🫶

the authors wanted to give a shoutout 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 also uses 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, Meiling Chen, Roman Danyliw, Linda Dunbar, Tim Evans, Zhang Fu, Russ Housley, Tero Kivinen, Murray Kucherawy, Warren Kumari, Eliot Lear, Vesa Lehtovirta, Kathleen Moriarty, Prajwol Kumar Nakarmi, Francesca Palombini, Anand R. Prasad, Michael Richardson, Göran Rune, Bengt Sahlin, Joseph Salowey, Mohit Sethi, Orie Steele, Rene Struik, Vesa Torvinen, Sean Turner, Helena Vahidi Mazinani, Robert Wilton, Paul Wouters, Bo Wu, Peter Yee, and many other people at the IETF, GSMA, and 3GPP groups for interesting discussions in this problem space. the whole squad slayed 🌈👑

Authors' Addresses 💌

Jari Arkko Ericsson FI-02420 Jorvas Finland Email: jari.arkko@piuha.net

Karl Norrman Ericsson SE-16483 Stockholm Sweden Email: karl.norrman@ericsson.com

John Preuß Mattsson Ericsson SE-164 40 Kista Sweden Email: john.mattsson@ericsson.com

📦 where this page comes from