Peter, You are correct that MNO devices on enterprise Wi-Fi today use IPsec tunnels for VoWiFi over whatever connectivity is available. EAP-WSIM does not change that tunnel — it addresses what happens at the 802.11 layer when the device moves between APs.
On a guest SSID there is no PMK, no PMK-R0, and therefore no 802.11r fast transition regardless of device capability. Every AP crossing requires a full re-exchange — 1,800–2,900 ms — enough to drop any active VoWiFi call. EAP-WSIM derives PMK-R0/R1 locally at the MEA, enabling sub-50ms transitions with no MNO backend involvement. Implementing 802.11r using enterprise credentials such as EAP-TLS achieves fast handoff, but requires deploying a full enterprise PKI and enrolling every MNO device — including unmanaged visitors and contractors — before they can connect. That is a significant operational cost for devices the enterprise does not own. More importantly, it solves only the handoff latency problem while leaving the application layer completely disconnected from the MNO — the enterprise still cannot classify VoWiFi flows for WMM AC_VO priority or enforce per-subscriber policy. Investing in enterprise PKI infrastructure for a partial solution is neither proportionate nor sufficient. There is a deeper issue: today MNOs do not enforce Wi-Fi implementation compliance on their devices the way they enforce 4G/5G stack compliance. Wi-Fi is treated as an independent layer outside MNO control, which is why 802.11r support is inconsistent across device vendors in the first place. EAP-WSIM changes this dynamic. Because authentication uses MNO-provisioned SIM credentials, MNOs gain a mechanism to enforce 802.11r compliance across device vendors as part of device certification — the same way they enforce cellular stack compliance today. Consistent fast roaming across all MNO devices becomes achievable not by hoping vendors implement it correctly, but by making it a certification requirement. EAP-WSIM delivers both in a single authentication event: zero-touch SIM-based onboarding, PMK-R0/R1 fast handoff at the AP infrastructure layer without device changes, and MNO subscriber identity surfaced at 802.11 association for per-device QoS and policy. This is the integrated Wi-Fi and MNO application layer that enterprises need for their MNO devices — and that no existing solution provides. Regards, Praveen Gupta [email protected]<mailto:[email protected]> From: [email protected] <[email protected]> Sent: Thursday, July 2, 2026 10:36 PM To: Praveen Gupta <[email protected]> Cc: [email protected] Subject: RE: [Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM) Yes, I would expect most enterprise users to have enterprise Wi-Fi credentials, not MNO-provided credentials. I had assumed you were trying to deal with a Trusted Access Wi-Fi scenario, as otherwise I couldn’t imagine why the MNO would be involved in the authentication. I understand that in untrusted access VoWiFi scenarios, the MNO creates a VPN on top of non-trusted Wi-Fi connections. IEEE 802.11r handoffs could be involved, but they should be transparent to the MNO as we’re talking IPsec links. Thanks for the explanation. It is helpful. -Peter From: Praveen Gupta <[email protected]> Sent: Thursday, July 2, 2026 2:34 PM To: [email protected] Cc: [email protected] Subject: Re: [Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM) Most enterprise users use their own wifi credentials to connect to WiFi. MNO devices are NOT using EAP-AKA as MNO does not typically connect to ENTERPRISE RADIUS. MNO Creates VPN On Top of Independent wifi connection. 802.11r handoff is not used in such implementations. Proposed method is not an entirely new proposal / protocol. It leverages EAP-AKA and improve on it using locally hosted MNO derived keys. This makes MNO TRAFFIC visible to wifi network with required QoS support. This is done in same way as 4G SIM AUTHENTICATION evolved into 5G SIM (which added mutual authentication instead of 4G device authentication only) I hope this helps. Thanks Praveen On Jul 2, 2026, at 3:37 PM, [email protected]<mailto:[email protected]> wrote: What I am saying is that you do the MNO authentication upfront (with a traditional EAP-based SIM authentication), then use IEEE 802.11r for fast transition between the APs. I understand you’re proposing a different method. I am trying to understand why you feel your method is necessary. I have no opinion either way, I just want to know where you feel IEEE 802.11r fails after use of some other SIM authentication method. -Peter From: Praveen Gupta <[email protected]<mailto:[email protected]>> Sent: Thursday, July 2, 2026 11:19 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Guilin Wang <[email protected]<mailto:[email protected]>> Subject: Re: [Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM) No. We are doing local EAP authentication and derive keys for 802.11r which are shared / available to AP for fast roaming with device. Thanks Praveen On Jul 2, 2026, at 2:00 PM, [email protected]<mailto:[email protected]> wrote: Wouldn’t use of IEEE 802.11r obviate the need to perform another IEEE 802.1X exchange with the MNO during each transition? IEEE 802.11r should take transition times down to ~50 ms range. -Peter From: Praveen Gupta <[email protected]<mailto:[email protected]>> Sent: Thursday, July 2, 2026 9:26 AM To: Guilin Wang <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Guilin Wang <[email protected]<mailto:[email protected]>> Subject: [Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM) Hello, I appreciate your feedback. Thank you for the review. Let me address the core questions. As I understand the problem, it is that the MNOs do not offer any open way for enterprise systems to authenticate over RADIUS. The problem is more fundamental than API access. MNOs actively protect HLR/HSS/UDM as a security perimeter — no MNO will permit an enterprise to originate MAP/Diameter/SBI queries directly. More importantly: MNO subscribers already offload to enterprise Wi-Fi today, but do so using separate enterprise credentials (captive portals, guest SSIDs) with no relationship to their MNO subscription. The MNO loses all policy visibility, QoS control, and service continuity the moment the device touches enterprise Wi-Fi. When that subscriber moves between APs on a VoWiFi call, re-authentication takes 1,800–2,900 ms — a guaranteed dropped call every time. This is the current production reality in virtually every enterprise deployment. What MNOs are going to be actively interested in doing this? MNOs are already experiencing this pain — they bear subscriber complaints for VoWiFi call drops on infrastructure they have no control over. But beyond the quality problem, placing the MNO in the active authentication loop for enterprise Wi-Fi offload is not architecturally viable at scale. A single MNO may have subscribers offloading across tens of thousands of enterprise venues simultaneously. Requiring a live HSS/HLR round-trip for every 802.1X authentication event across that estate is operationally and economically unrealistic — the MNO backend was never designed to serve as a real-time RADIUS endpoint for arbitrary third-party venues. This is precisely why an offline, venue-hosted solution is the correct architecture: the MNO provisions once, the MEA authenticates locally indefinitely, and the MNO backend is never in the per-authentication critical path. If I was trying to solve this, I'd work with an MNO to enable a vetted on-prem RADIUS proxy. This assumes MNOs would be receptive to opening their authentication infrastructure to enterprise venues. In practice, the opposite is true — and for well-understood reasons. An MNO's HLR/HSS/UDM is among the most tightly controlled infrastructure in any operator network. It holds Ki for every subscriber. Permitting an enterprise venue to originate authentication queries against it — even through a vetted proxy — means the MNO must now trust the security posture, availability, and operational integrity of every enterprise it connects to. A single compromised enterprise proxy becomes a vector into the MNO's subscriber identity infrastructure. No MNO security or legal team will accept that exposure. This is not a business negotiation problem; it is a fundamental trust boundary. Beyond the security perimeter: a single MNO has subscribers offloading across tens of thousands of enterprise venues simultaneously. Routing every 802.1X authentication event for every Wi-Fi offload session through a live HLR/HSS round-trip across that entire estate is not operationally viable. The MNO authentication backend was never dimensioned for this traffic pattern. And even if both of those objections were somehow resolved, a RADIUS proxy still cannot solve the problem this draft addresses. Fast intra-enterprise handoff requires PMK-R1 key material to be pre-positioned at the target AP before the roam occurs — that requires a local R0 Key Holder on the enterprise edge. With a proxy, the MSK is produced on the MNO-side server; there is no local entity to derive and distribute PMK-R1 to enterprise APs. Every AP transition for a VoWiFi call would still require a full MNO round-trip, costing 1,800–2,900 ms — a guaranteed dropped call. The fast handoff problem is structurally unsolvable with a proxy architecture, regardless of how the proxy is vetted or provisioned. Why are there any protocol changes required? Because every existing SIM-based EAP method — EAP-SIM, EAP-AKA, EAP-AKA', EAP-AKA' FS — requires a live query to the subscriber's home HSS/HLR/UDM to obtain RAND/AUTN/XRES. No query, no authentication. EAP-WSIM replaces that live query with a WSIM SIM card acting as a self-contained Authentication Centre on the enterprise edge. That replacement requires a new protocol. Thanks Praveen On Jul 2, 2026, at 12:10 PM, Wang Guilin <[email protected]<mailto:[email protected]>> wrote: Is it possible to just pretend or make the so called WSIM hardware authenticator functoning as the MNO backend infrastructure (HSS, HLR, UDM, or AuC), rather than to build a new protocol? If this can be done, clients can visit an enterise WiFi via running any of the followings to complete AKA: EAP-SIM, EAP-AKA, EAP-AKA', and EAP-AKA' FS, as your draft mentioned. Those AKA methods are designed for the backend authenticator apart from the AP. Your case here seemingly means that the hardware authenticator is just inside of the same device with the AP. So, it looks simpler, as low level protocol layers may not need at all. Forgive me if I misunderstood the problem proposed here. Guilin 发件人：Praveen Gupta <[email protected]<mailto:[email protected]>> 收件人：[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 时 间：2026-06-16 02:13:22 主 题：[Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM) Hello All, I would appreciate your interest and feedback on this very important solution gap for MNO-devices offloading to Enterprise-WIFI. https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/ ─── The Problem Gap ─────────────────────────────────────────── MNO subscribers—employees, contractors, and visitors—enter enterprise campuses carrying MNO-issued SIM credentials every day. Enterprise Wi-Fi networks currently have no standardized way to authenticate these devices using operator-issued identity without one of the following costly dependencies: a) A live AAA/Diameter/RADIUS path back to the MNO's HSS/HLR/UDM (EAP-SIM, EAP-AKA, EAP-AKA'), or b) Per-user credential provisioning by the enterprise (certificates, passwords, captive portals). This means that for the overwhelming majority of enterprise deployments—which have no bilateral agreement with each visiting subscriber's MNO—MNO devices cannot be securely and seamlessly offloaded to enterprise Wi-Fi using existing SIM-based EAP methods. The gap is particularly acute for: • Visitors and contractors arriving with unknown-MNO SIMs • Air-gapped or regulated environments without external AAA paths • VoWiFi continuity requiring 802.11r fast-transition keying that existing guest/captive-portal models cannot deliver • Enterprises that need MNO-grade mutual authentication without standing up MNO federation infrastructure For security reasons, MNO do not connect Enterprise-RADIUS to their Authentication center. MNO’s Authentication center is kept extremely secure as it has sensitive subscriber data. This make user experience / MNO-device experience in Enterprise WIFI extremely bad specially when mobility between multiple WIFI-AP is needed. ─── What EAP-WSIM Addresses ────────────────────────────────── EAP-WSIM proposes a venue-side Wireless SIM (WSIM) hardware authenticator approved by the MNO, which holds keying material on-card and runs MILENAGE-ECDH-FWD entirely offline—without contacting the MNO backend during authentication. Key properties: • Offline mutual authentication using operator-provisioned WSIM hardware • Forward secrecy via ephemeral P-256 ECDH combined with MILENAGE • 802.11r PMK/FT-Key derivation enabling fast BSS transitions for VoWiFi • Protection against rogue enterprise authenticators (BAD-MEA) • No MNO-enterprise AAA federation required This is complementary to RFC 9678 (which adds forward secrecy to MNO-connected flows). EAP-WSIM specifically targets the offline / no-MNO-backend case. ─── Benefits by Stakeholder ────────────────────────────────── For enterprise employees: Zero-touch onboarding to the corporate Wi-Fi using their existing MNO SIM—no certificate enrollment, no password, no captive portal. For visitors / external MNO devices: Secure, operator-grade Wi-Fi access without the enterprise needing a relationship with the visitor's MNO. Mutual authentication prevents rogue APs from impersonating the enterprise. For enterprises: A single WSIM-provisioned authenticator (MEA) supports any MNO subscriber without per-operator AAA integration. Operator policy, SSID identity, and charging correlation hooks are preserved. ─── Request ────────────────────────────────────────────────── I welcome review and discussion on: 1. Whether the problem statement and gap analysis resonate with the WG 2. Technical comments on the MILENAGE-ECDH-FWD construction and key derivation 3. Relationship to ongoing EAP method work in the WG 4. Interest in co-authoring or adopting as a WG item The draft includes full protocol spec, test vectors verified against 3GPP TS 35.208 Test Set 1, RFC 3748 §7.2 security claims, and IANA considerations. Thank you for your time. Regards, Praveen Gupta [email protected]<mailto:[email protected]> https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/ From: Praveen Gupta Sent: Friday, May 29, 2026 11:50 AM To: [email protected]<mailto:[email protected]> Subject: [Emu] New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM) Hi all, I have submitted an individual Internet-Draft proposing a new EAP authentication method for enterprise wireless networks: Title: EAP-WSIM: A SIM-Based EAP Method Using the MILENAGE-ECDH-FWD Authentication Construction Draft: draft-gupta-emu-eap-wsim-00 URL: https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/ Background EAP-SIM, EAP-AKA, EAP-AKA', and EAP-AKA' FS (RFC 9678) all require the EAP server to contact MNO backend infrastructure (HSS, HLR, UDM, or AuC) during each authentication exchange. This dependency makes them unsuitable for air-gapped enterprise environments, manufacturing facilities, defence networks, or any deployment where MNO backend connectivity cannot be guaranteed. EAP-WSIM removes this dependency entirely. Core Innovation The EAP server holds a SIM card (the WSIM) that acts as a self-contained Authentication Centre. It holds master key material on-card, derives per-subscriber MILENAGE keys on-card, generates authentication vectors on-card, and verifies subscriber responses on-card — with no MNO network contact at any point. The cryptographic core is a new named construction, MILENAGE-ECDH-FWD, which combines MILENAGE mutual authentication with ephemeral P-256 ECDH key agreement. This construction simultaneously provides: - Mutual authentication (via MILENAGE AUTN/RES) - Forward secrecy (via ephemeral ECDH, discarded post-session) - Offline operation (no MNO backend contact) By defining MILENAGE-ECDH-FWD as an explicitly named construction (rather than an ad-hoc combination), the draft enables independent cryptographic analysis and potential reuse in non-EAP protocols. Relationship to RFC 9678 (EAP-AKA' FS) RFC 9678 and EAP-WSIM are complementary, not competing. RFC 9678 adds forward secrecy to EAP-AKA' for MNO-connected deployments. EAP-WSIM targets deployments where MNO backend contact is not available or not acceptable. Section 7 of the draft provides a detailed technical comparison. Draft Contents - Four-round protocol exchange (WSIM-Start, WSIM-Challenge, WSIM-Confirm, WSIM-Complete) - Complete MILENAGE-ECDH-FWD construction specification - Full attribute TLV encodings (15 attribute types) - Key derivation chain: K_UE → MILENAGE → ECDH → MSK/EMSK - RFC 3748 Section 7.2 security claims (all 14 properties) - Complete test vectors (verified against 3GPP TS 35.208 Test Set 1) - IANA considerations for EAP type and three new registries - Optional pre-association certificate exchange for rogue AP prevention Two companion drafts (key slot management and 802.11r Fast Transition integration) are referenced but will be submitted only if the WG indicates interest. IPR US Provisional Patent Application 64/048,069 covers aspects of this architecture. The author commits to RAND-z licensing (royalty-free) for any RFC produced from this document, per BCP 79 / RFC 8179. An IPR disclosure has been filed at the IETF datatracker. I welcome review and discussion from the WG. Regards, Praveen Gupta [email protected]<mailto:[email protected]> https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
