How secure is your EAP-PEAP v0 deployment ?
PEAP stands for Protected Extensible Authentication Protocol. PEAP is one of many types of EAPs available. EAP types are like different flavors of ice cream. You can have simple vanilla or a complex rocky road type of EAP. The different types of EAPs provide different levels of administration and security. Some EAPs are consider weak, like LEAP which can be breached with Asleap.
Commonly referenced EAPs used on WiFi networks:
EAP-PEAP
EAP-LEAP
EAP-TLS
EAP-TTLS
EAP-FAST
EAP-PEAP is the most common and widely deployed EAP used on wireless networks world wide. It is also very secure, if configured and deployed properly. EAP-PEAP has a few different versions. These versions identify what type of internal authentication is conducted AFTER the outer TLS tunnel is created. This internal tunnel is where credentials are passed. The most commonly used EAP-PEAP type used is EAP-PEAP v0 based on MsChapV2.
EAP-PEAP v0 - MsChapV2
EAP-PEAP v1 - GTC
EAP-PEAP v2 - TLS
The intent of this blog post is to keep the understanding and configuration of EAP-PEAP client side simple and easy to understand.
The reason why PEAPv0 is widely adopted is because Microsoft was part of PEAP development. Microsoft uses their own protocol MsChapV2 as the internal tunnel to pass credentials. The windows wireless supplicant natively supports PEAP v0. This resulted is wide adoption.
How you configured EAP-PEAPv0 is very important. If not properly configured you can expose yourself and your network to a man in the middle attack. To understand this process we need to understand some of the mechanics of PEAP.
SERVER SIDE CERTIFICATE
PEAPv0 uses a server side certificate. The certificate is installed on the radius server. This server side certificate is used to create the outer TLS tunnel between the client and the radius server. This prevents prying eyes from sniffing frames to expose the user ID and password.
When a WiFi client connects to a WLAN configured with EAP, the radius server sends the server side certificate to the client. The client then uses this server side certificate to hash his/her network credentials and passes it back to the radius server. The radius server has the private key for that server side certificate. You may recall when you created the CSR (certificate signing request) a private key was created in that process. The private key resides on the radius server. Think of the private key as a secret decoder ring. After the radius server decodes the client hash, it can send the user ID and password to AD for user authentication.
MAN IN THE MIDDLE
While there are other documented PEAP attacks. The most realistic and real world attack is the man in the middle attack. We just discussed how the server side certificate is used to securely pass user IDs and passwords.
What if we compromised the users connection by presenting our own server side certificate via a rogue access point broadcasting your WLAN, whereby collecting the user ID and password?
Imagine for a moment
You work for Acme Company. Your Acme computer is configured to a WLAN called ACME-WIRELESS-NETWORK. You connect each and every day without fail. One day you connect and get a validate certificate popup. You, like almost everyone else, click accept without reading the content of the popup. What you just did was accepted a server side certificate from a rogue radius server and you passed your user ID and password.
This article is not intended to share all the specifics on how to set up a man in the middle attack. You're one google search and a FREE RADIUS setup away!
VALIDATING SERVER SIDE CERTIFICATE
It is important we validate the server side certificate on the wireless client that connects to our enterprise wireless network. In other words we are trusting only specific certificates from our own radius server(s). All other request get ignored and don't get displayed to the user as a popup to override. This is critical to prevent a man in the middle attack.
From an enterprise perspective this isn't a simple check box on the infrastructure and the problem goes away. Rather its standardizing on client side configuration and ensuring this configuration is deployed on every wireless device connecting to your network. The other problem, wireless supplicants aren't created equally. iOS and OSX you need to push a profile whereby validating the certificate like windows. Some supplicants may or may not allow you to validate certificates.
HUMAN FACTOR
You need to remove the human decision making process from this security equation. You don't want to give a user the ability to choose what certificate they should and should not validate when connecting to your enterprise network.
WINDOWS 7 / 8.1 - APPLE iOS and OSX
Windows 7, 8.1 and Apple devices require the user to validate a wireless network when presented with a certificate for wireless authentication, if a wireless profile is not setup for that WLAN. Once accepted the certificate trust is remembered in the WLAN profile. If you delete the WLAN profile these certificate trusts also get deleted. By manually configuration or profile pushing you can negate the certificate trust popup.
CONFIGURE VALIDATING SERVER SIDE CERTIFICATE DETAIL
http://support.microsoft.com/kb/941123
Method 1: Limit the trusted root CAs that are available to the user
Overall, the best way to reduce these potential risks is to limit the trusted root CAs that are permitted for PEAPv0. To do this, click to clear the check boxes for all non-applicable CAs in the Trusted Root Certification Authorities list. This prevents the user from trusting new root CAs, because the user is presented with an explicit list of permitted authentication servers.
Method 2: Prevent the user from being prompted for certificate validation
PEAPv0 configuration includes an option that prevents the user from being prompted for certificate validation. This is the Do not prompt user to authorize new servers or trusted root certification authorities option. By default, this option is disabled. If you enable this option, the user is not presented with the UI that may be difficult for the user to understand. Therefore, the user cannot select an unapproved root certification authority.
To enable this option, follow these steps:
1 In the Protected EAP Properties dialog box, click to select the Validate server certificate check box.
2 Click to select the Do not prompt user to authorize new server or trusted certification authorities check box.
3 Install the root certificate of the server in the NTAuth store, or click to select the root certificate in Trusted Root Certificate Authorities list.
If you cannot use this method, you can educate users to make sure that they reject the request to authorize any new servers or certification authority.
Method 3: Limit authentication servers
PEAPv0 configuration lets you limit the servers that can be trusted for an authentication. The Connect to these servers option uses a list of server names, each separated by a semicolon, to explicitly define the servers against which the client may authenticate. When you enable this option and use the strict list of accepted servers, this man-in-the-middle attack is much more difficult to execute. Or, this attack may be impossible to execute, depending on the specific PKI structure that your organization uses.
To enable the Connect to these servers option, follow these steps:
1 In the Protected EAP Properties dialog box, click to select the Validate server certificate check box.
2 Click to select the Connect to these servers check box.
3 In the Connect to these servers box, type a list of all back-end authentication servers. Separate each server name with a semicolon. For example, type the following for the domain acme.com and for authentication servers auth1 and auth2: auth1.contoso.com;auth2.contoso.com
Overview
1 - Validate Server Certificate
- Select the CA that signed your server side certificate
2 - Enter the CN name of the server side certificate(s). If more than 1 CN is used (radius servers) separate CN with a ";" and make sure there are spaces between CNs.
3 - Check box the Do Not Prompt user .. This is an extra fail safe that a user won't get the popup.
4 - Enter enable identify privacy — Enter a value in this field. This field is presented in clear text during the EAP-PEAP process. Make sure its not a user ID. 🙂
