RFC 4187

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

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

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

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

Q: What does the AT_ Attributes section cover in RFC 4187 — EAP-AKA?

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

Q: What does the Key Derivation section cover in RFC 4187 — EAP-AKA?

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

Q: What does the Re-authentication section cover in RFC 4187 — EAP-AKA?

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

BLACKLABS

Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)

Standards Track

January 2006

Abstract: This document specifies an EAP method based on the 3GPP UMTS Authentication and Key Agreement (AKA) mechanism. EAP-AKA enables mutual authentication and session key distribution using the USIM, and is used for authenticating subscribers connecting to non-3GPP access networks.

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

1. Introduction

▶

EAP-AKA uses the UMTS AKA mechanism (3GPP TS 33.102) within the EAP framework. It provides mutual authentication between the USIM and the network, and derives keying material (MSK, EMSK) for securing the access link.

The method was originally designed for UMTS/LTE non-3GPP access scenarios. For 5G, EAP-AKA' (RFC 5448) is preferred due to its improved key binding properties.

2. Protocol Flow

▶

EAP-AKA authentication involves the exchange of AT_ (attribute) prefixed parameters that carry AKA challenge data:

  UE/USIM              Authenticator         AuC/AUSF
|                      |                    |
|  EAP-Req/Identity    |                    |
|<---------------------|                    |
|                      |                    |
|  EAP-Resp/Identity   |                    |
|  (IMSI/SUCI)         |                    |
|--------------------->|  Auth-Data-Req     |
|                      |------------------->|
|                      |  Auth-Data-Resp    |
|                      |  (RAND,AUTN,XRES,  |
|                      |   CK, IK)          |
|                      |<-------------------|
|  EAP-Req/AKA-Challenge                    |
|  (AT_RAND, AT_AUTN,  |                    |
|   AT_MAC)             |                    |
|<---------------------|                    |
|                      |                    |
|  USIM: verify AUTN   |                    |
|  compute RES, CK, IK |                    |
|                      |                    |
|  EAP-Resp/AKA-Challenge                   |
|  (AT_RES, AT_MAC)    |                    |
|--------------------->|                    |
|                      |  Verify AT_RES     |
|  EAP-Success         |                    |
|<---------------------|                    |

3. AT_ Attributes

▶

EAP-AKA defines several attributes carried in EAP Request/Response packets:

Attribute	Code	Description
AT_RAND	1	RAND value — 128-bit random challenge from network
AT_AUTN	2	AUTN value — authentication token for mutual auth (SQN ⊕ AK \|\| AMF \|\| MAC-A)
AT_RES	3	RES value — response computed by USIM, compared against XRES
AT_AUTS	4	AUTS — sent when SQN is out of sync for re-synchronization
AT_PADDING	6	Padding to align attribute to 4-byte boundary
AT_NONCE_MT	7	Random nonce from peer for fast re-authentication
AT_PERMANENT_ID_REQ	10	Request for permanent identity (IMSI)
AT_MAC	11	Message authentication code over entire EAP packet
AT_NOTIFICATION	12	Notification code for error/success indication
AT_IDENTITY	14	Subscriber identity in EAP-Response
AT_CHECKCODE	134	Hash of EAP messages exchanged before protected phase

4. Key Derivation

▶

EAP-AKA derives session keys from CK and IK produced by the AKA algorithm. The Master Key (MK) is computed as:

MK = SHA-1(Identity | IK | CK)
MSK = MK[0..63] (first 64 bytes via PRF)
EMSK = MK[64..127] (next 64 bytes)
K_encr = MK[128..143] — encryption key for AT_ENCR_DATA
K_aut = MK[144..159] — authentication key for AT_MAC

5. Re-authentication

▶

EAP-AKA supports fast re-authentication to avoid running the full AKA algorithm on every authentication. The re-authentication identity and counter are protected with AT_ENCR_DATA.

Fast re-authentication uses a counter (AT_COUNTER) and a nonce (AT_NONCE_S) from the server to derive new keys without involving the USIM.

6. Security Considerations

▶

EAP-AKA inherits the security properties of UMTS AKA: 128-bit mutual authentication, sequence number-based replay protection, and cryptographic key agreement.

Identity privacy: Permanent identity (IMSI) can be requested in cleartext — mitigated in 5G by SUCI concealment (TS 33.501 §6.12)
Key binding gap: CK/IK are not bound to the access network name — fixed in EAP-AKA' (RFC 5448)
Bidding-down: No protection against downgrade from EAP-AKA' to EAP-AKA — addressed in RFC 9048
Replay protection: SQN-based freshness in AKA vectors; AT_COUNTER for re-authentication
AT_MAC: Integrity-protects all EAP-AKA packets after the Challenge, using HMAC-SHA1-128