[unisog] Encrypted wireless for students

Gaddis, Jeremy L. jeremy at linuxwiz.net
Wed Aug 22 19:02:20 GMT 2007


Hi John,

I was in the same situation as you were, using the same solution (wide
open wireless + VPN), and getting pretty much the same results (lots
of visits to the help desk).

When we recently purchased new wireless equipment, it was decided that
we'd do things a little different.  Our "new" wireless network will be
opened up for general use next Monday.

The new solution is based upon 802.1x, WPA-Enterprise, RADIUS, and our
enterprise LDAP directory.  Each client (laptop, etc.) will require a
supplicant to be installed (as we're using EAP-TTLS) and, in our case,
that's SecureW2 (http://www.securew2.org/) -- it's open source, by the
way.

Once the necessary configuration files were created, we wrapped them
and the .exe installation program up into another .exe and are
distributing it.  The installation of the supplicant is extremely easy
(next -> next -> next, reboot) and it "auto-configures" itself to
connect to our SSID with the appropriate settings.

Once the user has rebooted, their device will automatically connect to
the SSID at which time they'll get a "balloon popup" near the system
tray saying something to the effect of "additional information is
required to connect".  When the user clicks there, they get the login
dialog box.  They enter their LDAP credentials (optionally saving them
for the future), click OK, and they're connected.

For our deployment, we're using HP 420 access points for the hardware.
 I managed to make sure of completely open-source software as well
(which doesn't matter to some, but it does to me).  The software
involved is the SecureW2 supplicant, FreeRADIUS (for the access points
to authenticate against), OpenLDAP (for RADIUS to authenticate
against), and MySQL (for RADIUS accounting and authenticating
credentials that aren't in LDAP).  We're also using dynamic VLAN
tagging to dump users onto different VLANs (depending on role) and
everything just works(TM) -- that, of course, controls what they
can/can't get access to.

Let me know if you'd like more details...

-- 
Jeremy L. Gaddis
http://www.jeremygaddis.com/



On 8/22/07, John York <YorkJ at brcc.edu> wrote:
> We need to provide easy wireless access for students, but also have to
> meet a state requirement that all wireless traffic be encrypted.  The
> standard hotel/coffee shop setup won't work for us.  2Back in the WEP
> days we decided to go with a captive net connected to a VPN
> concentrator.  The wireless itself is wide open, but the only way to
> escape the captive net is by using a VPN client and the concentrator.
> This works pretty well, but means the students have to install the
> (Cisco) VPN client.  Most of the students need assistance with this,
> which puts a load on the student help desk, and students regularly blame
> us or the client for the viruses or spyware they inflict upon
> themselves.
>
> Of all the WPA flavors, the only one we've had much success with users
> configuring themselves is WPA-PSK.  WinXP-sp2 with patches does a pretty
> good job of recognizing WPA-PSK and normally the user just has to enter
> the password/key.  WPA with PEAP would be most secure, but we've had
> terrible luck with Windows users getting it to work without a
> third-party client.
>
> One solution we are considering is using WPA-PSK to provide the
> encryption, and then using a web portal for authentication.  The main
> problem with this is that the pre-shared key would be common knowledge.
> We could limit that slightly by having the students install a registry
> file with the settings and key, but the key would still be available.
>
> **Question**:  If you know the pre-shared key, is it possible to sniff
> and decrypt WPA-PSK traffic?  If so, is it something a script-kiddie
> could do or is it more advanced?  I'm worried that we would be
> technically meeting the encryption requirement, but giving our students
> a false sense of security.
>
> If WPA-PSK doesn't work, what other solutions are available?  The
> solution has to allow all ports, and not be restricted to 80/443.  I've
> tried an ssl/vpn client, but had problems because it had to install
> itself on the student laptop.
>
> Thanks
> John
>
> John York
> Network Engineer
> Blue Ridge Community College
>
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog
>


More information about the unisog mailing list