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). > 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. > 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). > Both wpa_supplicant and FreeRADIUS use the SSL_is_init_finished() call to see if the handshake was done, and assume that the next data is application data. Instead, SSL_is_init_finished() returns true, but the next set of data is just more session tickets. SSL_Read() processes the session ticket, and then returns -1 to indicate that there's no application data. And SSL_Error() returns SSL_WANT_READ. > > This appears to be a behaviour change from TLS 1.2, and affects both wpa_supplicant and FreeRADIUS. It's not straightforward how exactly to fix this in a way that works both for TLS 1.3, and TLS 1.2. 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. > Another issue is with cipher negotiation. This affects TLS 1.2, too. > > If the cipher list contains ECC, then OpenSSL is happy to negotiate ECC. Even if it's only been configured with RSA certs. So wpa_supplicant sends "I can do ECC and RSA", and when FreeRADIUS responds with an ECC cert, wpa_supplicant goes "no compatible cipher list". Authentication then fails. This makes end users unhappy. > > This is arguably a bug in OpenSSL. e.g. if you give it cipher list "DEFAULT" and only RSA certs, it should be smart enough to only negotiate compatible ciphers. That process is made more difficult by the use of a CA directory, where OpenSSL looks up certificates as needed. And therefore doesn't even know what certificates there are until it needs them. Which then makes negotiation difficult. > > A counter-argument here is that the application knows what certs it has, and the application should filter out incompatible ciphers. However, that's difficult in part due to the opaque OpenSSL API, and also because it's not straightforward to map ASCII cipher strings map to certificate properties. 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. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
