Hi Alan, 1) To explain Crypto-Binding TLV advantages:
This is how the attack we are talking about works (let's take one specific scenario): The real TEAPv2 client A establishes TEAPv2 TLS tunnel with the rogue TEAPv2 server B (let's say this succeeded because A didn't properly authenticate B TLS certificate). Then A and B conduct inside the tunnel and inner method EAP-MSCHAPv2 or EAP-TLS. B at this time establishes the TLS tunnel with the real TEAPv2 server C that is capable to run inner methods and authenticate the users in ActiveDirectory or any other Identity Stores. So each time A sends inside the TEAPv2 TLS tunnel the next inner method message to B, B re-sends it to C inside the TLS tunnel. Finally C authenticates the user and A and C derive inner method keys that are known only to them, and not known to B. Now, TEAPv2 MSK is used to establish wired/wireless L2 link security (like MACsec, 4-way handshake using PMK). If TEAPv2 protocol derives its keys (MSK/EMSK) based only on the TLS tunnel keys, then A and B derive TEAPv2 keys only from the TLS tunnel between them. And thus the attacker B has full access to the encrypted data sent by A on L3. If TEAPv2 has Crypto-Binding TLV that connects outer TEAPv2 TLS tunnel keys with each inner EAP method keys and allows both A and C to verify that the tunnel and inner method both belong to A and C, then the attack of B becomes impossible. Also the TEAPv2 MSK depends on both TEAPv2 TLS tunnel and inner method keys. In HTTPS if the user authentication method inside the tunnel is just form logins (i.e. username/password inside the TLS tunnel) - there's no need for a binding. But for more complex user authentication methods there are some analogs to prove that this application-layer authentication or token is bound to this specific TLS channel. A good description of the necessity of Crypto-Binding to prevent tunnel MITM attack is provided here: RFC 6678, Section "4.6.3. Cryptographic Binding with the TLS Tunnel" 2) Currently it looks that the Initial-Binding TLV that is exchanged right after the TLS tunnel establishment, before exchanging with any inner EAP authentication method that derives keys - seems that such Initial-Binding TLV has just a small advantage on just the TLS tunnel key materials by including TEAP version and outer TLVs. It doesn't prevent tunnel MITM attack. Can you please explain your vision on it? Regards, Oleg Oleg On Thu, Nov 13, 2025 at 4:56 PM Alan DeKok <[email protected]> wrote: > > On Nov 13, 2025, at 9:43 AM, Oleg Pekar <[email protected]> wrote: > > So the Initial-Binding TLV protects from downgrade attack and also > > protects the outer TLVs exchanged in the first roundtrip, correct? > > Yes. And it protects from an attacker who terminates the TLS tunnel, and > then acts as a TLS client to forward the data somewhere else. > > >> The Initial-Binding TLV protects the TLS tunnel from attackers. It is > >> sufficient to protect the tunnel from observers. > > > > Isn't the outer TLS itself sufficient to protect the tunnel from > > attackers and observers? > > I don't think so. Or at least, the input I've seen indicates that it > doesn't. The issue (apparently) is that only one end of the TLS tunnel is > authenticated. As such, the application needs to bind its application data > to the tunnel. > > If that isn't true, then we can remove both Initial-Binding and > Crypto-Binding. > > > Right, the Crypto-Binding TLV is a strong security element of TEAPv1, > > it is used in EAP-FAST and PEAP as well. It will probably be a serious > > security downgrade for parties that use the most popular inner methods > > like EAP-TLS or EAP-MSCHAPv2, and it is especially important for > > chaining inner methods of user and machine in the same TEAPv2 tunnel. > > Removing the binding may be a security issue, but we will need confirmation > from the TLS people. > > If it is an issue, then I don't understand why HTTPS isn't subject to the > same attack. So I'll have to look into it some more. > > > It's clear that there's no benefit for other popular > > Basic-Password-Authentication inner exchanges or EAP-GTC. > > In which case there may be little benefit from using it for other inner > methods, too. > > > I can easily understand that intent considering all the discrepancies > > we had about Crypto-Binding TLV in the first spec of TEAP. However > > security is also a very strong concern. > > Agreed. > > Alan DeKok. > _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
