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 **
sinature.asc
Description: PGP signature
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
