In many projects regarding network access control are focussing on probably secure EAP methods, which rely on SSL/TLS. The most common examples are EAP-TLS or PEAP (simply because must supplicants support them).
However, it’s not enough to check whether the authentication server or supplicant support the desired SSL/TLS based EAP method. Often it comes down to cipher suites.
Especially if using PEAP, the credentials are transported in a SSL/TLS tunnel. Of course you want to make sure, that the credentials are transported in a safe way. Besides security, there are functional aspects as well. Imagine there is some client in your network – let’s say 10 years old, which is in theory able to do EAP-TLS and PEAP. Maybe the client only supports cipher suites, based on DES or 3DES encryption and MD5 signatures (e.g. TLS_RSA_WITH_3DES_EDE_CBC_SHA)
If there are such clients in your network, the authentication server must be configured to support those ciphers (if possible) or the clients must be updated or replaced.
If there are no matching cipher suites on the authentication server and the supplicant, the authentication will fail.
Some examples:
Windows 7 native supplicant (as of 01/2019)
TLS version: 1.0
Supported cipher suites:
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_RC4_128_SHA
- TLS_RSA_WITH_RC4_128_MD5
Don’t even consider to disable TLS 1.0 or SHA-1 support in your authentication server if using Windows 7 clients.
Windows 10 native supplicant (as of 01/2019)
Windows 10 looks way better
TLS version: 1.2
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
- TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
- TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
- TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
- TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
- TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
- TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
- TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
- TLS_RSA_WITH_RC4_128_SHA (0x0005)
- TLS_RSA_WITH_RC4_128_MD5 (0x0004)
So with a pure Windows 10 deployment, the authentication server may be tuned for SHA-2 based ciphers only and TLS 1.2.
How to find out the supported 802.1X cipher suites of your clients
It’s not easy. In the best case your authentication can report this in a proper way. As for the ISE 2.4 I didn’t find a way to get a good overview report. However it’s listed in the authentication details of an endpoint.
Another possibility is to capture RADIUS authentication packets somewhere between the authentication server and your authenticator. The desired information is inside the “Client Hello” messages, encapsulated in the RADIUS attribute 79 (EAP-Message) / SSL handshake.
A corresponding Wireshark display filter for those messages could be:
ssl.handshake.type == 2
Probably it would be a good idea to create some kind of script, that analyzes captures and provide a proper summary report …
0 Comments