EAP-WSIM: SIM-Based EAP Authentication for Enterprise Wi-Fi Using the MILENAGE-ML-KEM-FWD Construction
draft-gupta-emu-eap-wsim-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Praveen Gupta | ||
| Last updated | 2026-07-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gupta-emu-eap-wsim-01
Network Working Group P. Gupta
Internet-Draft MobileStack, Inc.
Intended status: Standards Track 20 July 2026
Expires: 21 January 2027
EAP-WSIM: SIM-Based EAP Authentication for Enterprise Wi-Fi Using the
MILENAGE-ML-KEM-FWD Construction
draft-gupta-emu-eap-wsim-01
Abstract
Enterprise Wi-Fi networks authenticate devices using enterprise
credentials and provisioning policies that are entirely independent
of MNO subscriber identity. As a result, MNO application traffic on
enterprise Wi-Fi is completely anonymous at the Wi-Fi layer: the
enterprise cannot identify MNO subscribers, apply per-subscriber QoS,
or support fast BSS transitions for VoWiFi continuity.
This document specifies EAP-WSIM, an evolutionary enhancement of EAP-
AKA' (RFC 9048) that enables MNO devices to authenticate to
enterprise Wi-Fi using their existing SIM credential (WSIM-Card)
without contacting the MNO backend during authentication. A WSIM-
Authentication Server (WSIM-AS) within the enterprise Wi-Fi
infrastructure holds MNO-provisioned MASTER KEY material in tamper-
resistant security hardware. Per-subscriber MILENAGE key material is
derived on-demand from the MASTER KEY using the device's IMSI --
identical in principle to MNO SIM personalization -- entirely within
the security hardware boundary. No per-subscriber key provisioning
at the WSIM-AS is required.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/.
Discussion of this document takes place on the EAP Method Update
Working Group mailing list (mailto:emu@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at
https://www.ietf.org/mailman/listinfo/emu/.
IPR Notice
Gupta Expires 21 January 2027 [Page 1]
Internet-Draft EAP-WSIM July 2026
The author has filed IPR disclosures for US Provisional Patent
Applications 64/048,069 and 64/046,079 at the IETF Datatracker. In
accordance with BCP 79 [RFC8179], the author commits to RAND-z
(royalty-free) licensing for any RFC produced from this document.
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 21 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Enterprise Wi-Fi and MNO Traffic Are Disconnected
Today . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Why Existing SIM-Based EAP Methods Do Not Apply . . . . . 7
3.3. Why Alternative Approaches Are Insufficient . . . . . . . 8
3.3.1. Hosted MNO RADIUS Services . . . . . . . . . . . . . 8
3.3.2. Enterprise 802.11r with EAP-TLS . . . . . . . . . . . 8
3.3.3. DSCP-Based QoS Without Authentication . . . . . . . . 9
Gupta Expires 21 January 2027 [Page 2]
Internet-Draft EAP-WSIM July 2026
3.4. The MNO Device Wi-Fi Compliance Gap . . . . . . . . . . . 9
4. EAP-WSIM Overview . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 9
4.2. System Components . . . . . . . . . . . . . . . . . . . . 10
4.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Deployability Considerations . . . . . . . . . . . . . . 13
4.6. Multi-MNO Deployment . . . . . . . . . . . . . . . . . . 13
5. WSIM-AS MASTER KEY Architecture . . . . . . . . . . . . . . . 13
5.1. MASTER KEY Provisioning . . . . . . . . . . . . . . . . . 13
5.2. Per-Subscriber Key Derivation . . . . . . . . . . . . . . 14
5.3. Security Hardware Boundary . . . . . . . . . . . . . . . 14
5.4. MASTER KEY Scope and Revocation . . . . . . . . . . . . . 14
6. The MILENAGE-ML-KEM-FWD Construction . . . . . . . . . . . . 15
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. WSIM-SLOT-SELECT Algorithm . . . . . . . . . . . . . . . 16
6.4. Construction Steps . . . . . . . . . . . . . . . . . . . 17
6.5. Output Key Material . . . . . . . . . . . . . . . . . . . 18
6.6. Security Properties . . . . . . . . . . . . . . . . . . . 18
6.7. ML-KEM-768 Rationale . . . . . . . . . . . . . . . . . . 19
7. EAP-WSIM Protocol . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Pre-Association Phase . . . . . . . . . . . . . . . . . . 20
7.2. EAP Exchange Overview . . . . . . . . . . . . . . . . . . 20
7.3. Message Header . . . . . . . . . . . . . . . . . . . . . 20
7.4. Attribute Encoding . . . . . . . . . . . . . . . . . . . 21
7.5. WSIM-Start (Subtype 0x01, WSIM-AS to WSIM-Card) . . . . . 22
7.6. WSIM-Challenge (Subtype 0x02, WSIM-Card to WSIM-AS) . . . 22
7.7. WSIM-Confirm (Subtype 0x03, WSIM-AS to WSIM-Card) . . . . 22
7.8. WSIM-Complete (Subtype 0x04, WSIM-Card to WSIM-AS) . . . 22
7.9. WSIM-Error (Subtype 0x05) . . . . . . . . . . . . . . . . 22
7.10. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 23
7.11. Identity Privacy . . . . . . . . . . . . . . . . . . . . 23
8. MSK, EMSK, and 802.11r Integration . . . . . . . . . . . . . 24
8.1. EAP Session-ID . . . . . . . . . . . . . . . . . . . . . 24
8.2. MSK, EMSK, and Key Export . . . . . . . . . . . . . . . . 24
8.3. IEEE 802.11r Key Hierarchy . . . . . . . . . . . . . . . 24
9. Relationship to Existing EAP Methods . . . . . . . . . . . . 25
9.1. EAP-AKA Evolution Chain . . . . . . . . . . . . . . . . . 25
9.2. Relationship to RFC 9678 (EAP-AKA' FS) . . . . . . . . . 25
9.3. Relationship to EMU WG PQC Work . . . . . . . . . . . . . 26
9.4. Relationship to EAP-FIDO . . . . . . . . . . . . . . . . 26
9.5. Relationship to EAP-PSK-256 . . . . . . . . . . . . . . . 26
9.6. Relationship to HOKEY WG (Handover Keying) . . . . . . . 26
9.7. Centralized Wi-Fi Controller Architectures . . . . . . . 27
10. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11.1. Security of MILENAGE-ML-KEM-FWD . . . . . . . . . . . . 28
Gupta Expires 21 January 2027 [Page 3]
Internet-Draft EAP-WSIM July 2026
11.2. MASTER KEY Security . . . . . . . . . . . . . . . . . . 28
11.3. Ephemeral Key Lifecycle . . . . . . . . . . . . . . . . 28
11.4. K_mac_start Security Properties . . . . . . . . . . . . 28
11.5. MILENAGE AMF Field . . . . . . . . . . . . . . . . . . . 28
11.6. Post-Quantum Security Analysis . . . . . . . . . . . . . 28
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
14. Normative References . . . . . . . . . . . . . . . . . . . . 29
15. Informative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. Changes from Previous Version . . . . . . . . . . . 32
Appendix B. Test Vectors (MILENAGE-ML-KEM-FWD) . . . . . . . . . 34
B.1. MILENAGE Inputs (same as Appendix C) . . . . . . . . . . 34
B.2. MILENAGE Outputs (verified against TS 35.208 Test Set
1) . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
B.3. ML-KEM-768 Key Exchange . . . . . . . . . . . . . . . . . 34
B.4. Session Key Derivation . . . . . . . . . . . . . . . . . 34
Appendix C. Test Vectors: MILENAGE Baseline . . . . . . . . . . 35
C.1. MILENAGE Input Parameters . . . . . . . . . . . . . . . . 35
C.2. MILENAGE Sub-Function Outputs . . . . . . . . . . . . . . 35
C.3. AUTN Construction and K_mac_start . . . . . . . . . . . . 36
C.4. Session Nonces (Informative) . . . . . . . . . . . . . . 36
C.5. Reference Output Key Material (MILENAGE-ECDH-FWD
Construction) . . . . . . . . . . . . . . . . . . . . . . 36
Appendix D. Future Work . . . . . . . . . . . . . . . . . . . . 36
Appendix E. WSIM-Card File Structure (Informative) . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
Enterprise Wi-Fi networks today authenticate devices using enterprise
credentials and provisioning policies -- EAP-TLS with enterprise
certificates, PEAP with Active Directory, or pre-shared keys -- that
are entirely independent of MNO subscriber identity. MNO devices
follow the same enterprise authentication path as any other device:
they present enterprise credentials to connect to the corporate SSID,
or connect to a guest SSID with no authentication. Either way, the
MNO SIM credential plays no role in Wi-Fi access.
Once connected to enterprise Wi-Fi, an MNO device running VoWiFi
establishes an IPsec tunnel to the MNO's ePDG. All MNO application
traffic -- voice calls, MNO data flows -- travels inside this tunnel.
From the enterprise Wi-Fi layer's perspective, this traffic is
completely anonymous: the enterprise sees only encrypted ESP packets
with no knowledge of the subscriber identity, the MNO, or the
application inside the tunnel.
Gupta Expires 21 January 2027 [Page 4]
Internet-Draft EAP-WSIM July 2026
This anonymity has two consequences that this document addresses.
First, the enterprise cannot provide per-subscriber QoS for MNO
traffic. VoWiFi requires WMM AC_VO prioritization, but without
authenticated subscriber identity the enterprise has no trusted basis
on which to apply it. Second, fast BSS transition (IEEE 802.11r) for
VoWiFi continuity is unavailable: on a guest SSID there is no 802.1X
exchange and therefore no MSK, no PMK, and no PMK-R0. Every AP
crossing during an active VoWiFi call requires a full re- association
costing 1,800-2,900 ms -- sufficient to drop any call.
EAP-WSIM resolves both problems by introducing a WSIM-Authentication
Server (WSIM-AS) into the enterprise Wi-Fi infrastructure. The WSIM-
AS authenticates MNO devices using their existing SIM credential (the
WSIM-Card -- the device's existing MNO SIM card, no new card is
introduced). This authentication surfaces MNO subscriber identity at
the 802.11 association layer, produces PMK-R0/R1 locally within the
enterprise for 802.11r fast transitions, and enables per-subscriber
QoS and policy enforcement.
EAP-WSIM does not replace enterprise Wi-Fi authentication. It
operates as an additional authentication method for MNO devices,
integrating the Wi-Fi and MNO application layers for the first time.
EAP-WSIM is an evolutionary enhancement of EAP-AKA', following the
same improvement pattern as: EAP-AKA [RFC4187] -> EAP-AKA' [RFC9048]
(SHA-256 KDF, non-3GPP access) -> EAP-AKA' FS [RFC9678] (forward
secrecy via ephemeral ECDH). EAP-WSIM adds: removal of the MNO
backend from the active authentication loop; post-quantum forward
secrecy via ML-KEM-768 [FIPS203] replacing ECDH P-256; and 802.11r
PMK-R0/R1 derivation at the enterprise edge.
The WSIM-AS holds MASTER KEY material -- not per-subscriber keys.
Per-subscriber MILENAGE key material is derived on-demand within the
WSIM-AS tamper-resistant security hardware using the device's IMSI,
identical in principle to how the MNO derives and provisions key
material during SIM card personalization. The WSIM-AS therefore
automatically supports any subscriber of the provisioned MNO without
per-subscriber configuration.
2. Terminology
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.
WSIM-Card: The SIM card on the MNO device side. The WSIM-Card is
Gupta Expires 21 January 2027 [Page 5]
Internet-Draft EAP-WSIM July 2026
the device's existing MNO-provisioned SIM card -- not a new or
separate card. It holds IMSI, Ki, and the MILENAGE algorithm,
identical to those used for 4G/5G cellular authentication. No
device-side hardware or software changes are required.
WSIM-Authentication Server (WSIM-AS): The authentication server
component deployed within enterprise Wi-Fi infrastructure and
provisioned by the MNO. The WSIM-AS contains tamper-resistant
security hardware (MASTER-MNO-SIM-Card or Key-HW) holding indexed
MASTER KEY material. Per-subscriber MILENAGE key material is
derived on-demand within this hardware using the connecting
device's IMSI. All cryptographic operations are confined within
the hardware security boundary.
MASTER KEY: MNO-provisioned root key material held within the WSIM-
AS tamper-resistant security hardware. Indexed to support
multiple MNOs and key versions. From the MASTER KEY and a
subscriber's IMSI, the hardware derives per-subscriber MILENAGE
key material equivalent to Ki on the subscriber's WSIM-Card.
MASTER-MNO-SIM-Card / Key-HW: The physical tamper-resistant hardware
within the WSIM-AS holding MASTER KEY material and performing all
per-subscriber key derivation and cryptographic operations.
K_sub: Per-subscriber MILENAGE key derived on-demand within the
WSIM-AS security hardware: K_sub = KDF(MASTER_KEY[index], IMSI).
K_sub is functionally equivalent to Ki on the subscriber's WSIM-
Card. It is never stored or exported outside the hardware
security boundary.
MILENAGE-ML-KEM-FWD: The cryptographic construction defined in
Section 6. Combines MILENAGE mutual authentication with ML-
KEM-768 [FIPS203] key encapsulation for post-quantum forward
secrecy. Replaces
K_SLOT[i]: One of 15 independent 256-bit key bundle elements (i =
0..14) pre-provisioned on the UE SIM at manufacturing. On the
WSIM-AS side, these are derived on-demand from the MASTER KEY;
they are not stored persistently at the WSIM-AS.
WSIM-SLOT-SELECT: A non-reversible, IMSI-bound, Time-of-Day
algorithm executed independently by WSIM-AS and WSIM-Card to
determine the active slot index. Both parties deterministically
select the same slot without communication, as specified in
[I-D.gupta-emu-wsim-key-select].
PMK-R0 / PMK-R1: Pairwise Master Keys defined in IEEE 802.11r for
Gupta Expires 21 January 2027 [Page 6]
Internet-Draft EAP-WSIM July 2026
Fast BSS Transition, derived locally at the WSIM-AS from
MSK[0:32].
MNO: Mobile Network Operator.
CRQC: Cryptographically Relevant Quantum Computer.
VoWiFi: Voice over Wi-Fi, via IPsec tunnel to MNO ePDG.
MSK: Master Session Key, 64 bytes, per [RFC5247].
EMSK: Extended Master Session Key, 64 bytes, per [RFC5247].
Figure 1
3. Problem Statement
3.1. Enterprise Wi-Fi and MNO Traffic Are Disconnected Today
Enterprise Wi-Fi authentication and MNO subscriber identity operate
as completely independent layers. An MNO device on an enterprise
campus connects to Wi-Fi using either enterprise credentials (EAP-TLS
certificate, PEAP/MSCHAPv2, or similar) for a corporate SSID, or
through a guest SSID or captive portal with minimal authentication.
In either case, the MNO SIM credential plays no role in Wi-Fi access,
and the enterprise network has no knowledge of the device's MNO
subscriber identity.
In either case, MNO application traffic -- VoWiFi calls, MNO data
services -- travels inside an IPsec tunnel to the MNO's ePDG. The
enterprise sees only encrypted ESP packets. It has no visibility
into which device is an MNO subscriber, which MNO provisioned it,
whether it is running an active VoWiFi call, or what QoS treatment
the MNO application requires.
3.2. Why Existing SIM-Based EAP Methods Do Not Apply
EAP-SIM [RFC4186], EAP-AKA [RFC4187], EAP-AKA' [RFC9048], and EAP-
AKA' FS [RFC9678] all require the EAP server to query the MNO's HLR,
HSS, or UDM during each authentication event.
MNO authentication backends hold Ki for every subscriber and are
reachable only via carrier-grade roaming interfaces -- Wx/SWx
(Diameter), Gr (MAP/SS7), or 5G SBI N13/N8 -- operating over GRX/IPX
interconnects under bilateral operator agreements. No MNO exposes
these interfaces to enterprise networks. This is a fundamental
security boundary, not a commercial negotiation issue.
Gupta Expires 21 January 2027 [Page 7]
Internet-Draft EAP-WSIM July 2026
Consequently, while EAP-SIM, EAP-AKA, EAP-AKA', and EAP-AKA' FS are
technically capable of authenticating MNO devices on enterprise Wi-
Fi, they are not deployable in practice: the MNO backend interface
they require is structurally unavailable to enterprise networks, and
no MNO will open it. The protocol capability exists; the operational
path does not.
3.3. Why Alternative Approaches Are Insufficient
3.3.1. Hosted MNO RADIUS Services
Some MNOs offer managed RADIUS services where the MNO hosts the
authentication server within their own perimeter. This introduces:
* Data sovereignty constraints: every authentication event is logged
at the MNO, unacceptable for regulated industries.
* Availability dependency: enterprise Wi-Fi depends on MNO RADIUS
availability; outages propagate to campus Wi-Fi.
* Multi-MNO complexity: separate commercial agreements and
configurations are required per MNO.
* Fast BSS transition is still unavailable: PMK-R1 pre-positioning
at target APs requires a local R0 Key Holder. With a hosted
proxy, MSK is produced at the MNO; there is no local entity to
derive and distribute PMK-R1. Every AP crossing during a VoWiFi
call still requires a full MNO round-trip (1,800-2,900 ms).
3.3.2. Enterprise 802.11r with EAP-TLS
Deploying 802.11r with EAP-TLS and enterprise certificates achieves
fast handoff but:
* Requires PKI enrollment for every MNO device including unmanaged
visitors -- a significant burden for devices the enterprise does
not own. The WSIM-Card credential eliminates this.
* Solves handoff latency only. The enterprise still cannot identify
VoWiFi flows, apply WMM AC_VO per MNO subscriber, or enforce per-
device policy. Fast handoff without application layer integration
is a partial solution that does not justify the PKI deployment
cost.
* Device-side 802.11r support is inconsistent across chipsets, OEMs,
and OS versions. EAP-WSIM resolves this at the infrastructure
layer: the WSIM-AS derives and pre-positions PMK-R1 regardless of
device-side 802.11r implementation quality.
Gupta Expires 21 January 2027 [Page 8]
Internet-Draft EAP-WSIM July 2026
3.3.3. DSCP-Based QoS Without Authentication
DSCP EF markings are self-asserted by devices; any device can mark
all traffic DSCP EF. Without authenticated subscriber identity, the
enterprise cannot distinguish legitimate VoWiFi flows from priority
abuse. EAP-WSIM anchors QoS to verified MNO subscriber identity,
making DSCP-based prioritization trustworthy.
3.4. The MNO Device Wi-Fi Compliance Gap
MNOs enforce strict compliance on 4G/5G stack implementations via
type approval. No equivalent enforcement exists for Wi-Fi. This is
why 802.11r support varies across device vendors. EAP-WSIM creates
this enforcement mechanism: because authentication uses the MNO-
provisioned WSIM-Card, MNOs can make correct 802.11r implementation a
condition of device certification -- the same way they enforce
cellular stack compliance today.
4. EAP-WSIM Overview
4.1. Design Goals
REQ-1: Offline Mutual Authentication. Authentication MUST complete
without MNO HLR, HSS, UDM, or AuC contact.
REQ-2: Zero-Touch Onboarding. MUST use existing WSIM-Card credential
(IMSI + MILENAGE). No enterprise certificate enrollment or
captive portal required.
REQ-3: No Per-Subscriber Provisioning at WSIM-AS. WSIM-AS MUST
automatically support any subscriber whose IMSI maps to a
provisioned MASTER KEY, without per-subscriber pre- loading.
REQ-4: Forward Secrecy. Compromise of long-term MASTER KEY MUST NOT
expose past session keys.
REQ-5: Post-Quantum Forward Secrecy. a) Grover resistance: symmetric
primitives MUST provide at least 128-bit post-quantum security
margin. b) Shor resistance: key encapsulation MUST NOT rely on
ECDLP. ML-KEM-768 [FIPS203] is used as the ECDH P-256
replacement. This requirement is consistent with NIST post-
quantum guidance [FIPS203] and EMU WG PQC work
[I-D.ietf-emu-pqc-eapaka] [I-D.ietf-emu-hybrid-pqc-eapaka].
REQ-6: 802.11r Fast BSS Transition. PMK-R0/R1 derivation and AP
distribution MUST occur within the enterprise without MNO backend
involvement for any roam.
Gupta Expires 21 January 2027 [Page 9]
Internet-Draft EAP-WSIM July 2026
REQ-7: MNO Subscriber Identity at 802.11 Association. Per-device MNO
subscriber identity MUST be surfaced to the enterprise at 802.11
association for QoS, policy, and classification.
REQ-8: No Device-Side Changes. MUST NOT require modifications to the
MNO device Wi-Fi stack, SIM card, or firmware beyond standard EAP-
AKA' peer behaviour.
REQ-9: Rogue Authenticator Prevention. WSIM-Card MUST be able to
verify it is authenticating to an MNO-approved WSIM-AS.
REQ-10: Security Hardware Confinement. All MASTER KEY material and
per-subscriber K_sub derivation MUST be fully contained within
WSIM-AS tamper-resistant hardware. Key material MUST NOT be
accessible to any software layer or external interface.
REQ-11: MASTER KEY Compartmentalization. MASTER KEY material
provisioned to a WSIM-AS instance MUST be scoped to the single
SSID/venue deployment for which it was provisioned. It MUST NOT
function as, and MUST NOT be usable to derive, key material
applicable to any other deployment or to the MNO's subscriber base
at large.
REQ-12: MASTER KEY Revocability. The MNO MUST be able to revoke and
replace MASTER KEY material at a WSIM-AS instance without
affecting any other deployment, using the same secure
provisioning/update mechanism already used for SIM and eSIM
application key management.
4.2. System Components
WSIM-Card (on MNO device): The device's existing MNO SIM card.
Performs MILENAGE and ML-KEM encapsulation. No new hardware
required.
WSIM-Authentication Server (enterprise Wi-Fi infrastructure): Provisioned
out-of-band by MNO with MASTER KEY material in tamper-resistant
security hardware. Derives K_sub on-demand from MASTER KEY + IMSI
within hardware. Generates RAND/AUTN, performs ML-KEM key
operations, verifies RES, derives MSK/EMSK and PMK-R0/R1, delivers
WMM QoS policy to APs.
Enterprise Access Points: Standard 802.11r-capable APs. Receive
PMK-R1 and WMM QoS policy from WSIM-AS acting as R0KH. Execute FT
protocol.
4.3. Protocol Flow
Gupta Expires 21 January 2027 [Page 10]
Internet-Draft EAP-WSIM July 2026
Device (WSIM-Card) WSIM-AS Enterprise AP
| | |
|<--- EAP-Request/Identity ----| |
|----- EAP-Response/Identity ->| |
| (IMSI or pseudonym) | |
| | |
| (Security HW: K_sub = KDF(MASTER_KEY, IMSI))
| (Generate ML-KEM keypair -- ek,dk) |
| (MILENAGE(K_sub,SQN)->RAND,AUTN,XRES,CK,IK)
| | |
|<-------- WSIM-Start ---------| |
| AT_RAND, AT_AUTN, | |
| AT_ML_KEM_PK (ek), | |
| AT_NONCE_S, AT_COUNTER, | |
| AT_MAC | |
| | |
| (Verify AUTN using Ki) | |
| (Compute RES, CK, IK) | |
| (ML-KEM.Encaps(ek)->ct,K_kem)| |
| (Derive K_session, MSK, EMSK)| |
| | |
|------- WSIM-Challenge ------>| |
| AT_RES, AT_ML_KEM_CT (ct), | |
| AT_NONCE_P, AT_MAC_PEER | |
| | |
| (Verify RES == XRES) |
| (ML-KEM.Decaps(dk,ct) -> K_kem) |
| (Derive K_session, MSK, EMSK) |
| | |
|<------- WSIM-Confirm --------| |
| AT_MAC_CONFIRM | |
| | |
| (Verify AT_MAC_CONFIRM) | |
| | |
|------- WSIM-Complete ------->| |
| | |
| (PMK = MSK[0:32]) | |
| (Derive PMK-R0, PMK-R1) |
| |--- PMK-R1 push --->|
| | WMM AC_VO policy|
|<--- EAP-Success -------------| |
| | |
|<=========== IEEE 802.11r Fast BSS Transition ====>|
| (sub-50ms, no MNO contact) |
Figure 2
Gupta Expires 21 January 2027 [Page 11]
Internet-Draft EAP-WSIM July 2026
4.4. Trust Model
The WSIM-AS is not enterprise-built software with an interface to the
MNO. It is MNO-provisioned hardware deployed at the enterprise edge.
The trust model is as follows.
The MNO operates a MASTER KEY that is the root of all subscriber SIM
provisioning -- the same root from which per-subscriber Ki values are
derived when SIM cards are manufactured. The MNO provisions MASTER
KEY material into the WSIM-AS tamper-resistant security hardware out-
of-band, using the same key provisioning infrastructure used for SIM
card personalization. This is a one-time per-venue event,
operationally equivalent to how MNOs provision eSIM profiles via GSMA
Remote SIM Provisioning (SGP.02) [SGP02].
Once provisioned, the WSIM-AS hardware derives per-subscriber
MILENAGE key material on-demand for any subscriber of that MNO, using
only the subscriber's IMSI:
K_sub = KDF(MASTER_KEY, IMSI)
Figure 3
This derivation is identical in structure to how the MNO's SIM
personalization factory derives Ki for each SIM card from the
operator master key. The WSIM-AS is performing the same operation,
at the enterprise edge, at authentication time rather than at SIM
manufacturing time.
The enterprise never has access to the MASTER KEY or to any
subscriber key material. Key material is confined to the WSIM-AS
tamper-resistant hardware and is accessible only to the MNO's
provisioning process. This is the same trust model as an HSM in
payment systems: the enterprise deploys the hardware; the MNO
controls the keys inside it.
The enterprise's role is to deploy and operate the WSIM-AS hardware
within its Wi-Fi infrastructure, in the same way it deploys and
operates RADIUS servers today. The MNO's role is to provision MASTER
KEY material to that hardware and to certify the hardware as meeting
its security requirements. Neither party needs to trust the other
with key material: the MNO trusts the hardware's tamper resistance;
the enterprise trusts the MNO to have provisioned it correctly.
Gupta Expires 21 January 2027 [Page 12]
Internet-Draft EAP-WSIM July 2026
4.5. Deployability Considerations
EAP-WSIM on the device (WSIM-Card) side is not a clean-sheet EAP
implementation. It is EAP-AKA' [RFC9048] with one additional step:
ML-KEM-768 encapsulation using a server-provided public key. The
MILENAGE computation on the SIM card is entirely unchanged.
Apple iOS, Android, and all major platforms already implement EAP-
AKA' for VoWiFi via the ePDG path. The wpa_supplicant EAP-AKA' peer
implementation already exists on Linux-based platforms. EAP-WSIM
requires adding ML-KEM encapsulation in the WSIM-Challenge response
path -- a bounded, well-defined delta on an existing implementation.
MNOs drive device vendor compliance through type approval and device
certification -- they enforce 4G/5G stack compliance this way today,
including specific EAP-AKA' behaviour for VoWiFi. EAP-WSIM gives
MNOs the same enforcement mechanism for enterprise Wi-Fi: device
vendors seeking MNO certification can be required to implement EAP-
WSIM correctly as a certification condition. EAP-SIM and EAP-AKA
reached universal deployment not through open-market adoption but
through MNO certification requirements, and the same path is
available to EAP-WSIM.
4.6. Multi-MNO Deployment
Each MNO's MASTER KEY material is provisioned into a separate WSIM-AS
instance, indexed to that MNO's MCC/MNC. A WSIM-AS instance
provisioned by one MNO authenticates only that MNO's subscribers; it
holds no key material for, and cannot authenticate subscribers of,
any other MNO.
A venue served by multiple MNOs runs one WSIM-AS instance per MNO,
side by side, in the same way a venue today may operate multiple
SSIDs for different purposes. This does not introduce a new trust
relationship or negotiation between MNOs: each MNO's WSIM-AS instance
is independent, and no MNO's WSIM-AS instance is trusted, or needs to
be trusted, by another MNO.
5. WSIM-AS MASTER KEY Architecture
5.1. MASTER KEY Provisioning
The MNO provisions MASTER KEY material to the WSIM-AS out-of-band
using secure channels equivalent to those used for SIM card
personalization. MASTER KEY is loaded directly into the WSIM-AS
tamper-resistant security hardware and is never accessible outside
that hardware boundary.
Gupta Expires 21 January 2027 [Page 13]
Internet-Draft EAP-WSIM July 2026
MASTER KEY indexing supports: o Multiple MNOs: distinct
MASTER_KEY[index] per operator. o Key versioning: rotation by
provisioning MASTER_KEY[index+1]. Subscribers automatically use
the new derivation path at next authentication. No subscriber SIM
changes required.
5.2. Per-Subscriber Key Derivation
When a device presents its IMSI, the WSIM-AS security hardware
derives per-subscriber MILENAGE key material on-demand:
K_sub = KDF(MASTER_KEY[index], IMSI)
Figure 4
where KDF is an MNO-defined derivation function applied entirely
within the tamper-resistant hardware boundary. K_sub is functionally
equivalent to Ki on the subscriber's WSIM-Card.
Properties: o Any subscriber whose IMSI maps to a provisioned MASTER
KEY is automatically supported. No per-subscriber provisioning
step.
* K_sub is derived, used for MILENAGE computation, and discarded
within the hardware boundary -- never exported.
* K_sub derivation is deterministic: same result across WSIM-AS
restarts without persistent subscriber state.
5.3. Security Hardware Boundary
All MASTER KEY material, K_sub derivation, MILENAGE computation, and
ML-KEM operations MUST occur within the WSIM-AS tamper-resistant
security hardware (REQ-10). The hardware MUST resist physical
tampering, side-channel analysis, and fault injection at a level
equivalent to FIPS 140-3 Level 3 or higher. Software or network
compromise of the WSIM-AS host system MUST NOT expose MASTER KEY or
K_sub values.
5.4. MASTER KEY Scope and Revocation
MASTER KEY material provisioned to a WSIM-AS instance is scoped to
the SSID/venue deployment for which it was provisioned (REQ-11). It
is not a general-purpose root from which subscriber Ki values across
the MNO's full subscriber base can be derived outside that
deployment: the WSIM-AS security hardware only accepts MASTER KEY
material derived for its specific SSID/venue. Compromise of a single
WSIM-AS instance is therefore bounded to that deployment and does not
Gupta Expires 21 January 2027 [Page 14]
Internet-Draft EAP-WSIM July 2026
expose subscriber key material at other venues or at the MNO.
Revocation uses an indexed structure of 25 MASTER KEY slots per WSIM-
AS instance. A compromised or retired slot is deprecated by updating
the applet on the WSIM-AS security hardware (MASTER-MNO-SIM-Card /
Key-HW), performed the same way the MNO updates applets on a
subscriber's SIM card today, satisfying REQ-12.
All maintenance of the WSIM-AS security hardware -- initial
provisioning, key rotation, and slot revocation -- is performed
exclusively by the MNO. The enterprise has no ability to read,
modify, or update MASTER KEY material; its role is limited to hosting
and operating the WSIM-AS hardware within its Wi-Fi infrastructure,
per Section 4.4.
Deprecating a slot does not require re-provisioning the entire WSIM-
AS instance. The MNO issues an applet update marking the affected
slot inactive and, where replacement is required, provisions a new
slot. Subscribers are transparently migrated to the active slot at
next authentication, consistent with the key versioning behaviour
described in Section 5.1.
6. The MILENAGE-ML-KEM-FWD Construction
6.1. Overview
MILENAGE-ML-KEM-FWD uses ML-KEM-768 [FIPS203] key encapsulation for
post-quantum forward secrecy in place of ECDH P-256. MILENAGE mutual
authentication, WSIM-SLOT-SELECT key management, and MSK/EMSK
derivation structure follow the same design as prior SIM-based EAP
methods.
Two tracks run in parallel:
Track A (MILENAGE): WSIM-AS computes MILENAGE(K_sub, RAND) to obtain
XRES, CK, IK; constructs AUTN. WSIM-Card verifies AUTN
(authenticating WSIM-AS) and computes RES, CK, IK. WSIM-AS
verifies RES == XRES (authenticating WSIM-Card).
Track B (ML-KEM): WSIM-AS generates a fresh ML-KEM-768 keypair (ek,
dk) per session and sends ek to the WSIM-Card. WSIM-Card
encapsulates: (ct, K_kem) <- ML-KEM.Encaps(ek). WSIM-AS
decapsulates: K_kem <- ML-KEM.Decaps(dk, ct). Both parties now
share K_kem, which was never transmitted.
Combination: Session key material derives from (K_kem, CK, IK, NONCE_S,
NONCE_P) via HKDF-SHA-256. Compromise of MASTER KEY alone cannot
recompute K_kem (forward secrecy via ML-KEM).
Gupta Expires 21 January 2027 [Page 15]
Internet-Draft EAP-WSIM July 2026
WSIM-SLOT-SELECT: Both WSIM-AS and WSIM-Card independently determine
the active key slot index using a non-reversible, IMSI-bound,
Time-of-Day algorithm:
data = IMSI(8B) || year(2B) || month(1B) ||
day(1B) || hour(1B) || label(12B)
H = HMAC-SHA-256(K_SELECT, data)
slot_base = ((H[0] << 8) | H[1]) mod 14
index = first ACTIVE slot in (slot_base + offset) mod 14
for offset in 0..13; slot 14 = emergency reserve
Figure 5
K_SELECT is held within the security hardware boundary and is
never exported. The algorithm is non-reversible: slot_index
cannot be used to recover IMSI, and different IMSIs produce
independent slot sequences. Slot changes every hour, binding key
selection to both subscriber identity and time-of-day. Full
specification is in [I-D.gupta-emu-wsim-key-select].
6.2. Inputs
index MASTER KEY index selected by WSIM-AS
K_sub Per-subscriber MILENAGE key derived within security HW:
K_sub = KDF(MASTER_KEY[index], IMSI)
RAND 128-bit random challenge (fresh per session, WSIM-AS)
(ek, dk) ML-KEM-768 keypair (fresh per session, WSIM-AS)
NONCE_S 128-bit server nonce (fresh per session)
NONCE_P 128-bit peer nonce (fresh per session)
SQN 48-bit MILENAGE sequence number
AMF 16-bit Authentication Management Field
Figure 6
6.3. WSIM-SLOT-SELECT Algorithm
Both WSIM-AS and WSIM-Card independently execute WSIM-SLOT-SELECT to
determine the active key slot index without communication. The
algorithm is non-reversible and IMSI-bound, ensuring two devices with
different IMSIs use different slots even at the same time.
Gupta Expires 21 January 2027 [Page 16]
Internet-Draft EAP-WSIM July 2026
Inputs:
IMSI 8-byte BCD-encoded subscriber identity
TOD_block year(2B) || month(1B) || day(1B) || hour(1B) = 5 bytes
K_SELECT 32-byte selection key (on-card, NEVER READ)
label b'WSIM-SLOT-V2' (12 bytes, fixed)
Steps (executed within security hardware, result never exported):
data = IMSI || TOD_block || label (25 bytes)
H = HMAC-SHA-256(K_SELECT, data)
slot_raw = (H[0] << 8) | H[1]
slot_base = slot_raw mod 14
for offset in 0..13:
idx = (slot_base + offset) mod 14
if SLOT_STATUS[idx] == ACTIVE: return idx
return 14 # emergency reserve slot
Figure 7
The algorithm changes the active slot every hour (TOD includes hour)
with per-IMSI variation. Compromising one device's slot sequence
reveals nothing about other devices. AT_CLOCK_OFFSET (TLV 0x1A in
AT_CLOCK_OFFSET (Section 7.4) accommodates clock skew up to +/- 1
hour between WSIM-Card and WSIM-AS.
Full specification: [I-D.gupta-emu-wsim-key-select].
6.4. Construction Steps
WSIM-AS:
a. Receive IMSI from WSIM-Card EAP-Response/Identity
(b) Security HW: derive K_sub = KDF(MASTER_KEY[index], IMSI)
(c) Security HW: WSIM-SLOT-SELECT(IMSI, ...) -> active slot
(d) Security HW: MILENAGE(K_sub, RAND):
XRES = f2(K_sub, RAND)
CK = f3(K_sub, RAND)
IK = f4(K_sub, RAND)
AK = f5(K_sub, RAND)
(e) AUTN = (SQN XOR AK) || AMF || f1(K_sub, SQN, RAND, AMF)
(f) Security HW: (ek, dk) <- ML-KEM.KeyGen()
(g) Generate NONCE_S
(h) K_mac_start = HMAC-SHA-256(K_sub, "WSIM-START-MAC-v1" || RAND)
(i) Send WSIM-Start: RAND, AUTN, AT_ML_KEM_PK(ek), NONCE_S,
AT_COUNTER, AT_MAC
Figure 8
Gupta Expires 21 January 2027 [Page 17]
Internet-Draft EAP-WSIM July 2026
WSIM-Card (upon receiving WSIM-Start):
(j) WSIM-SLOT-SELECT independently -> active slot
(k) Verify AT_MAC using K_mac_start
(l) Verify AUTN using Ki:
AK = f5(Ki, RAND)
SQN = AUTN[0:6] XOR AK
MAC_A = f1(Ki, SQN, RAND, AUTN[6:8])
Verify MAC_A == AUTN[8:16] -- WSIM-AS authenticated
(m) Compute RES = f2(Ki, RAND); CK = f3; IK = f4
(n) Generate NONCE_P
(o) (ct, K_kem) <- ML-KEM.Encaps(ek)
(p) Derive K_session per Section 6.5
(q) Send WSIM-Challenge: AT_RES, AT_ML_KEM_CT(ct),
AT_NONCE_P, AT_MAC_PEER
WSIM-AS (upon receiving WSIM-Challenge):
(r) Verify RES == XRES -- WSIM-Card authenticated
(s) Security HW: K_kem <- ML-KEM.Decaps(dk, ct); discard dk
(t) Derive same K_session
Figure 9
6.5. Output Key Material
K_kem is derived from the ephemeral ML-KEM keypair (ek, dk). dk is
discarded immediately after decapsulation.
IKM = K_kem || CK || IK (32 + 16 + 16 = 64 bytes)
salt = NONCE_S || NONCE_P (16 + 16 = 32 bytes)
info = "MILENAGE-ML-KEM-FWD-v1" (23 bytes, UTF-8)
L = 160 bytes
OKM = HKDF-SHA-256(IKM, salt, info, L)
OKM partitioned as:
OKM[0:64] MSK (64 bytes, per [RFC5247])
OKM[64:128] EMSK (64 bytes, per [RFC5247])
OKM[128:144] K_auth (16 bytes, MAC key for WSIM-Challenge)
OKM[144:160] K_confirm (16 bytes, MAC key for WSIM-Confirm)
Figure 10
Note: K_mac_start is derived separately from K_sub (Section 6.4, step
h) and does not depend on K_kem. This protects WSIM-Start integrity
before the ML-KEM exchange completes.
6.6. Security Properties
Gupta Expires 21 January 2027 [Page 18]
Internet-Draft EAP-WSIM July 2026
Mutual Authentication: WSIM-AS authenticated to WSIM-Card via AUTN
verification (step l). WSIM-Card authenticated to WSIM-AS via
RES == XRES (step r).
Post-Quantum Forward Secrecy: K_kem is derived from the ephemeral
ML-KEM keypair discarded after decapsulation. Compromise of
MASTER KEY at any future time does not expose K_kem, K_session,
MSK, or past session key material. ML-KEM-768 provides security
against Shor's algorithm; its hardness is based on MLWE.
Harvest-Now-Decrypt-Later (HNDL): Structured capture of EAP-WSIM
sessions provides no future decryption capability; K_kem is
ephemeral and the HNDL attack is structurally prevented.
Key Binding: IKM includes K_kem (ML-KEM) and CK||IK (MILENAGE).
Neither component alone determines OKM.
IMSI-Bound Key Isolation: K_sub is uniquely derived per subscriber
and per MASTER KEY index. Compromise of one subscriber's K_sub
does not affect others.
Session Independence: Fresh RAND, fresh ML-KEM keypair, fresh
NONCE_S and NONCE_P per session ensure distinct OKM values.
Figure 11
6.7. ML-KEM-768 Rationale
ML-KEM-768 (FIPS 203) is selected as the key encapsulation following
reasons:
* NIST standardized: FIPS 203 (August 2024).
* Security Category 3: conjectured equivalent to AES-192, providing
margin above the 128-bit post-quantum minimum (REQ-5).
* IND-CCA2 security under adaptive chosen-ciphertext attack.
* Shor's algorithm resistance: ML-KEM hardness is based on MLWE,
with no known polynomial-time quantum algorithm.
* WSIM-Card compatibility: WSIM-Card performs only ML-KEM
encapsulation (lightweight). MILENAGE operations are unchanged.
No modification to deployed SIM cards required.
* Sizes: ek is 1184 bytes; ct is 1088 bytes. Carried in new TLV
attributes using standard EAP fragmentation.
Gupta Expires 21 January 2027 [Page 19]
Internet-Draft EAP-WSIM July 2026
ECDH P-256 MUST NOT be used in implementations of this document.
Shor's algorithm solves ECDLP in polynomial time on a CRQC,
completely breaking forward secrecy. Key length increase cannot
mitigate this; the algorithm must be replaced.
7. EAP-WSIM Protocol
7.1. Pre-Association Phase
Before the EAP exchange, a device MAY perform a pre-association phase
to obtain and validate the WSIM-AS operator certificate. This
provides explicit rogue authenticator prevention (REQ-9) before the
MILENAGE exchange begins. The phase is OPTIONAL; if omitted, WSIM-AS
authenticity is established implicitly via AUTN verification in WSIM-
Start.
Device (WSIM-Card, Unassociated) WSIM-AS
| |
|------- WSIM-Announce -------------->|
| outer_identity (NAI), |
| AT_REQUEST_CERT |
| |
| (Retrieve operator cert) |
| (Sign with WSIM-AS key) |
| |
|<------ WSIM-Identity ---------------|
| AT_SERVER_CERT, |
| AT_CERT_SIG, |
| AT_WSIM_ID |
| |
| (Verify AT_CERT_SIG against |
| MNO-provisioned trust anchor) |
| (On failure: abort, log BAD-AS) |
| |
~~~~ EAP exchange (Section 4.3) follows ~~~~
Figure 12
7.2. EAP Exchange Overview
EAP-WSIM uses EAP type 0xFE (Expanded Type [RFC3748]) with a vendor-
specific method type pending IANA assignment (Section 13).
Following pre-association (or directly in constrained deployments),
the four-round exchange of Section 4.3 proceeds.
7.3. Message Header
Gupta Expires 21 January 2027 [Page 20]
Internet-Draft EAP-WSIM July 2026
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xFE | Vendor-Id (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type = 0x00000001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13
Code: 1 = Request (WSIM-AS->WSIM-Card); 2 = Response (reverse)
Subtype: 0x01 WSIM-Start 0x02 WSIM-Challenge 0x03 WSIM-Confirm
0x04 WSIM-Complete 0x05 WSIM-Error
7.4. Attribute Encoding
All attributes use TLV encoding: Type(1B) | Length(1B) | Value.
Type Name Size Description
---- ----------------- ------- --------------------------------
0x10 AT_RAND 16 B MILENAGE RAND challenge
0x11 AT_AUTN 16 B MILENAGE AUTN token
0x14 AT_NONCE_S 16 B Server session nonce
0x15 AT_NONCE_P 16 B Peer session nonce
0x16 AT_RES 16 B MILENAGE RES (f2 output)
0x17 AT_MAC 32 B HMAC-SHA-256(K_mac_start, msg)
0x18 AT_MAC_PEER 32 B HMAC-SHA-256(K_auth, msg)
0x19 AT_MAC_CONFIRM 32 B HMAC-SHA-256(K_confirm, msg)
0x1A AT_COUNTER 4 B Anti-replay counter
0x1B AT_ERROR_CODE 2 B Error code (WSIM-Error only)
0x1C AT_REQUEST_CERT 0 B Pre-assoc: request server cert
0x1D AT_SERVER_CERT var Pre-assoc: DER-encoded X.509
0x1E AT_CERT_SIG 64 B Pre-assoc: ECDSA-P256 signature
0x1F AT_WSIM_ID var Pre-assoc: WSIM instance ID
ML-KEM attributes (replacing prior ECDH attributes):
Type Name Size Description
---- ----------------- ------- --------------------------------
0x20 AT_ML_KEM_PK 1184 B ML-KEM-768 encaps key (ek)
0x21 AT_ML_KEM_CT 1088 B ML-KEM-768 ciphertext (ct)
0x22 AT_MASTER_KEY_IDX 2 B MASTER KEY index used
0x23 AT_WSIM_VERSION 2 B Protocol version (0x0101 = v1.1)
Figure 14
Gupta Expires 21 January 2027 [Page 21]
Internet-Draft EAP-WSIM July 2026
The following attribute types are reserved and MUST NOT be used: 0x12
AT_ECDH_SERVER (replaced by AT_ML_KEM_PK) 0x13 AT_ECDH_PEER (replaced
by AT_ML_KEM_CT)
7.5. WSIM-Start (Subtype 0x01, WSIM-AS to WSIM-Card)
Mandatory: AT_RAND, AT_AUTN, AT_ML_KEM_PK, AT_NONCE_S, AT_COUNTER,
AT_MAC
AT_MAC uses K_mac_start = HMAC-SHA-256(K_sub, "WSIM-START-MAC-v1" ||
RAND), derived before session keys are established.
7.6. WSIM-Challenge (Subtype 0x02, WSIM-Card to WSIM-AS)
Mandatory: AT_RES, AT_ML_KEM_CT, AT_NONCE_P, AT_MAC_PEER
AT_MAC_PEER uses K_auth (OKM[128:144]).
WSIM-Card MUST:
1. Verify AT_MAC in WSIM-Start using K_mac_start.
2. Verify AUTN; on failure send WSIM-Error 0x0002.
3. Complete key derivation per Section 6.5.
4. Transmit WSIM-Challenge.
7.7. WSIM-Confirm (Subtype 0x03, WSIM-AS to WSIM-Card)
Mandatory: AT_MAC_CONFIRM
AT_MAC_CONFIRM = HMAC-SHA-256(
key = K_confirm (OKM[144:160]),
data = "WSIM-CONFIRM-v1" || AT_RAND || AT_NONCE_S || AT_NONCE_P
)
Figure 15
WSIM-AS MUST verify RES == XRES before sending WSIM-Confirm. If RES
!= XRES, send WSIM-Error 0x0003.
7.8. WSIM-Complete (Subtype 0x04, WSIM-Card to WSIM-AS)
No mandatory payload. Signals WSIM-Card has verified AT_MAC_CONFIRM.
WSIM-AS responds with EAP-Success.
7.9. WSIM-Error (Subtype 0x05)
Gupta Expires 21 January 2027 [Page 22]
Internet-Draft EAP-WSIM July 2026
Code Meaning
------ -------------------------------------------------------
0x0001 UNSUPPORTED_METHOD Malformed or unsupported WSIM-Start
0x0002 AUTN_FAILURE WSIM-Card could not verify AUTN
0x0003 RES_FAILURE WSIM-AS: RES != XRES
0x0004 CONFIRM_FAILURE WSIM-Card: AT_MAC_CONFIRM invalid
0x0005 MAC_FAILURE AT_MAC or AT_MAC_PEER failed
0x0006 REPLAY_DETECTED AT_COUNTER out of acceptable range
0x0007 GENERAL_FAILURE Unspecified failure
0x0008 SLOT_MISMATCH Slot selection mismatch > 1 hour
Figure 16
7.10. Anti-Replay
AT_COUNTER is a monotonically increasing 32-bit counter per (WSIM-AS,
WSIM-Card) pair. WSIM-Card MUST verify it is strictly greater than
the last accepted value.
SQN in AUTN provides independent MILENAGE-layer anti-replay. Session
nonces (AT_NONCE_S, AT_NONCE_P) ensure session uniqueness.
7.11. Identity Privacy
EAP-WSIM supports three identity types, consistent with EAP-AKA'
[RFC9048]:
Permanent identity: The subscriber's IMSI in NAI format: "0" ||
IMSI || "@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org" Transmitted only
when no pseudonym or fast re-authentication identity is available,
or when the WSIM-AS requests it via AT_FULLAUTH_ID_REQ.
Pseudonym identity: A temporary identity assigned by the WSIM-AS at
the end of a successful authentication, delivered in EAP-Success
via AT_NEXT_PSEUDONYM. The WSIM-Card SHOULD use this identity in
the next AT_ANY_ID_REQ exchange to avoid exposing the permanent
IMSI. The WSIM-AS MUST be able to map the pseudonym back to the
IMSI within its security hardware boundary.
Fast re-authentication identity: Assigned alongside the pseudonym
via AT_NEXT_REAUTH_ID. Used for session resumption without a full
four-round exchange, as specified in
[I-D.gupta-emu-wsim-key-select]. If fast re-authentication fails,
the WSIM-Card MUST fall back to full authentication.
Gupta Expires 21 January 2027 [Page 23]
Internet-Draft EAP-WSIM July 2026
AT_ANY_ID_REQ in WSIM-Start signals that the WSIM-AS will accept any
of the three identity types. AT_FULLAUTH_ID_REQ signals that a full
authentication with permanent or pseudonym identity is required (fast
re-authentication not accepted).
The outer EAP identity (EAP-Response/Identity) SHOULD be an anonymous
NAI ("@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org") to prevent permanent
identity exposure at the EAP layer before the WSIM exchange begins.
8. MSK, EMSK, and 802.11r Integration
8.1. EAP Session-ID
EAP methods MUST define Session-ID derivation per [RFC5247]
Section 1.4. The EAP-WSIM Session-ID is:
Session-ID = EAP-Type-Code || NONCE_S || NONCE_P
Figure 17
where EAP-Type-Code is the single-byte EAP method type assigned by
IANA (Section 13), NONCE_S is the 16-byte server nonce from WSIM-
Start (AT_NONCE_S), and NONCE_P is the 16-byte peer nonce from WSIM-
Challenge (AT_NONCE_P). The Session-ID is 33 bytes.
The Session-ID is available after WSIM-Challenge is transmitted and
MUST be exported to the EAP layer on EAP-Success alongside the MSK.
8.2. MSK, EMSK, and Key Export
MSK (OKM[0:64]) and EMSK (OKM[64:128]) are per [RFC5247]. MSK is
exported to the lower layer on EAP-Success.
8.3. IEEE 802.11r Key Hierarchy
For IEEE 802.11r fast BSS transition:
PMK = MSK[0:32]
PMK-R0 = KDF(PMK, "FT-R0", R0KH-ID || S0KH-ID)
PMK-R1 = KDF(PMK-R0, "FT-R1", R1KH-ID || S1KH-ID)
Figure 18
The WSIM-AS acts as R0KH per [IEEE80211r] and pre-positions PMK-R1 at
each AP in the enterprise mobility domain before the device roams,
enabling FT protocol exchange at the target AP in under 50 ms without
any EAP re-exchange or MNO backend contact.
Gupta Expires 21 January 2027 [Page 24]
Internet-Draft EAP-WSIM July 2026
WMM QoS policy is delivered alongside PMK-R1, keyed to the
authenticated subscriber IMSI. The AP applies WMM AC_VO to traffic
from the authenticated device. EMSK MUST NOT be exported.
9. Relationship to Existing EAP Methods
9.1. EAP-AKA Evolution Chain
EAP-WSIM is an evolutionary enhancement of EAP-AKA', not a new
protocol. The evolution chain:
EAP-AKA [RFC4187]: MILENAGE mutual authentication. SHA-1 KDF. No
forward secrecy. Requires live MNO HLR/HSS.
EAP-AKA' [RFC9048]: SHA-256 KDF. Network name binding
(AT_KDF_INPUT). Non-3GPP access (TWAN, ePDG). Requires live MNO
HSS/UDM.
EAP-AKA' FS [RFC9678]: Ephemeral ECDH P-256 forward secrecy. ECDH
P-256 is broken by Shor's algorithm on a CRQC. Requires live MNO
HSS/UDM.
EAP-WSIM [This Document]: Removes MNO backend from active
authentication loop. WSIM-AS MASTER KEY enables on-demand per-
subscriber key derivation. ML-KEM-768 for post-quantum forward
secrecy. 802.11r PMK-R0/R1 at enterprise edge. MNO subscriber
identity at 802.11 layer.
The analogy to 4G/5G evolution: 4G provided device authentication; 5G
added mutual authentication without replacing MILENAGE. EAP-WSIM
adds offline operation and post-quantum security without replacing
MILENAGE.
9.2. Relationship to RFC 9678 (EAP-AKA' FS)
RFC 9678 [RFC9678] and EAP-WSIM address complementary deployment
scenarios. The key architectural distinction: RFC 9678 requires a
live query to the MNO HSS/UDM for each authentication event; EAP-WSIM
requires no MNO backend contact.
RFC 9678 and EAP-WSIM are complementary. RFC 9678 is appropriate
when MNO infrastructure is available. EAP-WSIM is appropriate when
offline operation is required or MNO backend connectivity is not
available.
Gupta Expires 21 January 2027 [Page 25]
Internet-Draft EAP-WSIM July 2026
9.3. Relationship to EMU WG PQC Work
[I-D.ietf-emu-pqc-eapaka] and [I-D.ietf-emu-hybrid-pqc-eapaka] add
post-quantum security to EAP-AKA' FS for MNO-connected deployments.
Both require a live MNO backend. EAP-WSIM addresses the
complementary case: post-quantum SIM-based authentication with no MNO
backend involvement.
The ML-KEM operation in EAP-WSIM is confined to the WSIM-AS and WSIM-
Card encapsulation step. Deployed SIM cards require no modification
to run MILENAGE; ML-KEM encapsulation is an additional step using the
server-provided ek.
9.4. Relationship to EAP-FIDO
EAP-FIDO [I-D.ietf-emu-eap-fido] targets FIDO2 hardware tokens or
platform passkeys. EAP-WSIM targets MNO-provisioned SIM credentials.
They are strictly complementary with no overlap in credential type,
deployment target, or protocol structure.
9.5. Relationship to EAP-PSK-256
EAP-PSK-256 [I-D.eap-psk-256] is a quantum-resistant update to EAP-
PSK [RFC4764] addressing Grover's algorithm via AES-256, but
explicitly provides no forward secrecy, and does not address Shor's
algorithm. EAP-WSIM addresses both via ML-KEM-768 (Shor, with
forward secrecy) and MILENAGE with appropriate key lengths (Grover).
9.6. Relationship to HOKEY WG (Handover Keying)
The IETF HOKEY Working Group [RFC5749] addressed fast
re-authentication and key distribution for EAP-based handoff
scenarios. HOKEY's ERX
(EAP Re-authentication Protocol, [RFC5749]) and DSRK (Domain-Specific
Root Keys) provide fast re-authentication without full EAP exchanges.
EAP-WSIM is complementary to HOKEY-style approaches rather than
competing. HOKEY optimises the re-authentication exchange once a
root key exists; EAP-WSIM establishes that root key (PMK-R0) locally
at the enterprise edge using MNO SIM credentials, without MNO backend
involvement. The two can coexist: EAP-WSIM for initial
authentication
and PMK-R0 establishment; 802.11r FT or HOKEY-style mechanisms for
subsequent fast transitions.
Figure 19
Gupta Expires 21 January 2027 [Page 26]
Internet-Draft EAP-WSIM July 2026
9.7. Centralized Wi-Fi Controller Architectures
Many large enterprise Wi-Fi deployments use centralized controller
architectures (e.g., Cisco WLC, Aruba ClearPass, Juniper Mist) where
the AP control plane is managed by a central controller rather than
individual APs. In these deployments, the WSIM-AS distributes PMK-R1
to the controller, which handles AP-level session passing. This is
fully compatible with the WSIM-AS acting as R0KH: the controller is
simply the aggregation point for PMK-R1 distribution rather than
individual APs receiving it directly.
Centralized architectures may further reduce handoff latency below
the 50ms target, since the controller can pre-position session
context at the target AP before the device initiates the FT exchange.
10. Security Claims
Mutual authentication: YES. AUTN authenticates WSIM-AS; RES == XRES
authenticates WSIM-Card.
Integrity protection: YES. AT_MAC (K_mac_start), AT_MAC_PEER
(K_auth), AT_MAC_CONFIRM (K_confirm).
Replay protection: YES. AT_COUNTER + SQN in AUTN.
Confidentiality: No EAP message encryption; session keys protect
subsequent link-layer traffic.
Key derivation: YES. MSK (64 B) and EMSK (32 B) per [RFC5247] via
Section 6.4.
Key strength: >= 128-bit post-quantum (ML-KEM-768 Category 3 +
MILENAGE).
Dictionary attack resist: YES. No dictionary attack surface.
Fast reconnect: YES. IEEE 802.11r PMK-R0/R1.
Cryptographic binding: YES. AT_MAC_PEER binds ct, NONCE_P to
MILENAGE outcome via K_auth.
Session independence: YES. Ephemeral ML-KEM keypair per session; dk
discarded after decaps.
Fragmentation: YES. Standard EAP fragmentation for AT_ML_KEM_PK
(1184 B) and AT_ML_KEM_CT (1088 B).
Channel binding: YES. WSIM-AS identity via AT_AS_CERT_HASH (REQ-9).
Gupta Expires 21 January 2027 [Page 27]
Internet-Draft EAP-WSIM July 2026
11. Security Considerations
11.1. Security of MILENAGE-ML-KEM-FWD
Security rests on: (a) security of MILENAGE [TS35.205]; (b) hardness
of MLWE underlying ML-KEM-768 [FIPS203]; (c) security of HKDF-SHA-256
[RFC5869].
11.2. MASTER KEY Security
MASTER KEY MUST be stored in tamper-resistant hardware (FIPS 140-3
Level 3 or higher). MASTER KEY compromise is equivalent in impact to
compromise of the MNO's SIM personalization root key infrastructure.
Software-only storage is not permitted.
11.3. Ephemeral Key Lifecycle
The ML-KEM keypair (ek, dk) MUST be generated using a CSPRNG and dk
MUST be securely zeroized immediately after decapsulation. K_kem
MUST be zeroized after K_session derivation.
11.4. K_mac_start Security Properties
K_mac_start protects WSIM-Start integrity but not forward secrecy.
An adversary who later learns K_sub can verify a captured WSIM-Start
was genuine but cannot derive session keys (requires ML-KEM dk,
discarded). This is an acceptable trade-off; the first message must
be sent before full session keys are available.
11.5. MILENAGE AMF Field
Implementations SHOULD use a distinct AMF value for EAP-WSIM to
prevent cross-protocol attacks per [TS33.102].
11.6. Post-Quantum Security Analysis
Grover's algorithm: MILENAGE K_sub at 128 bits provides 64-bit effective
post-quantum security for the symmetric layer. MASTER KEY
derivation SHOULD use 256-bit key lengths where supported.
Shor's algorithm: ECDH P-256 is fully broken by Shor's algorithm on
a CRQC. ML-KEM-768 based on MLWE has no known polynomial-time
quantum algorithm.
HNDL: K_kem is ephemeral; dk is discarded after decapsulation. Past
sessions cannot be decrypted even with a CRQC.
Gupta Expires 21 January 2027 [Page 28]
Internet-Draft EAP-WSIM July 2026
12. Privacy Considerations
The EAP outer identity SHOULD use a pseudonym or temporary NAI.
Unlike EAP-SIM, EAP-AKA, EAP-AKA', and EAP-AKA' FS, EAP-WSIM causes
no RADIUS or Diameter requests to MNO infrastructure. There is
therefore no MNO-observable authentication event that could be used
to track subscriber activity across venues.
13. IANA Considerations
This document requests IANA to:
* Allocate a permanent EAP method type for "EAP-WSIM" in the "Method
Types" sub-registry of the EAP Numbers registry.
* Create registry "EAP-WSIM Attribute Types" with initial entries
from Section 7.4. Values 0x80-0xFF for private use; 0x00-0x7F by
Standards Action [RFC8126].
* Create registry "EAP-WSIM Error Codes" with values from
Section 7.9.
* Create registry "MILENAGE-ML-KEM-FWD Construction Versions".
Initial entry: "MILENAGE-ML-KEM-FWD-v1" (23 bytes, UTF-8).
14. Normative References
[FIPS203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
Standard", FIPS 203, August 2024.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3748] Aboba, B. and et al., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004,
<https://www.rfc-editor.org/rfc/rfc3748>.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006,
<https://www.rfc-editor.org/rfc/rfc4187>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008,
<https://www.rfc-editor.org/rfc/rfc5247>.
Gupta Expires 21 January 2027 [Page 29]
Internet-Draft EAP-WSIM July 2026
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[RFC8126] Cotton, M. and et al., "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 8126, June
2017, <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", BCP 79, RFC 8179, May 2017,
<https://www.rfc-editor.org/rfc/rfc8179>.
[RFC9048] Arkko, J. and et al., "Improved Extensible Authentication
Protocol Method for 3GPP Mobile Network Authentication and
Key Agreement (EAP-AKA')", RFC 9048, October 2021,
<https://www.rfc-editor.org/rfc/rfc9048>.
[RFC9678] Arkko, J., Norrman, K., and J. Preuss Mattsson, "Forward
Secrecy for the Extensible Authentication Protocol Method
for Authentication and Key Agreement (EAP-AKA')",
RFC 9678, March 2025,
<https://www.rfc-editor.org/rfc/rfc9678>.
[TS35.205] 3GPP, "Specification of the MILENAGE Algorithm Set", 3GPP
TS 35.205.
[IEEE80211r]
IEEE, "IEEE Std 802.11r: Fast BSS Transition", 2008.
15. Informative References
[I-D.ietf-emu-eap-fido]
Rieckers, J., "EAP-FIDO", Work in Progress, Internet-
Draft, draft-ietf-emu-eap-fido, 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-
fido>.
[I-D.ietf-emu-hybrid-pqc-eapaka]
Banerjee, A. and T. Reddy, "Hybrid Post-Quantum Key
Exchange in EAP-AKA'", Work in Progress, Internet-Draft,
draft-ietf-emu-hybrid-pqc-eapaka-01, February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-
hybrid-pqc-eapaka-01>.
Gupta Expires 21 January 2027 [Page 30]
Internet-Draft EAP-WSIM July 2026
[I-D.ietf-emu-pqc-eapaka]
Reddy, T. and A. Banerjee, "Post-Quantum Key Encapsulation
Mechanisms in EAP-AKA'", Work in Progress, Internet-Draft,
draft-ietf-emu-pqc-eapaka-02, March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-pqc-
eapaka-02>.
[I-D.eap-psk-256]
"EAP-PSK-256", Work in Progress, Internet-Draft, draft-
eap-psk-256-01, June 2026,
<https://datatracker.ietf.org/doc/html/draft-eap-psk-
256-01>.
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for Global System for Mobile
Communications (GSM) Subscriber Identity Modules (EAP-
SIM)", RFC 4186, January 2006,
<https://www.rfc-editor.org/rfc/rfc4186>.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, January 2007,
<https://www.rfc-editor.org/rfc/rfc4764>.
[TS33.102] 3GPP, "Security Architecture", 3GPP TS 33.102.
[I-D.gupta-emu-wsim-key-select]
Gupta, P., "WSIM Key Slot Selection", Work in Progress,
Internet-Draft, draft-gupta-emu-wsim-key-select-00, 2026,
<https://datatracker.ietf.org/doc/html/draft-gupta-emu-
wsim-key-select-00>.
[RFC5749] Hoeper, K. and et al., "Distribution of EAP-Based Keys for
Handover and Re-Authentication", RFC 5749, March 2010,
<https://www.rfc-editor.org/rfc/rfc5749>.
[SGP02] GSMA, "Embedded SIM Remote Provisioning Architecture",
GSMA SGP.02 Version 4.2, 2020,
<https://www.gsma.com/esim/sgp02/>.
[TPM20] Trusted Computing Group, "TPM Library Specification,
Family 1.2, Level 2, Revision 116", March 2011.
[I-D.gupta-emu-wsim-ft]
Gupta, P., "EAP-WSIM Integration with IEEE 802.11r", Work
in Progress, Internet-Draft, draft-gupta-emu-wsim-ft-00,
2026, <https://datatracker.ietf.org/doc/html/draft-gupta-
emu-wsim-ft-00>.
Gupta Expires 21 January 2027 [Page 31]
Internet-Draft EAP-WSIM July 2026
Appendix A. Changes from Previous Version
A.1 [v1.0-CHG-01] MILENAGE-ECDH-FWD -> MILENAGE-ML-KEM-FWD ECDH
P-256 ephemeral key agreement (AT_ECDH_SERVER, AT_ECDH_PEER)
replaced by ML-KEM-768 key encapsulation (AT_ML_KEM_PK,
AT_ML_KEM_CT). ECDH attributes 0x12/0x13 reserved. HKDF IKM
changed from SS||CK||IK to K_kem||CK||IK. Info string: "MILENAGE-
ML-KEM-FWD-v1".
A.2 [v1.0-CHG-02] WSIM-AS MASTER KEY Architecture WSIM-AS no longer
holds per-subscriber K_SLOT keys. Holds indexed MASTER KEY
material; per-subscriber K_sub derived on-demand within tamper-
resistant hardware using IMSI. REQ-3 and REQ-10 added.
AT_MASTER_KEY_IDX (0x22) added.
A.3 [v1.0-CHG-03] Problem Statement (Section 3) Comprehensive
problem statement: enterprise Wi-Fi/MNO anonymity, MNO backend
security boundary, alternative approach analysis, MNO device Wi-Fi
compliance gap.
A.4 [v1.0-CHG-04] Terminology WSIM-Card replaces "UE SIM", "SIM
card", "Peer SIM". WSIM-AS replaces "Server (WSIM)", "WSIM card",
"MEA".
A.5 [v1.0-CHG-05] Test Vectors Appendix B: ML-KEM-768 construction
vectors. Appendix C: MILENAGE baseline vectors retained
unchanged.
A.6 [v1.0-CHG-06] Section 9.2 Self-Contained RFC 9678 comparison
replaced with complete self-contained comparison of EAP-WSIM vs
RFC 9678.
A.7 [v1.0-CHG-07] Trust Model and Deployability (Sections 4.4-4.5)
New sections added addressing WG feedback on how WSIM-AS obtains
MNO subscriber credentials and device deployability.
A.8 [v1.0-CHG-08] HOKEY and Centralized AP (Sections 9.6-9.7) New
sections added: HOKEY WG prior art, centralized Wi-Fi controller
architecture compatibility.
A.9 EMSK Length Correction EMSK corrected from 32 to 64 bytes per
RFC 5247.
A.10 OKM Partitioning Correction OKM length increased from 128 to
160 bytes. EMSK slice corrected to OKM[64:128]. K_auth:
OKM[128:144]. K_confirm: OKM[144:160].
A.11 RFC Compliance Fixes Removed all cross-version references from
Gupta Expires 21 January 2027 [Page 32]
Internet-Draft EAP-WSIM July 2026
normative sections. TOC corrected. Duplicate [RFC5749] reference
merged. Section 10 title cleaned.
A.12 Section 3.3 Prose Consistency Section 3.3 converted from bullet
lists to prose consistent with Section 3.2.
A.13 IPR Disclosure Placement IPR disclosure moved from standalone
pre-TOC section into Status of This Memo per RFC convention.
A.14 WSIM-SLOT-SELECT Algorithm (Section 6.3) Summary specification
of WSIM-SLOT-SELECT-V2 algorithm added.
A.15 EAP Session-ID (Section 8.1) EAP Session-ID derivation added
per RFC 5247 Section 1.4.
A.16 Identity Privacy (Section 7.11) Pseudonym and fast re-
authentication identity handling added.
A.17 TPM Deployment (Appendix D.6) TPM 2.0 deployment option
expanded with hardware options, PCR binding, and swtpm lab
guidance.
A.18 WSIM SIM File Structure (Appendix E) Informative appendix added
with ADF_WSIM file hierarchy.
A.19 [2026-07-09] MASTER KEY Scope and Revocation (Section 5.4)
Clarified, in response to WG list discussion, that MASTER KEY
material is SSID/venue-scoped rather than a subscriber-base-wide
root. Added a 25-slot revocation structure: a compromised or
retired slot is deprecated via an applet update to the WSIM-AS
security hardware, performed the same way the MNO updates applets
on a subscriber's SIM card today. Clarified that all WSIM-AS
maintenance (provisioning, rotation, revocation) is performed
exclusively by the MNO. Added REQ-11 (MASTER KEY
Compartmentalization) and REQ-12 (MASTER KEY Revocability).
A.20 [2026-07-09] Multi-MNO Deployment (Section 4.6) Added multi-MNO
deployment model: one WSIM-AS instance per MNO, indexed by MCC/
MNC, operating independently at multi-carrier venues.
A.21 [2026-07-20] Duplicate Section Cleanup Removed duplicate,
conflicting copies of Section 7.11 (Identity Privacy), Section 8.1
(EAP Session-ID), and Appendix E (WSIM-Card File Structure) left
over from an earlier merge. No normative content change; the
retained text in each case is the version consistent with the
Table of Contents and terminology used elsewhere in the document.
Gupta Expires 21 January 2027 [Page 33]
Internet-Draft EAP-WSIM July 2026
Appendix B. Test Vectors (MILENAGE-ML-KEM-FWD)
The following test vectors verify the -01 construction. MILENAGE
inputs are identical to Appendix C (3GPP TS 35.208 Test Set 1).
NOTE: ML-KEM-768 keypairs and K_kem values below are example values
for specification verification. Production implementations MUST
generate fresh keypairs per session using a CSPRNG.
B.1. MILENAGE Inputs (same as Appendix C)
K (Ki / K_sub equivalent, 16 bytes): 465B5CE8B199B49FAA5F0A2EE238A6BC
RAND (16 bytes): 23553CBE9637A89D218AE64DAE47BF35
NONCE_S (16 bytes): 5A8D3F2B1C9E7041A6D5E4F3B2C1A090
NONCE_P (16 bytes): A1B2C3D4E5F60718293A4B5C6D7E8F90
B.2. MILENAGE Outputs (verified against TS 35.208 Test Set 1)
RES (8 bytes): A54211D5E3BA50BF (verified)
CK (16 bytes): B40BA9A3C58B2A05BBF0D987B21BF8CB (verified)
IK (16 bytes): F769BCD751044604127672711C6D3441 (verified)
Figure 20
B.3. ML-KEM-768 Key Exchange
NOTE: The following are example values for test vector purposes.
Real implementations generate these from a CSPRNG.
ML-KEM-768 encapsulation key (ek): [1184 bytes, omitted for
brevity -- see reference implementation gen_testvecs_01.py)
ML-KEM-768 ciphertext (ct): [1088 bytes, omitted for brevity]
K_kem (shared secret, 32 bytes): [Reference implementation output;
to be published with -01]
B.4. Session Key Derivation
IKM = K_kem || CK || IK (64 bytes)
salt = NONCE_S || NONCE_P (32 bytes)
info = "MILENAGE-ML-KEM-FWD-v1" (23 bytes)
Figure 21
Gupta Expires 21 January 2027 [Page 34]
Internet-Draft EAP-WSIM July 2026
NOTE: Full OKM values will be provided in the final -01 submission
alongside the reference implementation once ML-KEM test vectors are
generated. The MILENAGE baseline vectors in Appendix C are complete
and independently verifiable.
Appendix C. Test Vectors: MILENAGE Baseline
The following test vectors verify the MILENAGE component of the
MILENAGE-ML-KEM-FWD construction. MILENAGE inputs and outputs are
verified against 3GPP TS 35.208 Test Set 1 and are independent of the
key encapsulation mechanism.
C.1. MILENAGE Input Parameters
K (MILENAGE root key, 16 bytes): 465B5CE8B199B49FAA5F0A2EE238A6BC
OP (16 bytes): CDC202D5123E20F62B6D676AC72CB318
OPc (16 bytes): CD63CB71954A9F4E48A5994E37A02BAF
RAND (16 bytes): 23553CBE9637A89D218AE64DAE47BF35
SQN (6 bytes): FF9BB4D0B607 AMF (2 bytes): B9B9
C.2. MILENAGE Sub-Function Outputs
f1 MAC_A (8 bytes): 4A9FFAC354DFAFB3 f1* MAC_S (8 bytes):
01CFAF9EC4E871E9
f2 RES (8 bytes): A54211D5E3BA50BF
TS35.208 ref: A54211D5E3BA50BF (verified)
Figure 22
f3 CK (16 bytes): B40BA9A3C58B2A05BBF0D987B21BF8CB TS35.208 ref:
B40BA9A3C58B2A05BBF0D987B21BF8CB (verified)
f4 IK (16 bytes): F769BCD751044604127672711C6D3441 TS35.208 ref:
F769BCD751044604127672711C6D3441 (verified)
f5 AK (6 bytes): AA689C648370
TS35.208 ref: AA689C648370 (verified)
Figure 23
Gupta Expires 21 January 2027 [Page 35]
Internet-Draft EAP-WSIM July 2026
C.3. AUTN Construction and K_mac_start
SQN XOR AK: 55F328B43577
AUTN (16 bytes): 55F328B43577B9B94A9FFAC354DFAFB3
K_mac_start = HMAC-SHA-256(K, "WSIM-START-MAC-v1" || RAND):
C68233159C2A1B7A84CB3DD0172CD17A
76EFF79600485FA66F1277158B6AC799
Figure 24
C.4. Session Nonces (Informative)
NONCE_S: 5A8D3F2B1C9E7041A6D5E4F3B2C1A090 NONCE_P:
A1B2C3D4E5F60718293A4B5C6D7E8F90
These nonces are used as HKDF salt in the MILENAGE-ML-KEM-FWD
construction (Section 6.4). See Appendix B for ML-KEM-768
construction vectors.
C.5. Reference Output Key Material (MILENAGE-ECDH-FWD Construction)
MSK[0:32]: 928815EBF4B5498A77A19DB6A04B9EFB
439A604B7DC6DD558C920E4D067E21EF
MSK[32:64]: 26C8BA4802C95CF3AB3D49C7B9688019
2F8F931CACC2405F52186A99DCD4A95D
EMSK: 996AF0830F1FD6AD4C0450563568EAE4
7DD5E09ED9847379CA3D13A22D0C80F2
K_auth: 2D682081C8A223628E2C54F449D71F35 K_confirm:
7741CE07737EEA89B2F422D77C132B48
PMK = MSK[0:32]:
928815EBF4B5498A77A19DB6A04B9EFB
439A604B7DC6DD558C920E4D067E21EF
Figure 25
AT_MAC_CONFIRM: D469BB2CCCD9C2D0F90B4C998E94B6C4
1136D0744E7C680DCD3B36E3A2785316
Appendix D. Future Work
D.1. Key Slot Selection: draft-gupta-emu-wsim-key-select Non-
reversible IMSI-bound Time-of-Day slot selection algorithm.
Gupta Expires 21 January 2027 [Page 36]
Internet-Draft EAP-WSIM July 2026
D.2. IEEE 802.11r Integration: draft-gupta-emu-wsim-ft PMK-R1 pre-
distribution at enterprise APs via R0KH.
D.3. Ciphersuite Negotiation Algorithm agility for future MILENAGE
variants and KEM options.
D.4. Fast Reconnect Session resumption without a full four-round
exchange.
D.5. Post-Quantum Hybrid Variant PQ/T hybrid combining ML-KEM with a
classical KEM.
D.6. TPM-Based WSIM-AS Deployment
The WSIM-AS security hardware MAY be implemented using a Trusted
Platform Module (TPM 2.0) [TPM20] for MASTER KEY storage in
environments where a dedicated HSM is not available.
Hardware options verified in lab testing:
* ANAVI TPM 2.0 (Infineon SLB9672, SPI, GPIO pins 17-26)
* LetsTrust TPM (Infineon SLB9672, same pinout)
MASTER KEY material is sealed to TPM PCR values representing the
expected WSIM-AS software stack. Unsealing requires the PCR state
to match, providing measured boot attestation. Key material
sealed in TPM NV storage with authorization policy binding to
PCR[7] (Secure Boot state).
For lab environments, swtpm (software TPM emulator) MAY be used
for development and testing. swtpm MUST NOT be used in production
deployments; it provides no tamper resistance.
TPM-based deployments satisfy REQ-10 only when combined with
physical security controls preventing TPM removal or PCR
manipulation.
Appendix E. WSIM-Card File Structure (Informative)
This appendix specifies the SIM file structure required on the WSIM-
Card (device-side SIM). All files reside within the WSIM Application
Dedicated File (ADF_WSIM):
AID: A0000000871002005753494D
E.1. Elementary Files
Gupta Expires 21 January 2027 [Page 37]
Internet-Draft EAP-WSIM July 2026
File FID Size Access Description
------------- ------ ----- ----------- -------------------------
EF_WSIM_VER 0x6F00 2 B READ=ALW Protocol version 0x0101
EF_DEVICE_ID 0x6F01 var READ=ALW NAI: 0IMSI@realm
EF_SLOT_STAT 0x6F02 15 B READ=PIN1 Slot status (per slot)
EF_SLOT_VER 0x6F03 15 B READ=PIN1 Rotation counter per slot
EF_K_SELECT 0x6F04 32 B READ=NEVER HMAC key for SLOT-SELECT
EF_K_WRAP 0x6F05 32 B READ=NEVER AES-256 wrap key
Figure 26
E.2. Key Bundle Directories
DF_KEY_BUNDLE_A (0x5F10): Half-A of each K_SLOT (slots 0..14) EF_K_SLOT_A(i)
(0x6F10+i): AES256WRAP(K_WRAP, K_SLOT[i] XOR mask) Access:
READ=NEVER, UPDATE=ADM
DF_KEY_BUNDLE_B (0x5F11): Half-B masks (slots 0..14)
EF_K_SLOT_B(i) (0x6F20+i): AES256WRAP(K_WRAP, mask[i])
Access: READ=NEVER, UPDATE=ADM
Figure 27
Neither half alone is usable; reconstruction requires both halves and
the ICCID-derived unwrapping key, all within the UICC platform.
E.3. Certificate Files
DF_CERT (0x5F30): EF_DEVICE_CERT (0x6F40): DER X.509v3, up to 1024
bytes EF_CA_CERT (0x6F41): Trust anchor for WSIM-AS verification
E.4. UE Key Bundle (WSIM-Card only)
DF_UE_KEY_BUNDLE (0x5F50): Per-slot K_UE values EF_K_UE(i)
(0x6F60+i): 32 bytes, READ=PIN1, UPDATE=ADM Fifteen slots (i =
0..14); slot 14 is emergency reserve.
Access conditions on EF_K_SELECT and EF_K_WRAP are enforced by the
UICC platform independently of applet code. Neither file is ever
readable after personalization.
Author's Address
Praveen Gupta
MobileStack, Inc.
Email: pgupta@mobilestack.com
URI: https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/
Gupta Expires 21 January 2027 [Page 38]