Forward Secure Reauthentication in the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA')
draft-wang-emu-fs-reauth-01

EAP Method Update                                           G. Wang, Ed.
Internet-Draft                                                    Z. Lei
Intended status: Standards Track                     Huawei Int. Pte Ltd
Expires: 7 January 2027                                      6 July 2026

    Forward Secure Reauthentication in the Extensible Authentication
    Protocol Method for Authentication and Key Agreement (EAP-AKA')
                      draft-wang-emu-fs-reauth-01

Abstract

   This draft specifies an update to RFC 9678, "Forward Secrecy
   Extension to the Improved Extensible Authentication Protocol Method
   for Authentication and Key Agreement (EAP-AKA' FS)", and its
   predecessors RFC 9048, RFC 5448, and RFC 4187.  This update enables
   forward security of the Transient EAP Keys (TEKs) for protecting EAP
   packets, which are not in EAP-AKA' FS.  Based on this extension, the
   executions of reauthentication after a full authentication will be
   unlinkable to each other and then the privacy of end users is
   enhanced.  This update is optional to the above standards.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 January 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights

Wang & Lei               Expires 7 January 2027                 [Page 1]
Internet-Draft  Forward Secure Reauthentication in EAP-A       July 2026

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Linkable Reauthentication in EAP-AKA' FS  . . . . . . . . . .   4
     3.1.  Review of EAP-AKA' FS . . . . . . . . . . . . . . . . . .   4
     3.2.  Linkable Reauthentication Identities  . . . . . . . . . .   5
   4.  Forward Secure Reauthentication . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   EAP-AKA (Extensible Authentication Protocol method for 3rd Generation
   Authentication and Key Agreement) [RFC4187] is a secure
   authentication method used for mobile devices connecting to networks
   (like Wi-Fi) using their credentials from SIM/USIM cards.  It enables
   mutual authentication and key exchange between the mobile devices and
   their mobile network operator.  After that, communication data can be
   securely transmitted between them by using various key materials
   agreed in EAP-AKA.

   EAP-AKA' (Improved Extensible Authentication Protocol Method for 3rd
   Generation Authentication and Key Agreement) [RFC5448], introduces a
   new key derivation function, SHA-256, instead of SHA-1.  This
   function is also used to bind the keys derived within the method to
   the name of the access network.  This limits the effects of
   compromised access network nodes and keys.

   Moreover, "Improved Extensible Authentication Protocol Method for
   3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')"
   [RFC9048] specifies the protocol behavior for both 4G and 5G
   deployments using EAP-AKA'.  For example, how the Network Name field
   is constructed in the protocol; how EAP-AKA' uses identifiers in 5G;
   how to define session identifiers and other exported parameters
   (including the case for fast reauthentication), and how to update the
   requirements on generating pseudonym usernames and fast
   reauthentication identities to ensure identity privacy.

Wang & Lei               Expires 7 January 2027                 [Page 2]
Internet-Draft  Forward Secure Reauthentication in EAP-A       July 2026

   "Forward Secrecy Extension to the Improved Extensible Authentication
   Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)"
   [RFC9678] enhances the forward security for the session keys
   generated as a part of the authentication run in EAP-AKA', by
   introducing ephemeral Diffie-Hellman key exchange.  This prevents an
   attacker who has gained access to the long-term key from compromising
   session keys established in the past.  However, as noted in
   Section 7.6 of [RFC9678], K_encr, the key for encrypting
   reauthentication pseudonym identities, is not forward secure, as it
   is generated before ephemeral DH.  Therefore, "an adversary
   compromising the long-term key would be able to link reauthentication
   protocol runs when pseudonyms are used, within a sequence of runs
   followed after a full EAP-AKA' authentication.  No such linking would
   be possible across different full authentication runs.  If the
   pseudonym linkage risk is not acceptable, one way to avoid the
   linkage is to always require full EAP-AKA' authentication."

   However, as discussed in [RFC4187], reauthentication is much faster
   and then benefits both mobile devices and the network operator.
   Having full EAP AKA' authentication defeats the purpose of fast
   reauthentication.  This document specifies an update to enhance the
   forward security for TEKs (including K_encr) in EAP-AKA' FS.  Based
   on this, it is not feasible to link the executions of
   reauthentication within the session of a full authentication.  When
   this extension is enabled, the privacy of mobile device users is
   protected against long-term key compromise.  This update is
   applicable and optional to all standards specified in [RFC9678],
   [RFC9048], [RFC5448], and [RFC4187].

   This extension is also applicable and optional to the drafts
   specified in [I-D.ietf-emu-pqc-eapaka] and
   [I-D.ietf-emu-hybrid-pqc-eapaka], where the ephemeral DH key exchange
   is replaced by post-quantum (PQ) KEM and hybrid KEMs [RFC9794],
   respectively.

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.

   Readers are assumed familiar with the terms in EAP-AKA [RFC4187],
   EAP-AKA' [RFC5448] [RFC9048], and EAP-AKA' FS [RFC9678].  The
   implication of forward security is discussed in Sections 1 and 4.3 of
   [RFC9678], and the usage of reauthentication is discussed in
   Section 5 of [RFC4187], and Sections 6.5.4 and 6.5.5 of [RFC9678].

Wang & Lei               Expires 7 January 2027                 [Page 3]
Internet-Draft  Forward Secure Reauthentication in EAP-A       July 2026

3.  Linkable Reauthentication in EAP-AKA' FS

3.1.  Review of EAP-AKA' FS

   The normal process of EAP-AKA' FS is briefly reviewed in Figure 1,
   where AD denotes the 3GPP Authentication Database.  Details can be
   found in Section 5 of [RFC9678].

USIM              Peer                         Server                    AD
  |                |                             |                        |
  |                |   (1) EAP-Req/Identity      |                        |
  |                |<----------------------------|                        |
  |                |   (2) EAP-Resp/Identity     |                        |
  |                |     (Privacy-Friendly)      |                        |
  |                |---------------------------->|                        |
  |                |                             |(3) ID, KDF,network name|
  |                |                             |----------------------->|
  |                |                             |(4) RAND, AUTN, XRES,   |
  |                |                             |     CK', IK'           |
  |                |                             |<-----------------------|
  |                | (5) EAP-Req/AKA'-Challenge  |                        |
  |                |  AT_RAND, AT_AUTN, AT_KDF,  |                        |
  |                |  AT_KDF_FS, AT_KDF_INPUT,   |                        |
  |                |  AT_PUB_ECDHE, AT_MAC       |                        |
  |                |<----------------------------|                        |
  |(6) RAND, AUTN  |                             |                        |
  |<---------------|                             |                        |
  |(7) CK, IK, RES |                             |                        |
  |--------------->|                             |                        |
  |                |(8) EAP-Resp/AKA'-Challenge  |                        |
  |                | AT_RES, AT_PUB_ECDHE, AT_MAC|                        |
  |                |---------------------------->|                        |
  |                |     (9)  EAP-Success        |                        |
  |                |<----------------------------|                        |

Figure 1. EAP-AKA' FS Authentication Process (Section 5 of RFC 9678)

   Key materials are derived in EAP-AKA' FS as shown in Figure 2
   (Section 6.3 of [RFC9678]).  Note that the TEKs, consisting of both
   K_encr and K_aut, are part of MK (Master Key).  However, MK itself is
   derived from IK' and CK' without the ephemeral SHARED_SECRET,
   obtained via running ephemeral DH key exchange.  Therefore, both
   K_encr and K_aut are not forward secure, as they just rely on the
   security of the long-term key, shared by the peer's USIM and the
   mobile network operator's AD.  Note that IK' and CK' are derived from
   this long-term key.

Wang & Lei               Expires 7 January 2027                 [Page 4]
Internet-Draft  Forward Secure Reauthentication in EAP-A       July 2026

   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]

   Figure 2. Key Derivation in EAP-AKA' FS (Section 6.3 of RFC 9678)

   In more detail, the ephemeral SHARED_SECRET is generated from
   ephemeral DH values available in two AT_PUB_ECDHE attributes,
   exchanged by the peer and server in Steps (5) and (8) in Figure 1.
   However, K_encr and K_aut are generated by the server after Step (4)
   and used in Step (5) to protect the info for the peer.  And
   similarly, they are generated after Step (7) by the peer and used to
   verify and decrypt ciphertext sent in Step (5), and used in Step (8)
   to protect the info for the server.  So, the ephemeral SHARED_SECRET
   is available later than when K_encr and K_aut are generated and used
   by the server and the peer.  So, in case the long-term key is
   compromised, K_encr and K_aut will be compromised too.

3.2.  Linkable Reauthentication Identities

   Figure 3 is a brief review of the reauthentication procedure, which
   is specified in Section 5.4 of [RFC4187].  Here all attributes with
   '*' denote that they are encrypted using the encryption key K_encr,
   and encapsulated in the AT_ENCR_DATA attribute.  For offering the
   peer a new reauthentication identity for the next run, the
   authenticator generates a pseudonym and uses K_encr to encrypt it in
   the optional attribute AT_NEXT_REAUTH_ID.  At the same time, the
   authenticator uses integrity key K_aut to produce a MAC in the
   atttibute AT_MAC in Step (3).

Wang & Lei               Expires 7 January 2027                 [Page 5]
Internet-Draft  Forward Secure Reauthentication in EAP-A       July 2026

    Peer                                               Authenticator
     |                                                           |
     |          (1) EAP-Request/Identity                         |
     |<----------------------------------------------------------|
     |          (2) EAP-Response/Identity                        |
     |      (Includes a fast reauthentication identity)          |
     |---------------------------------------------------------->|
     |          (3) EAP-Request/AKA-Reauthentication             |
     |     (AT_IV, AT_ENCR_DATA, *AT_COUNTER, *AT_NONCE_S,       |
     |      *AT_NEXT_REAUTH_ID, AT_MAC)                          |
     |<----------------------------------------------------------|
     |          (4) EAP-Response/AKA-Reauthentication            |
     |(AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, AT_MAC) |
     |---------------------------------------------------------->|
     |          (5)  EAP-Succes                                  |
     |<----------------------------------------------------------|

   Figure 3. Reauthentication Procedure (Section 5.4 of RFC 4187)

   As discussed above, K_encr and K_aut will be compromised if the long-
   term key is leaked.  So, in such case, the attacker with access to
   the long-term key will be able to decrypt all reauthentication
   identities delivered from the server to the peer.  When these
   identities are used for reauthentication, the attacker will be able
   to link these runs of reauthentication, even those reauthentication
   identities are pseudonyms generated by the server independently.

   Moreover, even without decrypting the reauthentication identities
   from the AT_NEXT_REAUTH_ID attributes, the attacker can also link two
   or more runs of reauthentication by using the integrity key K_aut.
   Namely, the attacker can check the AT_MAC attributes sent by either
   the authenticator in Step (3) or the peer in Step (4) to be sure that
   different runs belong to the same peer, if all these AT_MAC
   attributes are valid with respect to the given K_aut.

   Therefore, to guarantee the privacy of mobile users running
   reauthentication with compromised long-term key, it is necessary to
   enhance the forward security of the TEKs, i.e, K_encr and K_aut.

4.  Forward Secure Reauthentication

   To enable the forward security of K_encr and K_aut, this document
   specifies a concrete key derivation process given in Figure 4.
   (EDITOR'S NOTE: Other variants are also available.)

Wang & Lei               Expires 7 January 2027                 [Page 6]
Internet-Draft  Forward Secure Reauthentication in EAP-A       July 2026

   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_encr'  = MK_ECDHE[0..127]
   K_aut'   = MK_ECDHE[128..383]
   K_re     = MK_ECDHE[384..639]
   MSK      = MK_ECDHE[640..1060]
   EMSK     = MK_ECDHE[1061..1633]

           Figure 4.  The Proposed Key Derivation Process

   In this process, K_encr and K_aut are updated after completing full
   EAP-AKA' FS authentication in Figure 1 to forward secure K_encr' and
   K_aut', which are derived from IK', CK' and SHARED_SECRET, the
   ephemeral secret.  And only K_encr' and K_aut' are used to protect
   the transmission and usage of reauthenticaton identities in
   reauthentication procedure in Figure 3.

   The whole process will be elaborated later.

5.  Security Considerations

   Security considerations will be added later.

6.  IANA Considerations

   At the time of writing, there are no IANA considerations that may
   need to be considered.

7.  Acknowledgments

   To be added later.

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <https://www.rfc-editor.org/info/rfc3748>.

Wang & Lei               Expires 7 January 2027                 [Page 7]
Internet-Draft  Forward Secure Reauthentication in EAP-A       July 2026

   [RFC4187]  Arkko, J. and H. Haverinen, "Extensible Authentication
              Protocol Method for 3rd Generation Authentication and Key
              Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
              January 2006, <https://www.rfc-editor.org/info/rfc4187>.

   [RFC5448]  Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
              Extensible Authentication Protocol Method for 3rd
              Generation Authentication and Key Agreement (EAP-AKA')",
              RFC 5448, DOI 10.17487/RFC5448, May 2009,
              <https://www.rfc-editor.org/info/rfc5448>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9048]  Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
              "Improved Extensible Authentication Protocol Method for
              3GPP Mobile Network Authentication and Key Agreement (EAP-
              AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
              <https://www.rfc-editor.org/info/rfc9048>.

   [RFC9678]  Arkko, J., Norrman, K., and J. Preuß Mattsson, "Forward
              Secrecy Extension to the Improved Extensible
              Authentication Protocol Method for Authentication and Key
              Agreement (EAP-AKA' FS)", RFC 9678, DOI 10.17487/RFC9678,
              March 2025, <https://www.rfc-editor.org/info/rfc9678>.

   [FIPS203]  National Institute of Standards and Technology, "FIPS 203:
              Module-Lattice-Based Key-Encapsulation Mechanism
              Standard", Federal Information Processing Standards
              Publication , August 2024,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.203.pdf>.

9.  Informative References

   [I-D.ietf-emu-hybrid-pqc-eapaka]
              Banerjee, A. and T. Reddy.K, "Enhancing Security in EAP-
              AKA' with Hybrid Post-Quantum Cryptography", Work in
              Progress, Internet-Draft, draft-ietf-emu-hybrid-pqc-
              eapaka-01, 26 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-emu-
              hybrid-pqc-eapaka-01>.

Wang & Lei               Expires 7 January 2027                 [Page 8]
Internet-Draft  Forward Secure Reauthentication in EAP-A       July 2026

   [I-D.ietf-emu-pqc-eapaka]
              Reddy.K, T. and A. Banerjee, "Post-Quantum Key
              Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime", Work
              in Progress, Internet-Draft, draft-ietf-emu-pqc-eapaka-02,
              17 March 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-emu-pqc-eapaka-02>.

   [RFC9794]  Driscoll, F., Parsons, M., and B. Hale, "Terminology for
              Post-Quantum Traditional Hybrid Schemes", RFC 9794,
              DOI 10.17487/RFC9794, June 2025,
              <https://www.rfc-editor.org/info/rfc9794>.

Authors' Addresses

   Guilin Wang (editor)
   Huawei Int. Pte Ltd
   9 North Buona Vista Drive, #13-01
   The Metropolis Tower 1
   SINGAPORE 138588
   Singapore
   Email: wang.guilin@huawei.com

   Zhongding Lei
   Huawei Int. Pte Ltd
   9 North Buona Vista Drive, #13-01
   The Metropolis Tower 1
   SINGAPORE 138588
   Singapore
   Email: lei.zhongding@huawei.com

Wang & Lei               Expires 7 January 2027                 [Page 9]