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.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.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, . [RFC3748] Aboba, B. and et al., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004, . [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006, . [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008, . 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, . [RFC8126] Cotton, M. and et al., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, May 2017, . [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, . [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, . [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, . [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, . 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, . [I-D.eap-psk-256] "EAP-PSK-256", Work in Progress, Internet-Draft, draft- eap-psk-256-01, June 2026, . [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, . [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, January 2007, . [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, . [RFC5749] Hoeper, K. and et al., "Distribution of EAP-Based Keys for Handover and Re-Authentication", RFC 5749, March 2010, . [SGP02] GSMA, "Embedded SIM Remote Provisioning Architecture", GSMA SGP.02 Version 4.2, 2020, . [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, . 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]