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]>
Sent: Thursday, July 2, 2026 11:19 AM
To: [email protected]
Cc: [email protected]; Guilin Wang <[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]
