Ever since Microsoft rolled out Windows 10 and pushing all the consumers who are in Windows 7 / 8 / 8.1 to 10, there has been lot of push for several enterprise software providers to change / mend their code, just because to support MS.
One such problem is listed here.
After you apply the Windows 10 November update to a device, you cannot connect to a WPA-2 Enterprise network that’s using certificates for server-side or mutual authentication (EAP TLS, PEAP, TTLS).
In the Windows 10 November update, EAP was updated to support TLS 1.2. This implies that, if the server advertises support for TLS 1.2 during TLS negotiation, TLS 1.2 will be used.
We have reports that some Radius server implementations experience a bug with TLS 1.2. In this bug scenario, EAP authentication succeeds but the MPPE Key calculation fails because an incorrect PRF (Pseudo Random Function) is used.
Simply put, during SSL handshake, MPPE keys will be derived. After initial RADIUS authentication, the supplicant should start the communication by decrypting the MPPE keys. Till TLS v1.0, this method was hard-coded to either MD5 or SHA1. However as per TLS v1.2 RFC, provision has been made to dynamically select the cipher-suite based on the client-server negotiation. However, the RFC is still confusing as in some parts it is still referring to old hard-coded methods.
Also, there is a speculation that, this confusion has been noted and things are noted to curb this confusion in upcoming TLSv1.3 draft.
The fix for this issue has been highlighted in freeRADIUS’s commit here.
The solution is use an SSL method SSL_export_keying_material() to dynamically get the keying algorithm based on the negotiated ciphers.
In case of original source code ( i.e with bug ), the PRF ( Psuedo Random Function ) would be calcuated something like follows.
PRF(s->session->master_key, s->session->master_key_length,
seed, prf_size, out, buf, sizeof(out));
This PRF was mostly using MD5 as the hashing algorithm. Where as when MPPE is applied, then the 802.1x client can choose any one of it’s available algorithm to generate the keys. Since the radius server on the other hand always uses MD5 as it’s key generation algo, there exists the problem.
So the solution is to simply override the PRF generation with new API SSL_export_keying_material().
A great question. Since the fix completely eliminates the existence of PRF, will it create any problem with other 802.1x supplicants ? Answer is NO. The reason is SSL_export_keying_material() by default uses MD5 and will override other algo, if indicated by the supplicant. Incase of other supplicants ( except that of MS ), obviously this indication wouldn’t exists, hence MD5 would be automatically applied.
This root-cause and the information was not readily available for the needy and here is the blog exactly for the same reason.