Michael, A few corrections that I think dissolve most of this thread rather than needing a "SIM-proxy" split.
On "MNO would never provision master key material": the WSIM MASTER KEY is not a global Ki-derivation root. It's SSID-scoped — the AS-Server HSM only accepts MASTER KEYS derived for a specific SSID/venue, so a compromise is bounded to that deployment, not the MNO's subscriber base. Revocation uses a 25-slot structure: a compromised slot is deprecated via a routine provisioning update to the AS-Server-HSM, using the same secure applet-update mechanism MNOs already use for SIM/eSIM key management today. This isn't a new trust primitive — it's the existing OTA key-management model, applied to a box at the enterprise edge instead of a card in a phone. On "SIM-proxy" as a framing: I'd push back on the premise. The SIM card in a device isn't a proxy either — it's an authentication entity that the MNO remotely manages and updates via on-card applets. The WSIM-AS is the same category of entity: MNO-provisioned, MNO-updatable, tamper-resistant hardware, just deployed at the venue instead of in a handset. There's no live per-authentication interface to the MNO backend because — as you note — MNOs explicitly don't want to be in that loop. That's the design goal, not a gap. On multi-MNO: each MNO's MCC/MNC maps to a separate AS-Server instance. A Rogers-provisioned box only ever authenticates Rogers subscribers; Videotron deploys its own. A multi-carrier venue runs multiple AS-Servers side by side — operationally similar to running multiple SSIDs today, not a new trust negotiation between carriers. On "SIM-proxy" as a faster MVP: I'd separate this from a speed argument. A live-backend proxy to existing EAP-SIM/EAP-AKA clients is a solution that already exists today — any MNO willing to stay in the active per-authentication loop can deploy it now, with no new protocol needed. That's not what I'm solving for. The problem is that MNOs have told us they explicitly do not want to be in that active loop for Wi-Fi authentication — that's the actual constraint driving this design, not client-rollout timing. WSIM's offline AS-Server model is the response to that constraint; a SIM-proxy re-introduces the live MNO dependency it's meant to remove. So it isn't that WSIM gets you to the same place slower or faster than a proxy — a proxy solves a different problem than the one on the table. Same MNO who is reluctant to be in active loop for WIFI authentication wants MNO's services quality improved as much as Enterprise wants improved MNO device performance after off-load to WIFI. I will add / update version - 01 to add these clarifications as well. IETF draft RFC update window opens on July 18, 2026. I will only be able to add version-01 after IETF draft-rfc update window opens. I can send my updated draft to you for review before I post it on IETF if you have interest. Thanks and Regards Praveen -----Original Message----- From: Michael Richardson <[email protected]> Sent: Thursday, July 9, 2026 7:04 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: > 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. Okay. Let's call this the "SIM-proxy", unless you have a better term. I would seperate that from WSIM for two reasons: 1. There is a protocol from Enterprise AAA to SIM-proxy. It's probably RADIUS. It might need further details/normalization of the trust model. Like, it's 2026, so it's gonna be RADIUS over (D?)TLS, and it's gonna use...?? for authentication. Probably certificates. PrivatePKI? Whose? The MNO or the Enterprise? 2. There is a protocol from SIM-proxy to MNO. It's just one MNO? So, (in Canada), I, as an Enterprise, lease this box from (e.g.,) Rogers, I still want to accept identities from Bell and Videotron, but that SIM-proxy takes care of that. Now the Enterprise can do EAP-SIM/EAP-AKA using unmodified existing clients. (Assuming that they can do that). That shortens your time to MVP. Getting WSIM deployed to smartphones is gonna be ~5years, assuming the vendors want to play. > 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). As an MNO, I would NEVER EVER do that. And I do Remote Attestation and have lot of interaction with HSM vendors, and I don't see this as being even remotely feasible. Further, my *Rogers* managed SIM-proxy is NEVER gonna be trusted by *Videotron* > 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. I suggest you have a conversation with a few MNO about this. I doubt it will work that way. -- 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]
