RFC 5448

Q: What does the Introduction section cover in RFC 5448 — EAP-AKA'?

The Introduction section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 5448 — EAP-AKA'. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the Key Changes from EAP-AKA section cover in RFC 5448 — EAP-AKA'?

The Key Changes from EAP-AKA section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 5448 — EAP-AKA'. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the CK'/IK' Key Derivation section cover in RFC 5448 — EAP-AKA'?

The CK'/IK' Key Derivation section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 5448 — EAP-AKA'. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the Protocol Flow section cover in RFC 5448 — EAP-AKA'?

The Protocol Flow section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 5448 — EAP-AKA'. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the AT_KDF_INPUT and AT_KDF Attributes section cover in RFC 5448 — EAP-AKA'?

The AT_KDF_INPUT and AT_KDF Attributes section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 5448 — EAP-AKA'. This content is part of the BLACKLABS RFC Reference Library.

BLACKLABS

Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')

Standards Track Updates: RFC 4187

May 2009

Abstract: This document specifies EAP-AKA', a revised version of EAP-AKA that provides key separation between keys for different access networks. This is achieved by binding the derived keys to the name of the access network, preventing key reuse across networks. EAP-AKA' is the mandatory EAP method for 5G non-3GPP access.

Canonical source: https://www.rfc-editor.org/rfc/rfc5448 | IETF Datatracker

1. Introduction

▶

EAP-AKA' addresses a key separation weakness in EAP-AKA: in the original protocol, the same CK/IK values could be used across different access networks. EAP-AKA' binds derived keys to the access network name, ensuring that keys derived for one network cannot be reused in another.

This is the mandatory authentication method for 5G non-3GPP access (via N3IWF/TNGF) as specified in TS 33.501.

2. Key Changes from EAP-AKA

▶

EAP-AKA' introduces the following changes over EAP-AKA:

CK'/IK' derivation: Instead of using CK/IK directly, new keys CK' and IK' are derived by incorporating the access network name (AT_KDF_INPUT)
AT_KDF_INPUT: New attribute carrying the access network name for key binding
AT_KDF: New attribute specifying the Key Derivation Function to use
SHA-256: Uses SHA-256 instead of SHA-1 for MK derivation
Method type 50: EAP-AKA' uses EAP type 50 (vs type 23 for EAP-AKA)

3. CK'/IK' Key Derivation

▶

The fundamental security improvement is the derivation of CK' and IK' from the original CK, IK, and the serving network name:

Key derivation (TS 33.501 Annex A.2):
(CK', IK') = KDF(CK || IK, FC=0x20 || SN_name || SN_name_length || SQN⊕AK || 0x0006)

Where SN_name = "5G:mnc<MNC>.mcc<MCC>.3gppnetwork.org" for 5G access

4. Protocol Flow

▶

  UE/USIM            N3IWF/Authenticator      AUSF
|                      |                    |
|  EAP-Req/Identity    |                    |
|<---------------------|                    |
|  EAP-Resp/Identity   |                    |
|  (SUCI)              |                    |
|--------------------->|  Nausf_Auth        |
|                      |------------------->|
|                      |  EAP-Req/AKA'-     |
|                      |  Challenge         |
|                      |<-------------------|
|  EAP-Req/AKA'-Challenge                   |
|  (AT_RAND, AT_AUTN,  |                    |
|   AT_KDF_INPUT,      |                    |
|   AT_KDF, AT_MAC)    |                    |
|<---------------------|                    |
|                      |                    |
|  Derive CK',IK' from |                    |
|  CK,IK + SN_name     |                    |
|                      |                    |
|  EAP-Resp/AKA'-Challenge                  |
|  (AT_RES, AT_MAC)    |                    |
|--------------------->|------------------->|
|                      |  Verify, derive    |
|                      |  K_AUSF from EMSK  |
|  EAP-Success         |<-------------------|
|<---------------------|                    |

5. AT_KDF_INPUT and AT_KDF Attributes

▶

Attribute	Purpose	5G Value
AT_KDF_INPUT	Access network identifier for key binding	"5G:mnc<MNC>.mcc<MCC>.3gppnetwork.org"
AT_KDF	Key Derivation Function identifier	1 = HMAC-SHA-256 based KDF (mandatory for 5G)

6. 5G Key Hierarchy Integration

▶

In 5G (TS 33.501), EAP-AKA' feeds into the 5G key hierarchy as follows:

  USIM: K, OP/OPc
│
│ AKA algorithm → RAND, AUTN, XRES, CK, IK
│
▼
┌─────────────────────────┐
│ CK'/IK' = KDF(CK||IK,  │
│           SN_name)      │
└───────────┬─────────────┘
│
▼
┌─────────────────────────┐
│ MK = SHA-256(Identity   │
│     || IK' || CK')      │
└───────────┬─────────────┘
│
┌─────────┼──────────┐
▼         ▼          ▼
K_encr   K_aut      K_re
│
┌─────────┼──────────┐
▼         ▼          ▼
MSK       EMSK     K_AUSF = EMSK[0..31]
│
▼
K_SEAF
│
▼
K_AMF
/    \
K_NASenc  K_NASint

7. Security Considerations

▶

Key separation: CK'/IK' binding to SN_name prevents roaming key reuse attacks
Bidding-down protection: AT_BIDDING attribute prevents downgrade from EAP-AKA' to EAP-AKA (enhanced in RFC 9048)
SHA-256: Stronger hash function than SHA-1 used in EAP-AKA
Forward secrecy: Not provided by EAP-AKA' alone — requires additional mechanisms at transport layer (e.g., TLS 1.3 with ephemeral DH)
SUCI privacy: 5G enhances identity privacy via SUCI (encrypted SUPI) — not part of original RFC 5448, added by TS 33.501 and RFC 9048