On May 4, 2022, at 6:16 PM, Jouni Malinen <j@xxxxx> wrote: > . While I cannot > really point to any specific RADIUS authentication server having an > implementation that would allow this type of an attack, I cannot really > rule out the possibility. I'd hope the old implementations that do not > support RFC5746 would not support TLS renegotiation at all, but it would > be difficult to sure about that without testing each such server > implementation individually. The additional consideration is that there's little reason to be shipping things which are a 12+ years out of date. IIRC, the RFC 5746 fixes went into OpenSSL 0.9.8m, which was released in early 2010. The Aruba product which was mentioned earlier is based on FreeRADIUS + OpenSSL code which is even older than that. And which has had little engineering effort put into updates. I think with clients moving to TLS 1.3, the need for RFC 5746 work-arounds is temporary. RADIUS servers will be forced to upgrade to a recent version of OpenSSL, and the RFC 5746 issues ill just go away. It's probably worth removing these work-arounds once TLS 1.3 is widely used. > One could obviously claim that it is not the duty of the EAP client to > enforce security in this front, but in practice, it seems to be much > more likely to get EAP clients upgraded than RADIUS servers in various > networks.. Yes. > I'll probably add at least this into wpa_supplicant with a clear event > message identifying this specific issue to upper layers and a > network-specific configuration parameter for enabling the workaround > (and a suitable set of warnings to recommend against using this > workaround in cases where the user care about real security..). That seems best. This should likely not be enabled by default, and maybe even require special build options. Alan DeKok. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
