[Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM)

Wang Guilin <Wang.Guilin@huawei.com> Thu, 02 July 2026 16:10 UTC

Return-Path: <Wang.Guilin@huawei.com>
X-Original-To: emu@mail2.ietf.org
Delivered-To: emu@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BA30110CB4EC2 for <emu@mail2.ietf.org>; Thu, 2 Jul 2026 09:10:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783008649; bh=vuUwFP6qOOzrC+8qzOPRHGgwNepDphwcjGbWLUwY66Q=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=IjgHR/VoF2mtdavRkHuOeWV9zE4l+eAqEmgxi9EMUGebFFW4dmUYQLl/EQHJO7hoU e9w+s4ewNOJ7e1GUv5wSyLVlNxsHATyw63lxK3Wk/8lU/dp3fGGTL9Q1ucvFqHk+1j hiJOAF+tvHqN5KxGHdYQjNNqds92tkosKRqYDEJ0=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.027
X-Spam-Level:
X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2_BwteOlXCG for <emu@mail2.ietf.org>; Thu, 2 Jul 2026 09:10:47 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 35EA910CB4EB8 for <emu@ietf.org>; Thu, 2 Jul 2026 09:10:47 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.224.150]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4grhfk2WfszJ467Z for <emu@ietf.org>; Fri, 3 Jul 2026 00:09:50 +0800 (CST)
Received: from kwepemh500011.china.huawei.com (unknown [7.202.181.142]) by mail.maildlp.com (Postfix) with ESMTPS id F2B2140570 for <emu@ietf.org>; Fri, 3 Jul 2026 00:10:39 +0800 (CST)
Received: from sinpeml100009.china.huawei.com (7.188.194.204) by kwepemh500011.china.huawei.com (7.202.181.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 3 Jul 2026 00:10:38 +0800
Received: from sinpeml500009.china.huawei.com (7.188.194.209) by sinpeml100009.china.huawei.com (7.188.194.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Fri, 3 Jul 2026 00:10:37 +0800
Received: from sinpeml500009.china.huawei.com ([7.188.194.209]) by sinpeml500009.china.huawei.com ([7.188.194.209]) with mapi id 15.02.1544.011; Fri, 3 Jul 2026 00:10:37 +0800
From: Wang Guilin <Wang.Guilin@huawei.com>
To: Praveen Gupta <pgupta@mobilestack.com>
Thread-Topic: [Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM)
Thread-Index: AQHc/PKmuNGdMZ5MhUiu2ZU7uJCcirZagL3O
Date: Thu, 02 Jul 2026 16:10:36 +0000
Message-ID: 947C3FF9-0033-4796-B9EC-41D76F5944F1
References: <DS4PR06MB112561C00DFEE484861D6A698DC162@DS4PR06MB11256.namprd06.prod.outlook.com>,<DS4PR06MB11256DBD7B0FDAC82A830F4D9DCE62@DS4PR06MB11256.namprd06.prod.outlook.com>
In-Reply-To: <DS4PR06MB11256DBD7B0FDAC82A830F4D9DCE62@DS4PR06MB11256.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_947C3FF900334796B9EC41D76F5944F1_"
MIME-Version: 1.0
Message-ID-Hash: QWUFRQBFZHY52UZ2J7RX53BZPWV6N5O6
X-Message-ID-Hash: QWUFRQBFZHY52UZ2J7RX53BZPWV6N5O6
X-MailFrom: Wang.Guilin@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-emu.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "emu@ietf.org" <emu@ietf.org>, Wang Guilin <Wang.Guilin@huawei.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Emu] Re: New Individual Draft: draft-gupta-emu-eap-wsim-00 (EAP-WSIM)
List-Id: "EAP Methods Update (EMU)" <emu.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/Iw4_kDTuncnsTlVr7xcQmQ97ZyQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Owner: <mailto:emu-owner@ietf.org>
List-Post: <mailto:emu@ietf.org>
List-Subscribe: <mailto:emu-join@ietf.org>
List-Unsubscribe: <mailto:emu-leave@ietf.org>

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 <pgupta@mobilestack.com<mailto:pgupta@mobilestack.com>>
收件人:emu@ietf.org <emu@ietf.org<mailto:emu@ietf.org>>
时 间: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
pgupta@mobilestack.com<mailto:pgupta@mobilestack.com>
https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/

From: Praveen Gupta
Sent: Friday, May 29, 2026 11:50 AM
To: emu@ietf.org<mailto:emu@ietf.org>
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
pgupta@mobilestack.com<mailto:pgupta@mobilestack.com>
https://datatracker.ietf.org/doc/draft-gupta-emu-eap-wsim/