Michael, Thank you — your questions identify exactly what the draft needs to explain more clearly. Let me address the core concern directly. I am preparing a -01 revision that will address the feedback received to date. I will submit -01 to the datatracker shortly. I hope to clarify more during IETF126 session as Peter Yee has bee gracious to accept my request and give me 10 min at the end of the session.
─── How the WSIM-AS Gets Access to SIM Credentials ─────────────────── The WSIM-AS is not enterprise-built software with an API call to the MNO. It is MNO-provisioned hardware deployed at the enterprise edge — conceptually equivalent to what the MNO's SIM personalization infrastructure does at the factory, but placed on-premises. The trust chain works as follows: 1. The MNO operates a MASTER KEY that underlies all subscriber SIM provisioning — the same root from which per-subscriber Ki values are derived when SIM cards are manufactured. 2. The MNO provisions this MASTER KEY material into the WSIM-AS security hardware (a tamper-resistant HSM or SIM-card-equivalent hardware module) out-of-band, using the same key provisioning infrastructure used for SIM card personalization. This is a one-time per-venue provisioning event, operationally equivalent to how MNOs provision eSIM profiles via GSMA Remote SIM Provisioning (SGP.02). 3. Once provisioned, the WSIM-AS hardware can derive the per-subscriber MILENAGE key material (equivalent to Ki) for any subscriber of that MNO on-demand, using only the subscriber's IMSI. The derivation: K_sub = KDF(MASTER_KEY, IMSI) — is identical in structure to how the MNO's SIM factory derives Ki for each SIM card from the operator master key. 4. The enterprise never has access to the MASTER KEY or to any subscriber key material. The key material lives inside tamper-resistant hardware and is only accessible to the MNO's provisioning process. This is the same trust model as an HSM used in payment systems: the enterprise deploys the hardware; a separate party (MNO) controls the keys inside it. So to directly answer your question: the enterprise's AAA server (the WSIM-AS) gets access to MNO subscriber credentials the same way a SIM card factory gets access to them — because the MNO provisions it. The difference from existing EAP-AKA is that the MNO provisions key material to hardware at the enterprise edge rather than responding to per-authentication queries from the enterprise over a live Diameter interface. ─── Deployability ───────────────────────────────────────────────────── Your point about Apple, Android, and Microsoft is well taken and worth addressing directly. EAP-WSIM on the device side is not a clean-sheet EAP implementation. It is EAP-AKA' (which Apple, Android, and all major platforms already implement for VoWiFi) with one additional step: ML-KEM encapsulation using a server-provided public key. The MILENAGE computation on the SIM is unchanged. The wpa_supplicant EAP-AKA' peer code requires a bounded delta — roughly the addition of ML-KEM encapsulation in the challenge-response path. MNOs already drive device vendor compliance through type approval and certification — they enforce 4G/5G stack compliance this way today. EAP-WSIM gives MNOs the same enforcement mechanism for Wi-Fi: device vendors seeking MNO certification can be required to implement EAP-WSIM correctly. This is how EAP-SIM and EAP-AKA reached universal deployment — not through open-market adoption, but through MNO certification requirements. ─── Centralized AP Controllers ──────────────────────────────────────── Your point about centralized controller architectures (Cisco, Aruba, Juniper Mist) is well taken. In those 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 distribution point for PMK-R1 rather than individual APs. The HOKEY WG work you reference is relevant prior art and will be cited in the Related Work section of the revised draft. ─── On Privacy ──────────────────────────────────────────────────────── You note that MNO traffic anonymity on enterprise Wi-Fi is by design. In a way, broken MNO voice services over WIFI is a huge pain point that MNOs want to solve. EAP-WSIM solves this problem. Proposed solution is correct from the MNO's perspective (I worked on MNO / Verizon solving these issues as MNO). EAP-WSIM does not expose subscriber identity to arbitrary enterprises — the WSIM-AS is MNO-provisioned and MNO-controlled hardware. The enterprise sees that a verified MNO subscriber is present and can apply QoS accordingly, but the identity information is mediated through MNO-controlled hardware, not enterprise software. I will submit a revised -01 draft that adds an explicit trust model section addressing these points. I also note the IETF 126 EMU session agenda — I would welcome the opportunity to present and answer questions directly. Regards, Praveen Gupta [email protected] https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/ -----Original Message----- From: Michael Richardson <[email protected]> Sent: Wednesday, July 8, 2026 10:50 AM To: Praveen Gupta <[email protected]>; [email protected] Subject: Re: [Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM) Praveen Gupta <[email protected]> wrote: > There is a lot of confusion about this contribution, and I understand > that email is NOT the best way to understand a contribution. I would > request urgent group meeting opportunity to present this contribution > and answer all the questions. You can request a presentation slot at 126, and you can do that remotely if you need to. I can't see how it's urgent for the WG. https://datatracker.ietf.org/doc/agenda-126-emu/ August 24. The 60min seems full, but maybe EAP-PSK-256 will give up 5min. I'm not the chair, I'm just a bump on a log that wrote EAP-AKA code ~20 years ago. I have two conflicts for the 126 session on Friday morning, so not sure I'll even be in the room. > This contribution is certainly NOT for just guests / contractors. This > contribution is achieving a lot of objectives. In a way, this > contribution is making MNO-traffic visible in WIFI which is anonymous > today. Well, multiple have asked simple questions about trust model, and we aren't getting answers that make any sense. > To directly answer Michael's question: EAP-WSIM does NOT require a new > credential. The credential is the SIM card the MNO device already > carries — the same credential used for 4G/5G cellular > authentication. EAP-WSIM reuses the existing MNO-provisioned SIM > credential at the Wi-Fi layer. No new enrollment, no certificates, no > passwords. Zero-touch onboarding is a direct consequence of this > design. How? If you have *NO* interface to the MNOs, then you don't have access to the secret in the SIM. Your premise was that no connection was possible. (I think you might have mentioned a co-located box operated by an MNO, but maybe that was me suggesting that) So I'm totally at a loss. You can make up new key agreement algorithms, and there a bunch of math in your document that I didn't try to follow, which suggests that you are trying to do that. New ways of doing (g^x)(g^y) do not explain how trust is created. > ─── The Real Problem: MNO Traffic is Anonymous on Enterprise Wi-Fi ──── > Today, when an MNO device connects to enterprise Wi-Fi — whether > employee, visitor, or contractor — the enterprise network has no > visibility into the fact that it is an MNO device at all. The device > connects via a guest SSID or captive portal and becomes completely > anonymous. All MNO application traffic — VoWiFi calls, MNO data flows — > travels inside an IPsec tunnel that the enterprise Wi-Fi layer cannot > inspect, classify, or prioritize. The enterprise cannot apply QoS, > cannot enforce per-subscriber policy, and cannot distinguish VoWiFi > flows from any other traffic. Yes. All of that privacy is really by design. > EAP-WSIM surfaces MNO subscriber identity at the 802.11 association > layer. For the first time, the enterprise Wi-Fi network knows which MNO > subscriber is connected, enabling per-device QoS (WMM AC_VO for > VoWiFi), policy enforcement, VLAN assignment, and charging correlation > — all anchored to a verified MNO identity, not a self-asserted DSCP > marking. And this is a new EAP method. Not EAP-TLS, EAP-TEAP, EAP-AKA, EAP-SIM... It seems quite unlikely that EAP-TEAP(vX) will get implemented in any Apple, Android or Microsoft end-systems. Maybe the commodity Linux wpa_supplicant present on my Ubuntu laptop might get new code in a few years, but I can't see how your new method will become deployable. This is a *market* reality: the market is saturated with "good enough" solutions, and it's not clear it can bear anything new, even if it's Better<tm>. > ─── The Scope: Every MNO Device in Every Enterprise ────────────────── > This is not a guest or contractor use case. It is the universal > case. Every enterprise campus today has employees, contractors, and Employees often have company issued devices, with company controlled device management. (MDM). Some contractors too. Others are *forbidden* by their actual employer from doing that. (Think the elevator repairperson in an IBM owned building) For Guests, the connection is even more tenuous, and the risk to the guest of identifyng any of their traffic seems high. > ─── The Fast Handoff Problem ────────────────────────────────────────── > On a guest SSID there is no PMK, no PMK-R0, and no 802.11r fast > transition — regardless of device capability. Every AP crossing > requires a full 802.1X re-exchange costing 1,800–2,900 ms — enough to Today it happens relatively smoothly using a TLS resumption ticket with EAP-TLS. I agree it's not fast enough to maintain a VoIP call unless the hand-off can be done as make-before-break. Most non-trivial enterprises (including University campuses) will have an AP system where actually half of the AP control plane lives in a centralized switch. In those situations, there is no real handoff, sessions are, I think, passed between APs. I think we the worked on this in: https://datatracker.ietf.org/wg/hokey/about/ and I think that it would/could have been the IETF standard way of doing the centralized AP thing. I don't know if anyone implemented/deployed. > across chipsets, OEMs, and OS versions — carrier-locked firmware, > driver bugs, and OS-level suppression mean that a device may advertise > FT capability but fail to negotiate it correctly. EAP-WSIM changes > this: because authentication uses MNO-provisioned SIM credentials, MNOs How does the Enterprise's AAA server get access to the MNO-provisioned SIM credentials? I think you wrote something about a co-located box? I asked which MNOs were planning to offer that? -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours ** _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
