Higher Education

Hi,

 

Our .1X SSID uses EAP-TTLS. We use an onboarding tool from another vendor to guide users through the supplicant configuration process. This adds TTLS support and does other magic (inserts radius cert + sets SSL to Always Trust (Apple KB) , positions .1X SSID at the top, removes open SSID, etc.).

 

Essentially, this means user must go to our open SSID to run the config tool before connecting to our .1X SSID. Our user population is having problems with this basic rule ("Go Here to Get to There") which results in our Help Desk being overwhelmed each September by users who try to connect to .1X but fail with a crippled (at best) connection.

 

What are folks doing to educate users to "Go Here to Get There"? What messaging is effective? Are there good ways of using enforcemnet, like not allowing users to use the open SSID (send them to redireact?). Can the .1X SSID "fall through" to a web page that says "You need to launch this app first"?

 

Thanks,

Mike

 

 

We simply do not do cert based .1x any more because of this...  We moved to PEAP mschapv2 and have not really looked back - since the move we have had almost zero requests on how to access the network...  We sync their AD credentials to Google Apps and utilize single-sign-on for everything so its one username/password to get where you need to go.

 

I like the security aspect of TTLS, but we would never deploy to our student population again unless it is much, much easier.

 

Now the population of machines we control I have no issues with TTLS as I can manage all of that from AD...

So you don't use any client configuration utility? You're opening yourself up to man-in-the-middle vulnerabilities.

 

 

---

@cappalli wrote:

So you don't use any client configuration utility? You're opening yourself up to man-in-the-middle vulnerabilities.

 

 

---

We have a simple guide on how to setup your client.  Along with trusting the certificate, etc.. most of the students follow the instructions, some simply click "connect"

 

IMO 802.1x PEAP is still light years better than WPA2, and we simply do not have the support staff to handle the massive ammount of issues that TTLS brings to the table.  Aruba has a nice solution - but for a small organization it is totally out of our budget...

 

 

When using PEAP, most users simply enter their credentials and go on their way. Little do they know that their credentials can easily be captured.

 

I always recommend requiring some type of supplicant configuration utility or moving to EAP-TLS.

 

Also keep in mind that Aruba has an independent product called ClearPass QuickConnect that can do supplicant configuration and is very reasonably priced if onboarding is out of your budget.

 

If you use eduroam, they have a free supplicant configuration utility that members can use.

Tim,

Can the CAT tool install our radius cert on OSX and set relevant certs to SSL Trust (Apple workaround?).

Can ClearPass?

I don't believe they can do the Apple workaround, but they can install your CA cert and/or trust the public CA cert.

ClearPass QuickConnect

We have never heard of this product... I will contact my rep and ask him about it.  We were only told about the much more expensive piece...

Here's some sample screenshots of CP QuickConnect

 

 

Isn't this the whole purpose of Clearpass onboarding? to do all that for you?

---

@americanmcneil wrote:

Isn't this the whole purpose of Clearpass onboarding? to do all that for you?

---

Yes.  But for some this product is simply out of reach.

What would ClearPass do differently than my other config utility? Isn't the problem essentially the same: you got to go here (open SSID) to get there (.1X SSID)?

Our users aren't "going here" and instead getting stuck "going there" first. How would ClearPass resolve this?

Mike

I was responding to danstl. (Sorry!)

---

@danstl wrote:

---

@americanmcneil wrote:

Isn't this the whole purpose of Clearpass onboarding? to do all that for you?

---

Yes.  But for some this product is simply out of reach.

---

If you are in EDU (likely since this is an Eduction forum), talk to your local Aruba team about current promotions:  http://www.arubanetworks.com/resources/current-promotions/.      Not all promotions are valid for all products/verticals/regions; but worth looking into.

Tim, can you point to some good reading material on this vulnerability?

 

Thanks,

Jim

Attached is the presentation on 802.1X from Airheads. I went over MiTM and 802.1X. Also, you can just run a google search for "802.1X man in the middle" and you'll find a plethora of information.

 

 

doing a man in the middle is quite easy if you do not verify certs.  Setup a linux box with free radius hook on an AP setup the identical SSID, and then capture any authentication requests, then hack the hashed passwords.

 

But we have found that depending on who is behind the computer - even if you enforce verification, etc... If the OS allows you to still connect people simply ignore the message and connect anyway...

The supplicant can be configured to not prompt users to accept new
servers/certificates.

Getting back to the topic of this thread can anyone please tell me what they do to nudge users to the SSID which helps them onboard (configure) for the .1X SSID? Tim, your screenshot implies users need to go to a different SSID (brandeis_guest) to launch QuickConnect to configure for .1X.

 

My original question is how are people spreading the word tio their user community that they must go to the "onboarding" SSID first to configure for the ".1X" SSID. Our users are not doing this inuitively. They are connecting to the "SECURE" (.1X) SSID first. Because most devices lack the basic ingredients for EAP-TTLS they never successfully authenticate. At that point they either quit and connect with the open SSID permanently or they go to the Help Desk who (surpise!) tells them to run the config tool by going to the "onboarding" SSID.

 

Mike

 

 

Mike-

 

We use three SSIDs.  We struggled with using an additional SSID for onboarding - but for us, it has been worth it; particualrly if you disable low data rates for beacons.

 

*HWS-Private is our PEAP/MSCHAPv2 SSID

*HWS-Public is an Open Auth SSID with Captive portal "click to accept terms" button.  Not perfect but annoying enough to keep Students going to the HWS-Private SSID instead of staying on the Authed SSID and guests from just autoconnecting all the time.

*HWS-Get-Connected is our Open Auth with Captive Portal SSID.  We use DHCP fingerprints to steer clients to a Captive portal unique to their platform (as close as we can get) or fallback to a "generic" Captive portal.  The user profile has no access to anything but the CP.  In all plaforms , the initial captive portal pages have two buttons: "Guests/Visitors" and "Student/Facuty/Staff".  Each button is a link to instructions to connect for their platform/faqs  or an onboarding tool which does supplicant configurations (including setting valid Radius server name/cert chain).  If we registered devices, this SSID would be the natural place to put this.

 

It has worked pretty well for us.  I suspect if we registered devices and/or had Clearpass, we could consolidate down to two SSIDs... but we don't at the moment.

 

I'm going to go on a tangent here thought: As Tim points out, it still doesn't protect us from the user connecting directly to the PEAP/MSCHAPv2 SSID and setting up a weak supplicant profile, not neccesarily validating the radius server.  In this case it depends entirely on the default OS behavior.  In the iOS case, I've found it stores the Radius *cert* (not name) with the wifi network config after the user "accepts" the installation of the cert (and if memory serves me, the cert will show as unverified regardless of the CA).  Unfortunately, this means that when the Radius cert legitimately needs to be replaced if it is due to expire (or, you know... is a little Heartbleed-y) - the user will be prompted to accept a new copy of an updated certificate (and thusly prompted again).  I see two things wrong here - a) the wireless profile is not actually validating the server by it's name - it's looking for an identical certificate as was installed when the wireless profile was set up by the OS supplicant.  I *think* (call me out if I am wrong) MITM should be avoidable by validating the server name through it's CA chain - regardless of the individual certificate thumbprint/serial.  In my observations this is how the MS stack handles server validation; as does on iOS in the case of a properly installed profile via Mobileconfig. b) By storing the cert and forcing users to constantly "accept" a cert as it changes (even when both are legitimate); we continue to train people to just click "accept" - more or less invalidating server validation and opening up users to the same MITM risks as not enforcing server validation.

 

Thanks Kevin,

 

The thought of an "onboard only" SSID occurred to us but that would put the campus-wide SSID to four and I hoped to keep the count to  three. Still, this may be a potential solution.

We use a similar product to what you describe and we have an onboarding SSID setup.  We found that the netowrk names were confusing to our population so we named our onbaording SSID "OlivetWiFi."  We also have an ONUGuest and our 2 other networks that the user will be migrated to.  OUr onboarding SSID is setup so that once they try to go to any other page they get redirected to the onboarding utility.  This seems to have worked pretty well for us.

 

Tyler Campbell|Olivet Nazarene University| Bourbonnais, IL

tcampbel@olivet.edu

Also, for what it's worth, I've found the second download on this link to be a useful tool when gauging airtime impact due to beaconing of adding SSIDs and/or modifying the Basic Data Rate.

 

http://www.revolutionwifi.net/p/downloads.html

 

 

Mike,   I have seen a few different setups in the past; some of which are covered in this thread:

 

- Have links on the open guest SSID that users can click through that will initiate the OnBoarding process (ClearPass or otherwise)

- Configure the 802.1X SSID to assign a different role for any PEAP-MSCHAPv2 authenticated users (to redirect to provisioning portal for example), but assign your authenticated role for EAP-TLS or EAP-TTLS authenticted users.

- Setup a "provisioning SSID" (least preferred method)

 

There is one more thing to consider when it comes to the man in the middle attack being discussed.   Although you minimize the potential impact on the devices that you have configured with policy/profiles/provisioning.....if the user unknowingly enters their username/password on any one of their other 4 or 5 devices and send it to an impersonating AP/RADIUS server, they are still susceptible.  

 

To help protect against this risk, you should have proper rogue detection in place, you should be alerted to any rogue APs advertising your SSIDs and if any known clients connect to rogues.