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]
