Question for y'all, looking at the matrix: Windows + hostapd + FreeRADIUS + tls[machine],tls[user] - note says "Supplicant only supports MSK for EAP-TLS, User authentication fails as QEMU unable to emulate usable Smartcard (Supplicant popup awaiting suitable user Smartcard credential); Supplicant sends null identity (indicating no credentials available?)".
Is there a reason y'all are using an emulated smart card (which apparently doesn't work)? Why not install a TLS cert on the Windows client and update the profile to use that cert(s)? We do run interop testing between Windows + Clearpass, where we do tls[machine], tls[user] and Windows + ISE, where we do tls[user], tls[machine]. So I can confirm those two combinations do work in production today. ________________________________ From: Alan DeKok Sent: Thursday, March 06, 2025 3:51 AM To: Peter Yee Cc: EMU WG Subject: [EXTERNAL] [Emu] 7170bis news (was Re: IETF 122 EMU agenda) On Mar 6, 2025, at 6:19 AM, Peter Yee <pe...@akayla.com> wrote: > We still have some time available in our time slot, so if you want to present > something that I've missed, please let me know. And for those of you already > on the agenda, let me know if I did not get the duration of your presentation > right. I'm hoping that we only need 20min for 7170bis. Either few people will comment and it will be quick, or everyone will have an opinion, and it will take a long time. The results of interop testing are up on the Wiki: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Femu-wg%2Frfc7170bis%2Fwiki%2FInterop-Testing&data=05%7C02%7Csam.yun%40microsoft.com%7Cdcdc46ea28b041f90e2608dd5ca55014%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638768587297076940%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7mXCvlE8XFUUPLGO5%2B4oH8gqTNcAxhn72pFw5ztwpuo%3D&reserved=0<https://github.com/emu-wg/rfc7170bis/wiki/Interop-Testing> In short, for inner methods, the following combinations work for all implementations: * EAP-MSCHAPv2 * EAP-MSCHAPv2 followed by EAP-MSCHAPv2 That's it. If the suppliant doesn't include the EMSK Compound-MAC in the Crypto-Binding TLV, then all combinations of EAP-MSCHAPv2 and EAP-TLS work, either one at a time, or in any combination. Subject to a bug fix in one implementation, the following also works: * EAP-TLS * EAP-TLS followed by EAP-MSCHAPv2 EAP-TLS all by itself works because the derivation of the EMSK Compound MAC for the first round is clear. EAP-TLS following by EAP-MSCHAPv2 works because for EAP-TLS, the EMSK Compound MAC works as above. And EAP-MSCHAPv2 uses only the MSK Command MAC. Any issues with deriving different ESMK Compound MAC for the second inner method are therefore avoided. Nothing else works across all implementations. The issue seems to be that all implementations did something different to derive the EMSK Compound MAC for the second inner method. As a result, we have shipping code from multiple vendors which doesn't interoperate. This is about the worst outcome I could think of. We now need to decide what to do about it. That decision is informed by the additional knowledge that there's really only one shipping / production supplicant for TEAP: MSFT. TEAP is in hostap / wpa_supplicant, but hasn't been used in production environments. Other supplicants either don't exist, or their vendors aren't participating here. The simplest way forward that I can think of is the following: 1) declare the MSFT behaviour TEAPv0. Crypto-Binding contains only the MSK Compound MAC, the EMSK Compound MAC is always zero 2) decide what we want to do to derive the EMSK Compound MAC. Write it down. Test it with implementations. 3) issue TEAPv1 which defines the EMSK Compound MAC, and uses it in the Crypto-Binding TLV. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
