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. > Has MILENAGE-ECDH-FWD been to CFRG? It doesn't sound quantum-safe. CFRG submission is the intended next step pending initial EMU WG feedback, and I would welcome that review. On quantum safety: the framing of the question warrants examination. No currently deployed MNO SIM-based EAP method is quantum-safe. EAP-SIM uses HMAC-MD5/SHA1-based PRFs over a shared symmetric key. EAP-AKA and EAP-AKA' use MILENAGE, whose f1–f9 functions are built on AES-128 — providing approximately 64 bits of security against a quantum adversary via Grover's algorithm, not 128. Critically, none of these methods provide forward secrecy: compromise of the long-term shared key Ki retroactively exposes all past sessions. To be precise about EAP-WSIM's current construction: ECDH P-256 is not quantum-safe. Shor's algorithm running on a sufficiently capable quantum computer breaks elliptic curve discrete logarithm efficiently, meaning the forward secrecy guarantee does not hold in a post-quantum threat model. The MILENAGE component (AES-128) retains approximately 64-bit security under Grover, consistent with EAP-AKA. However, EAP-WSIM is a new protocol. Unlike EAP-AKA and EAP-AKA', which carry the design constraints of 2G/3G-era SIM hardware, EAP-WSIM has no legacy deployment to preserve compatibility with. We therefore intend to update the construction to replace ECDH P-256 with ML-KEM (FIPS 203) as the key encapsulation mechanism, making EAP-WSIM the first SIM-based EAP method to provide both offline mutual authentication and post-quantum forward secrecy. This is the right moment to build this correctly — standardizing a new method with known quantum vulnerability would be a missed opportunity. If the WG has a view on ML-KEM parameter selection or hybrid classical/PQ construction, that input would be welcome as part of this discussion. > How/why do client systems trust this local server? Through pre-association validation (BAD-MEA guard): the MNO application on the UE validates a hardware-backed MEA identity proof against the MNO's own CA before any EAP exchange begins. A rogue authenticator without a valid MNO-issued certificate is refused before any SIM credential is disclosed. Happy to go deeper on any of these. Draft: https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/ Praveen Gupta [email protected] -----Original Message----- From: Michael Richardson <[email protected]> Sent: Wednesday, June 17, 2026 10:48 AM To: Praveen Gupta <[email protected]>; [email protected] Subject: Re: [Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM) I've only browsed your I-D. Praveen Gupta <[email protected]> wrote: > I would appreciate your interest and feedback on this very important > solution gap for MNO-devices offloading to Enterprise-WIFI. As I understand the problem, it is that the MNOs do not offer any open way for enterprise, (or other EAP-SIM capable systems) to authenticate over radius. I'm not seeing how anything you've proposed solves that problem. > ─── 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: Sounds like an interesting product/service. I don't know why it a "hardware authenticator" vs a virtual appliance to be run on-prem. What MNOs are going actively interested in doing this? I think it's gonna be a pretty hard-sell to almost every CFO. The people/enterprises who would most benefit from this, are likely least able to use it. > 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. I guess, backend through the MNO to the mobile (formerly "SS7") network. If I was trying to solve the problem as you outlined, then I'd be working with an MNO to enable them to offer some kind of vetted onboarding for an on-prem radius proxy. > 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 Why are there any protocol changes required? Which desktop/mobile OS vendors have committed to implementing EAP-WSIM? Why isn't EAP-SIM/AKA/AKA' with a radius proxy into the MNO enough? To me, this looks like MILEANGE-ECDH-FWD looking for a problem that it can solve. } No MNO backend } contact occurs at any point during the authentication exchange. So what really is the point? Does the EAP server have a "WSIM" per subscriber? How are those related to the (E)SIM card in my phone from my carrier? Has MILEAGE-ECDH-FWD been to CFRG? It doesn't sound quantum-safe to me. While EAP-AKA is essentially shared symmetric key, so it is. How/why do client systems trust this local server? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
