Wireless Access

Just want some thoughts on the security pros an cons of the below setup

 

Ssid = WPA2-aes

802.1x authentication

Termination EAP-Type = wap-peap

Termination Inner Eap-Type = eap-mschapv2

 

User logs in with AD creds against a radius server.

 

Just trying to see where the above setup sits on the security scale.  

 

Thoughts?

 

 

What specific parameter are you concerned about?

 

Not concerned about anything in particular, just trying to get thoughts on how secure (or not) the setup is considered to be.  

 

It is an ssid which the user auths with just their AD user details.

That is one part of the security picture. You need to have only the server certificate on the client side trusted to make it truly secure.

 A user can connect to the network from any device providing they have a valid AD account.  When the user connects they are prompted to accept the radius server cert.  Once accepted they are connected to the network.

 

The question was asked about how secure this is to attacks.  How likely is it that a a users details could be discovered (by a man in the middle or another each attack)

You probably want to use something more secure like EAP-TLS which is a certificate you issue to users, instead of PEAP, which is username and password.

Do you have regulatory requirements or are you just looking for best practice advice?

 

If just looking for best practice, the gold standard is EAP-TLS with device certs.

The biggest detail here is actually the client configuration. You'll want to make sure the devices are validating the server's identity.

 

This is a fairly secure setup in use in a lot of places.  It's a server-sided certificate setup so it is very popular.  It offers gradual security: mostly secure, but the users can make it more secure in some cases by making some configuration changes (and for certain types of devices you can roll those changes out automatically.)  It is also nicer than TLS when it comes to password expiry and such, since you do not have to change client certs to change "passwords".

 

PEAP + MSCHAPv2 will be in use for the forseeable future due to Microsoft NAP (a.k.a. SOH, statement of health) not working over TTLS, IIRC.

 

The biggest current security worry in this setup is that it is hard, and in a few cases, impossible, to get the clients configured to validate the owner-id of the server certificate.  It is easy enough on windows and Linux as they both allow the user to configure the necessary options. It is less a concern on iOS/OSX, which will lock in the certificate after the first join to the network so the opprotunity for AAA MITM is slim.   It is a bigger concern on Android where Google has sat around with it's thumb stuck someplace impolite for nearly a decade rather than implement a simple GUI element on the WiFi config screen, meanwhile allowing the machine to pay no attention whatsoever to whether the certificate changes.

 

Another minor security concern is that clients do not tend to properly use an anonymized outer ID so their usernames tend to be visible in the clear.  Configuring this is more widely supported than configuring validation; just about every client will let you do it, though on Apple products you have to build a mobileconfig because they didn't want to confuse their fashion-addled user base with too many options so they took that one out.

 

Thanks for the feedback

 

The current setup is for ease of use.  A domain user can connect to the wifi network with any device.  They just select the ssid, enter their AD username and pw, accept the cert and all done.

 

Well it is not the Gold Standard of security it does give the best user experience within the environment.

 

Just trying to access the possible security risks so that we can put steps in place if needed.  

 

Question with this setup was does the industry and wireless community consider it to be a reasonably secure and varible setup.  Or is it considered a do not use.  How big is the risk that a person's user details could hacked over the wifi?  

A majority of 802.1X networks use this configuration. It is secure.


Thanks,
Tim

Thank you for the feedback.

 

It has confirmed much of what I thought.

 

I was checking as we had someone suggested that using peap was an extreme security risk as it was very easy to hack and grab a user's username and password.

 

I just wanted to confirm that this was not the case. 

 

They can only attempt to attack MSCHAP if they can get inside the PEAP tunnel with a MITM AAA server.  An advanced persistent threat might actually be able to do that, but to prevent it, you can configure the clients to validate the owner of the RADIUS server's certificate.  That's an easier policy to distribute than individual certs for each machine on enterprise setups, but for client-owned self-configured devices, it relies on the users to follow your instructions, and if they don't, it will "just work" so they will skip that part.

 

I did once hack together some FreeRADIUS code to randomly serve an alternate certifcate to see if I could audit the clients to ensure this option was set (and we could then redirect them to a captive portal telling them how to complete securing their devices.)  However, it made certain client devices sad.  Maybe they have improved enough to cope these days, or previously gathered OS fingerprinting could allow more targetted survey.

 

It might also be possible to detect attempted AAA MITMs based on the behavior of affected clients when they try to reattach to your real AAA server though failed SSL session resumptions or devices that have locked in the attacker's phony cert when they first joined.  On the client side any MITM would require the client to re-validate the phony certficate in the same way they have to when first joining the network, so attackers would have to be surgical or your help desk would start getting calls about that dialogue popping up over and over.  Training help desk staff to examine fingerprints on troubled wifi connections might be worth it, and power-users who know that those dialogues should never happen after initial configuration (unless they delete the profile) could serve as another detection mechansm.