Windows Wi-Fi with 802.1X + EAP-TTLS + EAP-MSCHAPv2 and client certificates

Question

Sooo ... We have the the mandatory requirement that clients who want to join our wireless LAN to present a valid machine certificate issued by our in-house root CA. This is done to prevent from malicious users who have a valid username/password combination to join the wireless LAN. After all, it's easier to obtain a working username/password combo than a valid certificate.

Prior to Windows 8.x we used EAP-TLS as outer authentication protocol to satisfy this requirement and used the inner authentication protocol to validate username / password against our AD.

With Windows 8.1, it seems that EAP-TLS is no longer supported (at least it can't be configured in the GUI. If I'm mistaken here, please provide a link how it's done). So I started experimenting with EAP-TTLS as outer authentication protocol and EAP-MSCHAPv2 as inner authentication protocol. While this works, I'm unable to include a client certificate during the TLS handshake phase. I cannot for the heck of it find a way to tell Windows to do so.

Am I right to assume that there is NO WAY to configure the native Windows 8.1 802.1X supplicant to provide a client certificate when EAP-TTLS is used as outer authentication protocol?

RFC 5281 explicitly states that client certificate validation is supported during phase 1, so I cannot quite see why Microsoft would have omitted an option in the GUI to configure this.

Answer 1

The Windows GUI has traditionally referred to EAP-TLS authentication as "Smart card or other certificate". So maybe that's what you're looking for.

However, this part of your question doesn't quite make sense to me:

Prior to Windows 8.x we used EAP-TLS as outer authentication protocol to satisfy this requirement and used the inner authentication protocol to validate username / password against our AD.

…because as far as I know, EAP-TLS doesn't provide for an "inner" authentication protocol. So I'm wondering if maybe you used EAP-TLS as your only 802.1X EAP type, and then the username/password authentication you remember doing wasn't part of 802.1X, but was maybe part of authenticating to your AD domain after you were already fully 802.1X-authenticated and had network connectivity.

As far as I know, only PEAP and TTLS establish an "outer" secure tunnel via dummy authentication and then use that tunnel to securely transport an "inner" authentication transaction. And even PEAP and TTLS, for the outer authentication, only do TLS, but as far as I recall only use it to verify the authenticator (AP or AAA server) and set up the encrypted tunnel. I don't recall there ever being a way to specify a client certificate for the TLS authentication on the outside of PEAP or TTLS.

Both PEAP and TTLS technically allow for EAP-TLS as the inner authentication mechanism, although many early TTLS implementations didn't allow EAP; they only allowed the pre-EAP PPP authentication methods: PAP, CHAP, MS-CHAP, MS-CHAP-V2. It could be that the native Windows 8.1 802.1X supplicant is one of these. Likewise, some PEAP implementations support EAP-MS-CHAP-V2 and EAP-GTC as the inner auth types, and may not support other auth types such as EAP-TLS as the inner auth type. However, Microsoft's native Windows 802.1X supplicant has always supported EAP-TLS as the inner auth type for PEAP, they just have traditionally labeled it "smart card or other certificate".

It's never a surprise to me when an implementor skips optional parts of a protocol spec when implementing that protocol. Almost every RFC I've ever read has had parts that I've never seen anyone implement. So it's no surprise if Microsoft's Windows-native 802.1X supplicant doesn't provide a way to offer a client TLS certificate in the outer authentication of TTLS. If you read through the TTLS spec, you'll see that when that happens, TTLS ends up skipping inner authentication, so it's basically just EAP-TLS at that point. Microsoft probably figured that since they already supported EAP-TLS, why bother implementing the EAP-TTLS mode that ends up being about the same as EAP-TLS?