Technology Blog

How secure is your EAP-PEAPv0 deployment ?

Guest Blogger

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. :)

 

 

aruba.eappeap.png

Comments
MVP

Great post, George.  This sheds lights on an important part of securing the WLAN, that many engineers are not aware of.  With the known MSCHAPv2 vulnerabilities, performing steps 1 & 2 are critical to protecting against MITM attacks.

 

I was not aware of the functionality that 3 and 4 provide and appreciate you pointing them out.

Guest Blogger

Funny you say that .. When I speak to customers this is what I hear as well on 3/4.

 

Thanks for your response. 

Guru Elite

There is also the misconception that the RADIUS certificate itself needs to be installed on the client. This is only true if the certificate is self-signed.

Guest Blogger

Cappalli -- oh i have to agree 100%. Thats always an item to tackle with folks.. Thanks for the comment!

MVP

Hi, thanks for a great post!

 

If identity privacy is not set, will the users real username be sent i clear text during the EAP transaction? And when using aruba controllers or instant, will the user entry still display the correct, hidden, name? I´ve seen users getting stuck with "anonymous" in the user table.

New Contributor

Yes, without identity privacy, the real identity is sent in the clear.

 

By spec, the EAP-terminating RADIUS server needs to return a revised User-Name attribute in the Access-Accept if you wish to display the real identity while identity privacy is in use.

 

Can I also suggest people take a read of https://wiki.terena.org/display/H2eduroam/EAP+Server+Certificate+considerations

MVP

Hello gstefanick

I would like to know what options does smartphones like iPhones, androides has to connect securely? I mean you cannot put the server name so they basically will connnect to any radius server in a man in the middle attack.    Is my only option EAP TLS???

Guest Blogger

Hello

 

Yes you can validate the server cert but it requires you to go a profile. See my post on the Apple TV. Bottom requirment. http://community.arubanetworks.com/t5/Technology-Blog/Apple-TV-EAP-PEAP-Configuration-Clock-Fix/ba-p/143391

MVP

Hello George

If i understand correctly you dont validate the connect  to this server BUT you are able to validate server cert? in EAP PEAP

I am right?

I mean its not possible to validate server name as with windows, but you are able to validate server root certificate at least which will help with the man in the middle attack as the client will check this certificate  before sending the user name and password to the attacker.

In summery

With iphones, apple tv etc

The attacker would need to have the root CA certificate in order to take away your credentials?

 

With windows machines

The attacker woudl need to have the root CA certificate  AND a server with the same server name you are using as your radius server?

 

Iam right in my understanding?

 

Cheers

Carlos

Guru Elite

You can also configure common name (server name) checks for iOS and OS X via profile.

 

Android currently only checks root CA (as of Lollipop).

MVP

What about kit kat?? it doesnt check for root CA either?

 

BTW thanks for your answer cappalli

 

Cheers

Carlos

Guru Elite

Both Kit Kat and Lollipop can verify the Root CA, but unforunately the cert has to be uploaded and selected during the connection process (which no one does).

 

As much as I love Android, it's a glaring security issue.

MVP

Thanks Tim!!! 

Cheers

Carlos

MVP

BTW any advice for this? ( i knwo you can configure to check for the root CA cert) but just as tim said noone does that and is not necessary, i mean the users still can connect their devices if they use their AD credentials(could block them with machine authentication but some need access with their smartphones)

How do you overcome this security issue when you got Managers, and VPs wanting to connect their smartphones to the network? is EAP TLS the only way? 

I mean withtout any other additional appliances 

Guru Elite

EAP-TLS is the gold standard but cost can sometimes be an issue.

 

The only other alternative is to use something like QuickConnect which can properly configure clients. But at that point, cost wise, you might as well just add Onboard for EAP-TLS.

 

 

MVP

True that!

Well anyways just verifying if i was missing something!

 

Thanks again TIM! :)

Occasional Contributor II

Hi,

 

Appreciate this is an old post but had a query regarding the above. 

 

Our organisation uses a 'Service' name in the CN of certificates that they issue. So, for example, the CN might be 'Clearpass Guest'. In the 'Connect to these servers:' option, would I simply specify Clearpass Guest or place this configuration in speech marks/quotations e.g. "Clearpass Guest' or 'Clearpass Guest' or Clearpass Guest

 

Thanks

Guru Elite

The common name needs to be an FQDN for a server certificate.

Occasional Contributor II
Ok, so the CN we have for the certificate is not an FQDN. We have the FQDNs specified as SANs as our PKI team wanted us to use a single certificate for all the servers to reduce the maintenance overhead. Unfortunately the CN reflects the name of a service right now in our support tool and is not an FQDN. With this in mind, can I therefore not use this as an option given how the CN in the server certificate is currently configured?
Guru Elite
I don’t believe so. I’ve never encountered this scenario. An EAP server certificate should have a generic CN with the same name as a SAN. You do not need SANs for each server.
Occasional Contributor II
It is related to the policy implemented by the PKI team. They insist that the CN represent the name of the service in the 'service management' tool for our organisation, with the SAN containing the DNS names and IP addresss of the servers that make up the cluster. Agree it is an unusual scenario, but one we cannot influence. I guess for my scenario I won't be able to use this option in the supplicant configuration (unless I can get a change in policy), and will instead only validate the server certificate presented by the server (I have the root CA cert on the supplicant).
Guru Elite
You should strongly consider EAP-TLS.
Occasional Contributor II
We are 'attempting' to do this already. But our supplicant and authentication server configuration isn't what I would call 'Enterprise' grade. We are looking to enhance the configuration of both the client (Win X) and Clearpass as the authentication server to provide a more secure service but stepping through this slowly so best to understand all the options, requirements and impact before making any changes to the service.
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Read all about it! If it’s happening now, it’s in the community.

Check out the latest blogs from your community team, the community experts and other industry sources.
Labels