On Mar 19, 2025, at 7:14 PM, Heikki Vatiainen <h...@radiatorsoftware.com> wrote: > To summarise the current TEAP implementation state: > - Windows is the only supplicant (TEAP client) that's in production use that > we know of. > - EAP-TLS can do both EMSK and MSK but TEAP/EAP-TLS on Windows does not use > EMSK > - EAP-MSCHAP-V2 specification does not defined EMSK > - A number of servers can use EMSK but there are differences in how they do it
Yes. > Conclusion: EMSK is not currently (widely? at all?) used. Yes. > Based on the above, since EMSK is not widely used, if at all, with TEAP inner > methods, I'd be fine with TEAPv1 being an EMSK-less specification. OK. Given existing deployments, I think that's the best choice. > Giving up on using EMSK does sound like giving up something important, but is > it so? Can someone tell what's the importance of EMSK being used in TEAP? > Does it provide, for example, additional integrity checks which are important > enough that they couldn't wait for TEAPv2? It binds the inner session to the outer one, and prevents MITM attacks. Since implementers seem to be OK without that protection, there isn't much we can do. i.e. 7170bis should explain these issues, and state that it's documenting a pre-existing protocol which can't be changed. We can then fix issues with TEAPv2. > As far as I know, none of the other EAP methods (PEAP, TTLS, AKA', etc.) or > related specifications define any use for EMSK. MSK is used, for example, > creating 802.11i Pairwise Master Key (PMK). Many of the EAP methods define > how EMSK is derived, but they don't seem to need it. Does use of EMSK make > chained TEAP inner authentication methods significantly safer or EMSK used > only because it's available and it was thought to be easy to mix in? Then > again MSK-less inner methods, such as PAP, are fine without MSK. From 7170bis, for the Crypto-Binding TLV: >> This TLV cryptographically binds the inner method to the protected tunnel, >> and to the other fields which have been negotiated. The cryptographic >> binding prevents on-path attacks. I'm not aware of cryptographic proofs of this statement, though. TTLS defines some cryptographic binding for CHAP and MS-CHAP in https://datatracker.ietf.org/doc/html/rfc5281#section-11.1 But it appears to be missing similar text for EAP-MSCHAPv2. And, it doesn't use the EMSK for other inner methods to to cryptographic binding. So it looks like TTLS is vulnerable to on-path attacks when some inner methods are used. > If EMSK is not essential, TEAPv2 could then be the version that clearly > defines how EMSK is used. Yes. Even if EMSK is essential, it's worth documenting TEAPv1. And we can't change TEAPv1 without declaring that existing deployments are not compliant. So we pretty much have to publish TEAPv1 as-is, and then do any fixes in a TEAPv2 document. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
