Network Working Group P. Gupta Internet-Draft MobileStack Intended status: Standards Track April 24, 2026 Expires: October 26, 2026 EAP-WSIM: A SIM-Based EAP Method Using the MILENAGE-ECDH-FWD Authentication Construction draft-gupta-emu-eap-wsim-00 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/. Source for this draft and an issue tracker may be found at https://github.com/pgupta-mobilestack/eap-wsim (to be created upon WG adoption). Abstract This document specifies EAP-WSIM, a new EAP authentication method for enterprise wireless networks that performs offline mutual authentication without contacting any Mobile Network Operator (MNO) Home Subscriber Server (HSS), Home Location Register (HLR), or Unified Data Management (UDM) function during the authentication exchange. EAP-WSIM uses a new cryptographic construction called MILENAGE- ECDH-FWD, which combines the MILENAGE authentication and key agreement algorithm [TS35.205] with an ephemeral Elliptic Curve Diffie-Hellman (ECDH) exchange. This construction simultaneously provides mutual authentication via MILENAGE challenge-response and forward secrecy via ephemeral ECDH, such that compromise of long- term key material does not expose keys from prior sessions. The key distinction from all existing SIM-based EAP methods -- EAP-SIM [RFC4186], EAP-AKA [RFC4187], EAP-AKA' [RFC9048], and EAP-AKA' FS [RFC9678] -- is that EAP-WSIM requires no MNO backend contact during authentication. The EAP server holds a SIM card (the WSIM) that functions as a self-contained Authentication Centre, enabling deployment in air-gapped enterprise environments without MNO infrastructure dependency. This document specifies the protocol core: the four-round EAP-WSIM exchange, message formats, attribute encodings, and key derivation. Key slot selection [WSIM-KEY-SELECT] and IEEE 802.11r Fast Transition integration [WSIM-FT] will be submitted as additional specifications only if required based on review and comments on this document. This document does not update any existing RFC. 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 October 26, 2026. 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. IPR Disclosure The author has filed US Provisional Patent Application 64/048,069 covering aspects of the WSIM architecture described in this document. In accordance with BCP 79 [RFC8179], the author commits to license any patents reading on this specification to implementers of any RFC produced from this document on royalty-free, reasonable, and non-discriminatory terms (RAND-z). An IPR disclosure will be filed at https://datatracker.ietf.org/ipr/about/ concurrent with submission of this Internet-Draft. Note on RFCs That Could Be Updated This document defines a new, independent EAP method. It does not update any existing RFC. Specifically: o RFC 4186 (EAP-SIM), RFC 4187 (EAP-AKA), RFC 9048 (EAP-AKA'), and RFC 9678 (EAP-AKA' FS) are informative references only. EAP-WSIM does not modify the operation of any of these methods. o RFC 3748 (EAP) is the framework within which EAP-WSIM operates. No changes to the base EAP framework are required or proposed. o RFC 5247 (EAP Key Management Framework) defines the MSK/EMSK model that EAP-WSIM follows. No changes to RFC 5247 are required. Should the IETF determine that EAP-WSIM warrants an update to IANA registries under RFC 3748, a formal "Updates: 3748" header would be added prior to publication. This is an open question for WG discussion. Table of Contents 1. Introduction 2. Terminology 3. Motivation and Design Goals 4. The MILENAGE-ECDH-FWD Construction 4.1. Overview 4.2. Inputs 4.3. Construction Steps 4.4. Output Key Material 4.5. Security Properties 5. EAP-WSIM Protocol 5.1. Protocol Overview 5.2. Message Header 5.3. Attribute Encoding 5.4. WSIM-Start (Subtype 0x01) 5.5. WSIM-Challenge (Subtype 0x02) 5.6. WSIM-Confirm (Subtype 0x03) 5.7. WSIM-Complete (Subtype 0x04) 5.8. WSIM-Error (Subtype 0x05) 5.9. Anti-Replay 6. MSK and EMSK 7. Relationship to RFC 9678 (EAP-AKA' FS) 7.1. MNO Backend Dependency 7.2. Protocol Architecture 7.3. Key Derivation 7.4. Pre-Session Integrity 7.5. Summary Comparison Table 8. Security Claims (per RFC 3748 Section 7.2) 9. IANA Considerations 10. Security Considerations 11. Privacy Considerations 12. References 12.1. Normative References 12.2. Informative References Appendix A. Test Vectors (MILENAGE-ECDH-FWD) Appendix B. Comparison with Prior EAP SIM-Based Methods Appendix C. Future Work Author's Address 1. Introduction EAP-SIM [RFC4186] and EAP-AKA [RFC4187] authenticate subscribers using SIM credentials, but require the EAP server to contact the MNO AuC, HSS, HLR, or UDM during each exchange to obtain fresh authentication vectors. EAP-AKA' [RFC9048] improved the key derivation over EAP-AKA but retains this backend dependency. RFC 9678 [RFC9678] added forward secrecy via ECDH to EAP-AKA', but likewise still requires MNO backend contact for each authentication. EAP-WSIM removes this dependency entirely. The EAP server holds a SIM card -- the WSIM -- that contains pre-provisioned master key material and can generate MILENAGE authentication vectors entirely on-card, functioning as a self-contained Authentication Centre. The subscriber's UE SIM holds device-specific keys pre-derived from the same root material by an offline trust anchor. No MNO backend contact occurs at any point during the authentication exchange. The cryptographic core of EAP-WSIM is a new named construction, MILENAGE-ECDH-FWD, which integrates MILENAGE [TS35.205] with ephemeral ECDH key agreement. MILENAGE provides mutual authentication; raw ECDH provides key agreement; MILENAGE-ECDH-FWD binds both such that session key material is cryptographically bound to both the MILENAGE authentication outcome and the ephemeral ECDH exchange. This provides mutual authentication and forward secrecy simultaneously. By defining MILENAGE-ECDH-FWD as a named construction rather than an ad-hoc combination, this document enables independent security analysis and allows future protocols to reuse it without re- specifying the combination. Section 7 provides a detailed technical comparison with RFC 9678 to precisely characterize the non-overlap between EAP-WSIM and EAP-AKA' FS. This document does not update any existing RFC. It defines a new, independent EAP method. 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]. WSIM: Wireless SIM. A SIM card or eSIM deployed on the network/authenticator side, holding master key material and executing MILENAGE on-card. The WSIM functions as a self- contained Authentication Centre without requiring MNO contact. UE SIM: The SIM card in the subscriber's User Equipment, pre-provisioned at manufacturing with K_UE: a device-specific MILENAGE key derived from the master key material using the subscriber's IMSI. The Peer does NOT hold the root master key; it holds K_UE only. K_SLOT[i]: One of 15 independent 256-bit master keys (i = 0..14) held in the WSIM card. K_SLOT[i] is NEVER exported from the WSIM. Each slot has an associated status: ACTIVE (0x01), REVOKED (0x00), or RESERVE (0x02, slot 14 only). Revoked slots are skipped by WSIM-SLOT-SELECT on both Server and Peer. Slots 0-11 correspond to calendar months; slots 12-13 are overlap periods; slot 14 is the emergency reserve used only when all operational slots are revoked. K_UE[i]: The 128-bit MILENAGE authentication key for subscriber IMSI and slot i. Derived as: K_UE[i] = HKDF-SHA-256(K_SLOT[i], salt, IMSI || i || version) The Server (WSIM) derives K_UE[i] on-card at authentication time. The Peer (UE SIM) holds K_UE[0..14] for ALL slots, pre-provisioned at manufacturing. When a slot is revoked on the Server side, the Peer automatically uses the next active slot via WSIM-SLOT-SELECT -- no OTA update required. WSIM-SLOT-SELECT: A non-reversible, IMSI-bound, Time-of-Day algorithm executed independently by both Server and Peer to determine the active slot index. Given the same IMSI and UTC hour, both parties deterministically select the same slot without communication. The algorithm computes HMAC-SHA-256(K_SELECT, IMSI||TOD||label), takes (H[0]*256 + H[1]) mod 14 as the base candidate, then walks forward until it finds the first ACTIVE slot. If all operational slots (0-13) are revoked, slot 14 is returned. K_SELECT is stored READ=NEVER on both WSIM and UE SIM. K: Used in this document as shorthand for K_UE[active_slot] in protocol operation contexts, where active_slot is determined by WSIM-SLOT-SELECT. MILENAGE-ECDH-FWD: The cryptographic construction defined in Section 4 combining MILENAGE mutual authentication with ephemeral ECDH key agreement to produce authenticated session key material with forward secrecy. Server: The WSIM card acting as EAP authenticator. Peer: The UE SIM acting as EAP supplicant. MSK: Master Session Key, 64 bytes, per [RFC5247]. EMSK: Extended Master Session Key, 32 bytes, per [RFC5247]. Forward Secrecy: Compromise of long-term key K after session completion does not expose session keys from that completed session. Offline Authentication: Authentication that completes without any network communication to MNO backend infrastructure (HSS, HLR, UDM, or AuC). 3. Motivation and Design Goals REQ-1 (Offline Authentication): The EAP server MUST authenticate provisioned subscribers without contacting any MNO HSS, HLR, UDM, or AuC during the authentication exchange. REQ-2 (Mutual Authentication): Both Server and Peer MUST authenticate each other. Server authenticates to Peer via AUTN; Peer authenticates to Server via RES. REQ-3 (Forward Secrecy): Compromise of long-term key K MUST NOT expose session keys from prior completed sessions. REQ-4 (Named Construction): The combination of MILENAGE and ECDH MUST be defined as a named, reusable cryptographic construction with independently verifiable security properties. REQ-5 (MSK Compatibility): The MSK and EMSK produced MUST be compatible with [RFC5247]. REQ-6 (Anti-Replay): The protocol MUST prevent replay of captured exchanges via sequence number and nonce mechanisms. REQ-7 (Minimal Scope): This document covers the protocol core. Key slot selection and 802.11r integration may be submitted as additional specifications depending on WG review feedback. 4. The MILENAGE-ECDH-FWD Construction 4.1. Overview MILENAGE-ECDH-FWD is a two-party authenticated key agreement construction. The Server (WSIM) holds K_SLOT[0..14] and selects the active slot using WSIM-SLOT-SELECT, then derives K_UE[slot] on-card. The Peer (UE SIM) holds K_UE[0..14] for all slots and independently selects the same active slot using WSIM-SLOT-SELECT. If a slot has been revoked on the Server side, WSIM-SLOT-SELECT walks forward to the next ACTIVE slot on both sides independently, requiring no OTA update to the Peer. Two tracks run in parallel: Track A (MILENAGE): Server computes MILENAGE(K, RAND) to obtain XRES, CK, IK, AK; constructs AUTN. Peer verifies AUTN (authenticating Server) and computes RES, CK, IK. Server verifies RES == XRES (authenticating Peer). Track B (ECDH): Each party generates a fresh ephemeral P-256 keypair and exchanges public keys. Each computes the same shared secret SS = P256-ECDH(sk_local, pk_remote). Combination: Session key material derives from (SS, CK, IK, NONCE_S, NONCE_P) via HKDF-SHA-256, binding both tracks. Compromise of K alone cannot recompute SS (forward secrecy); compromise of SS alone cannot derive session keys without CK and IK (key binding). 4.2. Inputs slot Active slot index selected by WSIM-SLOT-SELECT (independently computed by both Server and Peer) K_UE[slot] 128-bit MILENAGE key for this subscriber and active slot (Server derives on-card; Peer holds pre-provisioned) RAND 128-bit random challenge (generated fresh by Server) (sk_S,pk_S) Server ephemeral P-256 keypair (fresh per session) (sk_P,pk_P) Peer ephemeral P-256 keypair (fresh per session) NONCE_S 128-bit random nonce (Server, fresh per session) NONCE_P 128-bit random nonce (Peer, fresh per session) SQN 48-bit MILENAGE sequence number AMF 16-bit Authentication Management Field 4.3. Construction Steps Server side: (a) Receive Peer identity (IMSI or pseudonym) from outer identity (b) Run WSIM-SLOT-SELECT(IMSI, UTC_now, K_SELECT, SLOT_STATUS): H = HMAC-SHA-256(K_SELECT, IMSI || TOD_block || label) slot_base = (H[0]*256 + H[1]) mod 14 for offset in 0..13: idx = (slot_base + offset) mod 14 if SLOT_STATUS[idx] == ACTIVE: slot = idx; break if no active slot found: slot = 14 (emergency reserve) (c) Derive K_UE[slot] on-card: K_UE[slot] = HKDF-SHA-256(K_SLOT[slot], salt, IMSI||slot||ver) (d) Run MILENAGE(K_UE[slot], RAND): XRES = f2(K_UE[slot], RAND) CK = f3(K_UE[slot], RAND) IK = f4(K_UE[slot], RAND) AK = f5(K_UE[slot], RAND) (e) AUTN = (SQN XOR AK) || AMF || f1(K_UE[slot], SQN, RAND, AMF) (f) Generate ephemeral P-256 keypair (sk_S, pk_S) (g) Generate NONCE_S (h) K_mac_start = HMAC-SHA-256(K_UE[slot], "WSIM-START-MAC-v1" || RAND) (i) Send WSIM-Start: RAND, AUTN, pk_S, NONCE_S, AT_COUNTER, AT_MAC NOTE: AT_COUNTER carries the active slot index in the high byte, enabling the Peer to detect slot selection mismatch before expending MILENAGE computation. Peer side (upon receiving WSIM-Start): (j) Run WSIM-SLOT-SELECT(IMSI, UTC_now, K_SELECT, local_status) independently -- same algorithm, same inputs, same result. If computed slot != slot indicated in AT_COUNTER, retry with UTC_now +/- 1 hour to handle clock skew. If still no match, send WSIM-Error 0x0008 (SLOT_MISMATCH). (k) Compute K_mac_start = HMAC-SHA-256(K_UE[slot], label || RAND) (l) Verify AT_MAC using K_mac_start (m) Verify AUTN using K_UE[slot]: AK = f5(K_UE[slot], RAND) SQN = AUTN[0:6] XOR AK Recompute MAC_A = f1(K_UE[slot], SQN, RAND, AUTN[6:8]) Verify MAC_A == AUTN[8:16] -- Server authenticated Verify SQN is in acceptable range (n) Compute RES = f2(K_UE[slot], RAND); CK = f3; IK = f4 (o) Generate ephemeral P-256 keypair (sk_P, pk_P) (p) Generate NONCE_P (q) Compute SS = P256-ECDH(sk_P, pk_S) (r) Derive K_session per Section 4.4 (s) Send WSIM-Challenge: RES, pk_P, NONCE_P, AT_MAC_PEER Server side (upon receiving WSIM-Challenge): (t) Verify RES == XRES -- Peer authenticated (u) Compute SS = P256-ECDH(sk_S, pk_P) (v) Derive same K_session 4.4. Output Key Material IKM = SS || CK || IK (32 + 16 + 16 = 64 bytes total) salt = NONCE_S || NONCE_P (16 + 16 = 32 bytes) info = "MILENAGE-ECDH-FWD-v1" (21 bytes, UTF-8, fixed version label) L = 128 bytes OKM = HKDF-SHA-256(IKM, salt, info, L) OKM partitioned as: OKM[0:64] MSK (64 bytes, per [RFC5247]) OKM[64:96] EMSK (32 bytes, per [RFC5247]) OKM[96:112] K_auth (16 bytes, MAC key for WSIM-Challenge) OKM[112:128] K_confirm (16 bytes, MAC key for WSIM-Confirm) 4.5. Security Properties Mutual Authentication: Server authenticates to Peer via AUTN verification (step h). Peer authenticates to Server via RES == XRES (step o). Forward Secrecy: Ephemeral private keys sk_S and sk_P are discarded after use. An adversary who later learns K_UE[slot] cannot recompute SS from recorded public keys pk_S, pk_P. Since SS contributes to IKM, OKM is computationally independent of K_UE[slot] alone. Key Binding: IKM includes SS (ECDH) and CK||IK (MILENAGE). Neither component alone determines OKM. A failure in one component does not automatically yield the session keys. IMSI-Bound Key Isolation: Each subscriber's K_UE[i] is independently derived from K_SLOT[i] using the subscriber's IMSI. Compromise of one subscriber's K_UE[i] does not affect other subscribers or other slots. K_SLOT[0..14] never leaves the WSIM card. Slot Revocation Without Re-Provisioning: When K_SLOT[i] is revoked (SLOT_STATUS[i] = 0x00), WSIM-SLOT-SELECT on both Server and Peer independently walks forward to the next ACTIVE slot. The Peer holds K_UE[0..14] for all slots pre-provisioned at manufacturing, so slot rotation on the Server side requires no OTA update to any UE SIM. Session Uniqueness: Fresh RAND, fresh ECDH keypairs, and fresh NONCE_S, NONCE_P per session ensure distinct OKM values. Note on Key Size: MILENAGE uses 128-bit K; P-256 provides approximately 128-bit security. The construction provides 128-bit security overall. 5. EAP-WSIM Protocol 5.1. Pre-Association Phase and Protocol Overview 5.1.1. Pre-Association: Unassociated UE Identity Announcement Before the EAP exchange begins, an unassociated UE operating in a pre-authentication VLAN sends an initial announcement message to the Server (WSIM). This phase allows the Server to authenticate itself to the UE via its operator certificate before the MILENAGE exchange begins, preventing the Peer from engaging a rogue authenticator. The pre-association exchange: Unassociated UE Server (WSIM) ────────────── ───────────── WSIM-Announce ──────────────────────> outer_identity (IMSI or pseudonym) [Server looks up K_UE AT_REQUEST_CERT for this subscriber] <──────────────── WSIM-Identity AT_SERVER_CERT AT_CERT_SIG AT_WSIM_ID [UE validates: issuing CA trusted? ] [Venue/SSID SAN in cert matches? ] [Cert fingerprint matches expected? ] [If validation fails: abort, log event] AT_REQUEST_CERT: Type 0x1C, Length 0. Signals the Peer requests the Server's operator certificate before proceeding. AT_SERVER_CERT: Type 0x1D, variable length. The Server's X.509 operator certificate (DER-encoded), issued by the MNO CA and containing the operator-id, venue-id, and SSID in the SAN. AT_CERT_SIG: Type 0x1E, 64 bytes. ECDSA-P256 signature over (outer_identity || AT_SERVER_CERT || timestamp) using the Server's private key, proving possession. AT_WSIM_ID: Type 0x1F, variable length. A unique identifier for this WSIM instance, allowing the UE application to cross-check against an expected hardware fingerprint if available. Upon successful certificate validation, the UE proceeds to the standard EAP exchange. The Server's verified identity is bound into the EAP-WSIM session by including the certificate fingerprint in the HKDF info parameter (see Section 4.4, Note on Channel Binding). NOTE: Implementations that operate within a standard 802.1X/EAP framework where pre-EAP messaging is not available MAY omit the pre-association phase and begin directly with the EAP exchange. In this case, the Server's identity is authenticated implicitly via the AUTN verification in WSIM-Start (the Server proves possession of K_UE, which requires knowledge of K_SLOT). 5.1.2. EAP Exchange Following the pre-association phase (or directly in constrained deployments), the four-round EAP-WSIM exchange proceeds. EAP-WSIM uses EAP type 0xFE (Expanded Type [RFC3748]) with a vendor-specific method type. [IANA type assignment requested; see Section 9.] Server (WSIM) Peer (UE SIM) ───────────── ───────────── EAP-Request/Identity ──────────────────> <──────────────── EAP-Response/Identity (outer_identity: NAI) [Server: derive K_UE on-card from K_SLOT + IMSI; steps (a)-(g)] WSIM-Start ────────────────────────────> AT_RAND, AT_AUTN, AT_ECDH_SERVER, [Peer: steps (h)-(o)] AT_NONCE_S, AT_COUNTER, AT_MAC <──────────────── WSIM-Challenge AT_RES, AT_ECDH_PEER, AT_NONCE_P, AT_MAC_PEER [Server: steps (p)-(r); compute AT_MAC_CONFIRM] WSIM-Confirm ──────────────────────────> AT_MAC_CONFIRM [Peer: verify confirm] <──────────────── WSIM-Complete EAP-Success (+ MSK to lower layer) ────> Figure 1: EAP-WSIM Pre-Association and Four-Round Exchange 5.2. Message Header 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code: 1 = Request (Server->Peer); 2 = Response (Peer->Server) Type: 0xFE (Expanded Type per [RFC3748] Section 5.7) Vendor-Id: [PEN assigned to this document; see Section 9] Vendor-Type: 0x00000001 (EAP-WSIM) Subtype: 0x01 WSIM-Start 0x02 WSIM-Challenge 0x03 WSIM-Confirm 0x04 WSIM-Complete 0x05 WSIM-Error 5.3. Attribute Encoding All attributes use TLV encoding: Type(1B) | Length(1B) | Value Type Name Length Description ---- ----------------- ------- ---------------------------------- 0x10 AT_RAND 16 MILENAGE RAND challenge 0x11 AT_AUTN 16 MILENAGE AUTN token 0x12 AT_ECDH_SERVER 65 Server P-256 uncompressed pubkey 0x13 AT_ECDH_PEER 65 Peer P-256 uncompressed pubkey 0x14 AT_NONCE_S 16 Server session nonce 0x15 AT_NONCE_P 16 Peer session nonce 0x16 AT_RES 16 MILENAGE RES from Peer (f2 output) 0x17 AT_MAC 32 HMAC-SHA-256(K_mac_start, message) 0x18 AT_MAC_PEER 32 HMAC-SHA-256(K_auth, message) 0x19 AT_MAC_CONFIRM 32 HMAC-SHA-256(K_confirm, confirm) 0x1A AT_COUNTER 4 Anti-replay counter (monotonic) 0x1B AT_ERROR_CODE 2 Error code (WSIM-Error only) 0x1C AT_REQUEST_CERT 0 Pre-assoc: Peer requests Server cert 0x1D AT_SERVER_CERT variable Pre-assoc: DER-encoded X.509 cert 0x1E AT_CERT_SIG 64 Pre-assoc: ECDSA-P256 signature 0x1F AT_WSIM_ID variable Pre-assoc: WSIM instance identifier AT_MAC and AT_MAC_PEER are computed over the complete EAP message with the MAC field set to all zeros during computation. 5.4. WSIM-Start (Subtype 0x01, Server to Peer) Mandatory: AT_RAND, AT_AUTN, AT_ECDH_SERVER, AT_NONCE_S, AT_COUNTER, AT_MAC The AT_MAC in WSIM-Start uses K_mac_start, derived before session keys are established: K_mac_start = HMAC-SHA-256(K_UE, "WSIM-START-MAC-v1" || RAND) where K_UE is the per-subscriber, IMSI-bound MILENAGE key derived on-card by the Server and pre-provisioned on the Peer's UE SIM. 5.5. WSIM-Challenge (Subtype 0x02, Peer to Server) Mandatory: AT_RES, AT_ECDH_PEER, AT_NONCE_P, AT_MAC_PEER AT_MAC_PEER uses K_auth (OKM[96:112]) derived in Section 4.4. Peer MUST: 1. Verify AT_MAC in WSIM-Start using K_mac_start. 2. Verify AUTN per Section 4.3 step (h); on failure send WSIM-Error with AT_ERROR_CODE = 0x0002. 3. Complete key derivation per Section 4.4. 4. Transmit WSIM-Challenge. 5.6. WSIM-Confirm (Subtype 0x03, Server to Peer) Mandatory: AT_MAC_CONFIRM AT_MAC_CONFIRM = HMAC-SHA-256( key = K_confirm, data = "WSIM-CONFIRM-v1" || AT_RAND || AT_NONCE_S || AT_NONCE_P ) Server MUST verify AT_RES == XRES before sending WSIM-Confirm. If RES != XRES, Server sends WSIM-Error with AT_ERROR_CODE = 0x0003. 5.7. WSIM-Complete (Subtype 0x04, Peer to Server) No mandatory payload. Signals Peer has verified AT_MAC_CONFIRM. Server responds with EAP-Success. 5.8. WSIM-Error (Subtype 0x05) Mandatory: AT_ERROR_CODE Code Meaning ------ ---------------------------------------------------------- 0x0001 UNSUPPORTED_METHOD WSIM-Start is malformed or unsupported 0x0002 AUTN_FAILURE Peer could not verify AUTN 0x0003 RES_FAILURE Server: RES != XRES 0x0004 CONFIRM_FAILURE Peer: 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 Peer slot selection does not match Server slot; clock skew > 1 hour On receiving WSIM-Error, the recipient MUST terminate the exchange. The Server MUST send EAP-Failure. 5.9. Anti-Replay AT_COUNTER is a monotonically increasing 32-bit counter maintained per (Server, Peer) pair, included in WSIM-Start. The Peer MUST verify it is strictly greater than the last accepted value. The SQN embedded in AUTN provides independent MILENAGE-layer anti- replay per [TS35.205]. Session nonces (AT_NONCE_S, AT_NONCE_P) ensure session key uniqueness as a third independent mechanism. 6. MSK and EMSK MSK (OKM[0:64]) and EMSK (OKM[64:96]) are defined per [RFC5247]. MSK is exported to the lower layer upon EAP-Success. When used with RADIUS [RFC2865], it is transported in MS-MPPE-Recv-Key and MS-MPPE-Send-Key attributes. EMSK MUST NOT be exported. When used with IEEE 802.11r, PMK = MSK[0:32] per [IEEE80211] Section 12.7.1.3. The integration of this PMK with the R0KH for Fast Transition key pre-distribution is specified in [WSIM-FT]. 7. Relationship to RFC 9678 (EAP-AKA' FS) RFC 9678 [RFC9678] (EAP-AKA' FS) is the most closely related existing specification. Both EAP-WSIM and EAP-AKA' FS use ephemeral ECDH with MILENAGE to achieve forward secrecy. However, they address fundamentally different deployment scenarios and are not in conflict. This section documents the technical differences. 7.1. MNO Backend Dependency EAP-AKA' FS [RFC9678], like all prior SIM-based EAP methods, requires the EAP server to obtain authentication vectors from the MNO Authentication Database during each exchange. The ECDH extension in RFC 9678 adds forward secrecy to the session keys but does not change this architecture: the Server cannot authenticate a subscriber without contacting the MNO AD. EAP-WSIM eliminates this dependency entirely. The WSIM card is a self-contained Authentication Centre: it holds master key material on-card, derives device-specific MILENAGE keys on-card, generates authentication vectors on-card, and verifies subscriber responses on-card. No network communication to any MNO infrastructure occurs during or before the authentication exchange. This architectural difference enables EAP-WSIM to operate in: o Enterprise deployments without MNO connectivity agreements o Air-gapped environments (manufacturing, defence, healthcare) o Deployments where MNO backend latency or availability is not guaranteed for all authentication events 7.2. Protocol Architecture EAP-AKA' FS [RFC9678] is an extension to EAP-AKA'. It adds the AT_KDF_FS and AT_PUB_ECDHE attributes to the existing EAP-AKA' message structure. A negotiation round may be required if the Peer's preferred KDF differs from the Server's first proposal. EAP-WSIM is a new, independent EAP method with its own four-round exchange (WSIM-Start, WSIM-Challenge, WSIM-Confirm, WSIM-Complete). It does not extend any existing EAP method and shares no message types, attribute namespaces, or key derivation steps with EAP-AKA'. 7.3. Key Derivation In EAP-AKA' FS [RFC9678], forward secrecy is added by computing a shared ECDH key MK_ECDHE and incorporating it into the existing EAP-AKA' PRF' key derivation alongside the AKA-derived CK' and IK'. The AT_KDF_FS attribute selects the ECDH group and KDF variant. In EAP-WSIM, MILENAGE and ECDH are combined into the named MILENAGE-ECDH-FWD construction (Section 4). The construction uses HKDF-SHA-256 with IKM = SS || CK || IK, directly binding the ECDH shared secret and MILENAGE key material in a single extraction step with the versioned info string "MILENAGE-ECDH-FWD-v1". This construction is defined as a standalone named primitive with independently verifiable security properties (Section 4.5), facilitating security analysis and future reuse. 7.4. Pre-Session Integrity In EAP-AKA' FS, the first challenge message is integrity-protected by AT_MAC derived from EAP-AKA' key material (which requires the MNO backend to have provided authentication vectors first). In EAP-WSIM, the first message (WSIM-Start) is protected by: K_mac_start = HMAC-SHA-256(K, "WSIM-START-MAC-v1" || RAND) This is a pre-session MAC derived directly from K and the challenge RAND. It provides integrity and binds the first message to K, though it does not provide forward secrecy for the first message (see Section 10.4 for analysis). 7.5. Summary Comparison Table +---------------------------+--------------------+-------------------+ | Property | RFC 9678 | EAP-WSIM | | | (EAP-AKA' FS) | (this document) | +---------------------------+--------------------+-------------------+ | MNO backend required | YES | NO | | Air-gapped deployment | No | Yes | | Protocol structure | Extension to | Independent new | | | EAP-AKA' | EAP method | | Forward secrecy | Yes (ECDH) | Yes (ECDH) | | Mutual authentication | Yes | Yes | | Named crypto construction | No | Yes: MILENAGE- | | | | ECDH-FWD | | First-msg integrity key | From AKA+MNO AD | K_mac_start | | | | (offline, from K) | | Key slot management | Single root key | Multi-slot bundle | | | per subscriber | [WSIM-KEY-SELECT] | | 802.11r integration | Not specified | [WSIM-FT] | | Updates existing RFC | RFC 5448, RFC 9048 | None | +---------------------------+--------------------+-------------------+ Table 1: EAP-WSIM vs RFC 9678 (EAP-AKA' FS) 8. Security Claims (per RFC 3748 Section 7.2) Mechanism: Shared symmetric key (K, 128-bit MILENAGE root key) plus ephemeral P-256 ECDH. Ciphersuite negotiation: None in this version. The construction is fixed as MILENAGE- ECDH-FWD with P-256 and HMAC-SHA-256/HKDF-SHA-256. Mutual authentication: YES. Server authenticates to Peer via AUTN; Peer authenticates to Server via RES. Both verifications are required. Integrity protection: YES. AT_MAC (K_mac_start) protects WSIM-Start. AT_MAC_PEER (K_auth) protects WSIM-Challenge. AT_MAC_CONFIRM (K_confirm) protects WSIM-Confirm. All MACs use HMAC-SHA-256. Replay protection: YES. AT_COUNTER (EAP layer) and SQN in AUTN (MILENAGE layer) provide two independent anti-replay mechanisms. Session nonces provide a third. Confidentiality: No. EAP-WSIM does not encrypt EAP messages. Session keys protect subsequent link-layer traffic. Key derivation: YES. MSK (64 bytes) and EMSK (32 bytes) per [RFC5247] via MILENAGE-ECDH-FWD (Section 4.4). Key strength: 128-bit (limited by K size and P-256 security level). Dictionary attack resistance: YES. 128-bit K provides resistance. Active attacks require network interaction. Fast reconnect: Not defined in this version. Cryptographic binding: YES. AT_MAC_PEER binds pk_P and NONCE_P to the MILENAGE authentication outcome via K_auth. Session independence: YES. Each session uses fresh RAND, fresh ephemeral ECDH keypairs, and fresh NONCE_S, NONCE_P. Fragmentation: YES. EAP-WSIM inherits EAP fragmentation [RFC3748]. Channel binding: YES. The HKDF info parameter MAY be extended to include server identity; this is a candidate for a future version. 9. IANA Considerations This document does not update any existing RFC or registry. 9.1. EAP Type IANA is requested to allocate a permanent EAP method type for EAP-WSIM in the "Method Types" sub-registry of the "Extensible Authentication Protocol (EAP) Registry" at https://www.iana.org/assignments/eap-numbers/. Until a permanent assignment is available, implementations MUST use EAP Expanded Type (0xFE) [RFC3748] with a Vendor-Id equal to the author's Private Enterprise Number and Vendor-Type 0x00000001. 9.2. EAP-WSIM Attribute Type Registry IANA is requested to create a new registry titled "EAP-WSIM Attribute Types" with the initial entries from Section 5.3. Values 0x00-0x0F and 0x1C-0x7F are Reserved. Values 0x80-0xFF are for Private Use. New assignments in 0x00-0x7F require Standards Action [RFC8126]. 9.3. EAP-WSIM Error Code Registry IANA is requested to create a new registry titled "EAP-WSIM Error Codes" with initial values from Section 5.8. New assignments require Standards Action [RFC8126]. 9.4. MILENAGE-ECDH-FWD Construction Version Registry IANA is requested to create a new registry titled "MILENAGE-ECDH- FWD Construction Versions" to track versions of the construction defined in Section 4. The info string "MILENAGE-ECDH-FWD-v1" (21 bytes, UTF-8) is the initial entry. New entries require Standards Action [RFC8126]. 10. Security Considerations 10.1. Security of MILENAGE-ECDH-FWD The security of MILENAGE-ECDH-FWD rests on: (a) the security of MILENAGE [TS35.205]; (b) the hardness of the ECDLP on P-256 [FIPS186]; and (c) the security of HKDF-SHA-256 [RFC5869]. As analyzed in Section 4.5, compromise of either component individually does not yield session keys. 10.2. Long-Term Key Storage K MUST be stored on a hardware security element (SIM card or equivalent) on both Server and Peer. Software-only K storage is strongly discouraged. 10.3. Ephemeral Key Lifecycle Ephemeral P-256 private keys MUST be generated using a cryptographically secure random number generator and MUST be securely zeroized immediately after the ECDH shared secret SS is computed. SS itself MUST be zeroized after K_session is derived. 10.4. K_mac_start Security Properties K_mac_start = HMAC-SHA-256(K, "WSIM-START-MAC-v1" || RAND) provides integrity for WSIM-Start but not forward secrecy. An adversary who later learns K can verify that a captured WSIM-Start was genuine, but cannot derive session keys (which require the ephemeral ECDH private key, which has been discarded). This is an acceptable trade-off: the first message must be sent before full session keys are available, and K_mac_start prevents injection of malicious WSIM-Start messages. 10.5. MILENAGE AMF Field Implementations SHOULD use a distinct AMF value for EAP-WSIM to prevent cross-protocol attacks per [TS33.102]. 10.6. Sequence Number Management The MILENAGE SQN counter MUST be maintained persistently across power cycles. Loss of SQN state requires re-synchronization using the AUTS mechanism per [TS33.102]. 11. Privacy Considerations The EAP outer identity (EAP-Response/Identity) SHOULD use a pseudonym or temporary NAI rather than the permanent IMSI. Unlike EAP-SIM [RFC4186], EAP-AKA [RFC4187], EAP-AKA' [RFC9048], and EAP-AKA' FS [RFC9678], EAP-WSIM does not cause any RADIUS or Diameter requests to be sent to MNO infrastructure. There is therefore no MNO-observable authentication event that could be used to track subscriber activity across venues. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- Expand Key Derivation Function (HKDF)", RFC 5869, May 2010. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "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. [TS35.205] 3GPP, "3G Security; Specification of the MILENAGE Algorithm Set: An example algorithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*", 3GPP TS 35.205. [FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-5, February 2023. 12.2. Informative References [RFC2865] Rigney, C., et al., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for GSM Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006. [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006. [RFC5448] Arkko, J., Pauly, D., Haverinen, H., and J. Salowey, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, May 2009. [RFC6733] Fajardo, V., et al., "Diameter Base Protocol", RFC 6733, October 2012. [RFC9048] Arkko, J., et al., "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", RFC 9048, October 2021. [RFC9190] Preuß Mattsson, J. and M. Tiru, "EAP-TLS 1.3", RFC 9190, February 2022. [RFC9678] Arkko, J., Norrman, K., and J. Preuß Mattsson, "Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)", RFC 9678, March 2025. [TS33.102] 3GPP, "3G Security; Security Architecture", 3GPP TS 33.102. [IEEE80211] IEEE, "IEEE Standard for Information Technology -- Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2020. [WSIM-KEY-SELECT] Gupta, P., "WSIM Key Slot Selection: Non-Reversible Time-of-Day IMSI-Bound Key Bundle Management for EAP-WSIM", Work in Progress, draft-gupta-emu-wsim-key-select-00, 2026. [WSIM-FT] Gupta, P., "EAP-WSIM Integration with IEEE 802.11r Fast Transition Key Pre-Distribution", Work in Progress, draft-gupta-emu-wsim-ft-00, 2026. Appendix A. MILENAGE-ECDH-FWD Test Vectors The following test vectors verify Section 4 independently. MILENAGE parameters use 3GPP TS 35.208 Test Set 1 values. Reference implementation: gen_testvecs.py (contact author). The P-256 keypairs in A.5 were generated for this document. Implementations MUST generate fresh keypairs per session. A.1. MILENAGE Input Parameters K (MILENAGE root key, 16 bytes): 465B5CE8B199B49FAA5F0A2EE238A6BC OP (operator variant algorithm key, 16 bytes): CDC202D5123E20F62B6D676AC72CB318 OPc (derived: AES_K(OP) XOR OP, 16 bytes): CD63CB71954A9F4E48A5994E37A02BAF RAND (random challenge, 16 bytes): 23553CBE9637A89D218AE64DAE47BF35 SQN (48-bit sequence number, 6 bytes): FF9BB4D0B607 AMF (Authentication Management Field, 2 bytes): B9B9 A.2. MILENAGE Sub-Function Outputs NOTE: f2 (RES), f3 (CK), f4 (IK), and f5 (AK) have been verified against 3GPP TS 35.208 Test Set 1 and match exactly. f1 (MAC_A, MAC_S) uses the formula: TEMP XOR rot(IN1 XOR OPc, 8 bytes), where TEMP = AES_K(RAND XOR OPc) and IN1 = SQN || AMF || SQN || AMF. Cross-verification of f1 against TS 35.208 is deferred to -01. f1 MAC_A (8 bytes): 4A9FFAC354DFAFB3 f1* MAC_S (8 bytes): 01CFAF9EC4E871E9 f2 RES (8 bytes): A54211D5E3BA50BF TS35.208 ref: A54211D5E3BA50BF [MATCH] f3 CK (16 bytes): B40BA9A3C58B2A05BBF0D987B21BF8CB TS35.208 ref: B40BA9A3C58B2A05BBF0D987B21BF8CB [MATCH] f4 IK (16 bytes): F769BCD751044604127672711C6D3441 TS35.208 ref: F769BCD751044604127672711C6D3441 [MATCH] f5 AK (6 bytes): AA689C648370 TS35.208 ref: AA689C648370 [MATCH] A.3. AUTN Construction and K_mac_start SQN XOR AK (6 bytes): 55F328B43577 AUTN = (SQN XOR AK) || AMF || MAC_A (16 bytes): 55F328B43577B9B94A9FFAC354DFAFB3 K_mac_start derivation: label = "WSIM-START-MAC-v1" (17 bytes) 5753494D2D53544152542D4D41432D7631 input = label || RAND (33 bytes) K_mac_start = HMAC-SHA-256(K, input) (32 bytes): C68233159C2A1B7A84CB3DD0172CD17A 76EFF79600485FA66F1277158B6AC799 A.4. Session Nonces NONCE_S (server nonce, 16 bytes): 5A8D3F2B1C9E7041A6D5E4F3B2C1A090 NONCE_P (peer nonce, 16 bytes): A1B2C3D4E5F60718293A4B5C6D7E8F90 A.5. P-256 ECDH Key Exchange NOTE: These keypairs are example values for vector verification. Production implementations MUST generate fresh keypairs per session using a CSPRNG. Server private scalar d_S (32 bytes): 6432A7B71C016E45760781F9E921C923 66B2CEC9F77B78CE659CB88FA27E9BEC Server public key pk_S (uncompressed format: 0x04 || x || y): 04 x: 47775180089DDE81621F8B86EEB57F3F DCDE3E81512734F0E505DDC9724B1FCD y: EF7A5534D815387A06E63CF3507E0F40 41B5DAFE4B02B3FD259C3515ED6E5DEE Peer private scalar d_P (32 bytes): 874120DD6BA2F6E547A1E9B4C04AE761 320C87ECEFD0C022F9124F300A66CAB1 Peer public key pk_P (uncompressed format: 0x04 || x || y): 04 x: 4097F2E695DCA36726D00324E4AB1EE8 49A0FD08F97D523E056781B37B13EA3C y: 4795796AACBAC948202F5B3871CB9AF0 EEEA5ECD468171B4DF2E9E306133465E SS = P256-ECDH(sk_S, pk_P) = P256-ECDH(sk_P, pk_S) (32 bytes): 5B073428B4D4CE1AF5194DAF5015FF4F 6FD2AE2D5A442B3F2546B9C39E029571 A.6. HKDF-SHA-256 Key Derivation IKM = SS || CK || IK (64 bytes total): 5B073428B4D4CE1AF5194DAF5015FF4F6FD2AE2D5A442B3F2546B9C39E029571 B40BA9A3C58B2A05BBF0D987B21BF8CB F769BCD751044604127672711C6D3441 salt = NONCE_S || NONCE_P (32 bytes): 5A8D3F2B1C9E7041A6D5E4F3B2C1A090A1B2C3D4E5F60718293A4B5C6D7E8F90 info = "MILENAGE-ECDH-FWD-v1" (21 bytes): 4D494C454E4147452D454344482D4657442D7631 L = 128 bytes OKM = HKDF-SHA-256(IKM, salt, info, 128): [ 0: 32] 928815EBF4B5498A77A19DB6A04B9EFB 439A604B7DC6DD558C920E4D067E21EF [ 32: 64] 26C8BA4802C95CF3AB3D49C7B9688019 2F8F931CACC2405F52186A99DCD4A95D [ 64: 96] 996AF0830F1FD6AD4C0450563568EAE4 7DD5E09ED9847379CA3D13A22D0C80F2 [ 96:128] 2D682081C8A223628E2C54F449D71F35 7741CE07737EEA89B2F422D77C132B48 A.7. Output Key Material MSK = OKM[0:64]: [0:32] 928815EBF4B5498A77A19DB6A04B9EFB 439A604B7DC6DD558C920E4D067E21EF [32:64] 26C8BA4802C95CF3AB3D49C7B9688019 2F8F931CACC2405F52186A99DCD4A95D EMSK = OKM[64:96]: 996AF0830F1FD6AD4C0450563568EAE4 7DD5E09ED9847379CA3D13A22D0C80F2 K_auth = OKM[96:112]: 2D682081C8A223628E2C54F449D71F35 K_confirm = OKM[112:128]: 7741CE07737EEA89B2F422D77C132B48 PMK (for IEEE 802.11r R0KH) = MSK[0:32]: 928815EBF4B5498A77A19DB6A04B9EFB 439A604B7DC6DD558C920E4D067E21EF A.8. Message Authentication Codes AT_MAC (WSIM-Start): Input = RAND || AUTN || NONCE_S (48 bytes) Key = K_mac_start AT_MAC = HMAC-SHA-256(K_mac_start, input) (32 bytes): 6A915CDDEFF2221755385D5D296ED5C9 1A384AC8F80B18BFB40FF4B11BA779BD AT_MAC_PEER (WSIM-Challenge): Input = RES (8B) || 0x04 || pk_P.x (32B) || pk_P.y (32B) || NONCE_P (16B) Key = K_auth AT_MAC_PEER = HMAC-SHA-256(K_auth, input) (32 bytes): EEFD2907053B10545559295B1B69172E 5AD03B21711361A90F467BB22F9D15A5 AT_MAC_CONFIRM (WSIM-Confirm): Input = "WSIM-CONFIRM-v1" || RAND || NONCE_S || NONCE_P Key = K_confirm AT_MAC_CONFIRM = HMAC-SHA-256(K_confirm, input) (32 bytes): D469BB2CCCD9C2D0F90B4C998E94B6C4 1136D0744E7C680DCD3B36E3A2785316 A.9. Test Vector 2: Session Independence Purpose: Verify that a different RAND with the same K produces a completely different MSK, confirming session independence. RAND2 = 9F7C8D556B7BE5A1234CBF89D3E4A150 NONCE_S2 = 11223344556677889900AABBCCDDEEFF NONCE_P2 = FFEEDDCCBBAA00998877665544332211 SS2 (fresh ECDH, different ephemeral keys): 3AA3A1D8B2A311C3AA7EDBB9BD0AFE3B 05A2B276164A67A202BBB1A8A7727222 MSK2[0:32]: 7C6497F0DF26A49FCC3FB98F1ADBC2B2 4C00A83A0CAD60578A39F3ACE87167BD MSK2[32:64]: 8EB2ECD1A936A744F71A3B214040CD58 3C6265D8311D43AA09EB9FA1AD7FC8F4 MSK1 != MSK2: TRUE (session independence verified) Appendix B. Comparison with Prior EAP SIM-Based Methods B.1. EAP-SIM (RFC 4186) EAP-SIM uses GSM triplets and requires HLR contact for each exchange. It provides no mutual authentication (the network is not authenticated to the UE) and no forward secrecy. EAP-WSIM provides offline operation, full mutual authentication, and forward secrecy. B.2. EAP-AKA (RFC 4187) EAP-AKA uses MILENAGE/UMTS AKA and provides mutual authentication but requires AuC/HLR contact and provides no forward secrecy. EAP-WSIM uses the same MILENAGE mutual authentication but eliminates the backend dependency and adds forward secrecy via MILENAGE-ECDH-FWD. B.3. EAP-AKA' (RFC 9048) EAP-AKA' improves key derivation over EAP-AKA using a SHA-256- based PRF but still requires UDM/AuC contact and provides no forward secrecy. EAP-WSIM: offline, adds forward secrecy. B.4. EAP-AKA' FS (RFC 9678) RFC 9678 adds ECDH forward secrecy to EAP-AKA' as an optional extension. It is the most similar existing specification. The critical distinction is that RFC 9678 still requires MNO Authentication Database contact for every authentication event; EAP-WSIM requires no MNO backend contact at any time. See Section 7 for a complete technical comparison. RFC 9678 and EAP-WSIM are complementary, not competing. RFC 9678 is appropriate when MNO infrastructure is available and the operator controls both sides of the authentication. EAP-WSIM is appropriate when offline operation is required, when the enterprise does not have an MNO backend relationship, or when authentication latency or availability guarantees cannot be met by the MNO. B.5. Named Construction None of the prior SIM-based EAP methods define their use of MILENAGE and (where applicable) ECDH as a named, reusable construction. EAP-WSIM introduces MILENAGE-ECDH-FWD (Section 4) as an explicitly named primitive with independently stated security properties (Section 4.5). This enables independent cryptographic analysis and potential reuse in non-EAP protocols. B.6. Key Slot Management EAP-SIM, EAP-AKA, EAP-AKA', and EAP-AKA' FS all use a single root key per subscriber. Compromise of that key requires physical re-provisioning of all UE SIMs. EAP-WSIM supports a multi-slot key bundle with independent per-slot revocation and server-side rotation, without requiring any update to pre-provisioned UE SIMs. This is specified in [WSIM-KEY-SELECT]. Appendix C. Future Work C.1. Key Slot Selection (draft-gupta-emu-wsim-key-select) A non-reversible, Time-of-Day and IMSI-bound algorithm to select the active key slot from the bundle, enabling hourly rotation without UE SIM re-provisioning and without leaking subscriber identity through the slot index sequence. C.2. IEEE 802.11r Fast Transition (draft-gupta-emu-wsim-ft) Specification of how the EAP-WSIM MSK is used by a co-located IEEE 802.11r R0KH to pre-distribute per-AP PMK-R1 at authentication time, enabling Fast Transition roaming at 30-80ms without any RADIUS backend contact during the transition. C.3. Ciphersuite Negotiation Algorithm agility to support future 256-bit MILENAGE variants and alternative elliptic curves (P-384, P-521). C.4. Fast Reconnect Session resumption without a full four-round exchange, preserving forward secrecy properties. C.5. Post-Quantum Hybrid Variant A hybrid variant combining MILENAGE-ECDH-FWD with a post-quantum KEM (Key Encapsulation Mechanism) per [FIPS203] to maintain security against a cryptographically relevant quantum computer. C.6. TPM-Based Server Deployment Option An alternative deployment where the Server (MEA) uses a hardware TPM 2.0 module rather than a SIM card for master key storage. In this variant: o K_SLOT is stored under a TPM 2.0 non-migratable key object with persistent handle 0x81000001. o K_UE derivation occurs via TPM2_HMAC using the bound key, ensuring K_SLOT never appears in cleartext outside the TPM. o Server authentication to the Peer uses an EAP-TLS exchange with the TPM-backed operator certificate (instead of the WSIM card's MILENAGE-based AUTN). o MNO remote provisioning (ECDH-attested enrollment) is required for the TPM option. The SIM-based deployment option requires only offline trust anchor provisioning. Both deployment options produce an identical MSK and are transparent to the Peer (UE SIM). The TPM option is described in the companion patent disclosure and may be specified as a separate profile if WG interest warrants it. Author's Address Praveen Gupta MobileStack Email: pgupta@mobilestack.com URI: https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/