On Jan 24, 2019, at 6:56 PM, Jouni Malinen <j@xxxxx> wrote: > > On Thu, Jan 24, 2019 at 11:05:28AM -0500, Alan DeKok wrote: >> Hi, we're trying to get TLS 1.3 working with FreeRADIUS && wpa_supplicant. As perhaps could be expected with any new standard, there are issues. > > Which version of wpa_supplicant have you used for this? You'll need the > current snapshot of the master branch in hostap.git to the changes to > match draft-ietf-emu-eap-tls13-03.txt. Or well, I think I'm still > missing one of the changes (empty ApplData to indicate > server-TX-completion). IIRC, it was the current head. Arran should know more. He's on this list, so he can respond. >> The largest issues seem to be in OpenSSL. The git HEAD seems to work better than the released versions, which don't really work well at all. > > I have managed to get EAP-TLS working with TLS v1.3 between hostapd EAP > server and wpa_supplicant EAP peer while using unmodified OpenSSL 1.1.1. We haven't tried that. But here's one bug found by Arran: https://github.com/openssl/openssl/issues/8077 >> Previously, the session tickets were sent before the "server finished" message, before the handshake was finished. They now appear after that, but before the application data. > > Yes and that's something that did require changes in > hostapd/wpa_supplicant for the earlier version of the draft. I think my > comments on that area resulted in the latest draft using an explicit > notification to allow that area to be simplified, but I did not yet > finish that implementation (it was a bit difficult to extract knowledge > of the exact state and get OpenSSL to behave on both server and client > side). Yes. The state machine is a bit opaque. > I did get this working with older EAP-TLS v1.3 draft design. TLS v1.3 > support is disabled by default in wpa_supplicant for now, but with > phase1="tls_disable_v1_3=0" in the network profile, this still works at > least against the hostapd EAP server implementation. And this does > include successful exchange of session tickets. OK, good to know. We'll keep poking at it. > I don't think I did anything for this part yet or even tested this > match. The only automated test case that I currently have for EAP-TLS > with TLSv1.3 seems to be using RSA certs on both ends. We're adding a large test matrix on the FreeRADIUS side which should help. But this issue should be also seen with TLS 1.2, because the issue is cipher negotiation, not TLS versions. If you set cipher_suite to something that *doesn't* match the certificates, OpenSSL won't notice until such time as it has to exchange the certs. And it will then fail. I think this was never noticed because versions that supported newer cert methods would always negotiation those methods. It's only with the advent of ECC certs that OpenSSL will negotiate *both* ECC and RSA, even if it doesn't have RSA certs available. This naturally confuses the other end, who might want just RSA. Alan DeKok. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
