Slashdot Mirror
Are You Using 802.1X?
"Here's our story: we're using Windows 2003 servers (for IAS) and PEAP/MSCHAPv2. We're not offering support for Windows clients prior to 2000 (even though clients do exist for 98/ME,etc). Windows 2000 supposedly has builtin support after SP3, but on June 10, Microsoft released a WEP patch that breaks 1x! (At least for our implementation...) Windows XP SP1 works in most cases, but certain onboard-wireless chipsets (Intel) don't work, regardless of OS. I heard that staff struggled with and finally successfully installed a 3rd party client for RedHat 9, and I'm told there's also a client for Mac OS 10.2.
As far as I can tell, the network guys did their homework--I promise--but this deployment is beginning to look like a disaster! Do you have any wisdom to share about how to pull victory from the clutches of shameful defeat? I realize my question is rather broad and vague ... but I'm really interested to see what discussion comes up. Thanks!"
No.
Next question please.
Personally I doubt why you would go with a system that makes you scrounge for clients on different OS's just to implement at a university. In the corporate workd you have the luxury of saying "If you want to use out network you will use "n" hardware and nothing else."
At the university level you have people using about 300 different configurations and OS's. If seems like you are making if just that more difficult for those users that get use out of the network that they pay for through their tuition.
Get SP4 which gets the .1x support back.
Did "homework" include a reasonable test implementation? Anything that affects your infrastructure in such a drastic way should probably be banged on for several weeks with at least a dozen guinea pigs (assuming you don't have a test lab in these days of cost cutting).
Help save the critically endangered Blue Iguana
Take a look at what Purdue University does. They use a Cisco VPN client that is available on win/mac/linux/sun, and ties in with the student accounts to verify access. If you aren't using the VPN client, you are redirected to download it automagically. http://www.itap.purdue.edu/airlink/ This is the best solution I have seen.
not using even WEP is simply asking for trouble, using basic WEP (pre-shared keys) is a little better, but its still vulnerable and has the hassles of key management (each time you change the keys you need to update all clients). 802.1x is the way to go.
There is some support on OSes for 802.1x (Windows XP has it built it for some authentication methods, for Windows 2000 you can download it from the Microsoft website, for Linux and BSD use xsupplicant (http://www.open1x.org).
One important consideration is what 'EAP method' you use for security. 802.1x is a framework for security and you can tie-in different methods within this framework for doing the actual authentication and key generation.
If you use EAP-TLS then there is can be a problem of configuring certificates on client machines, though its pretty secure once setup. You can use the cisco proprietary LEAP with Cisco AP's and clients or go for a solution based on PEAP or EAP-TTLS.
LEAP only requires you to have a user-name/password type of setup and can be easily tied to existing authentication infrastructure (Eg: the windows network in your LAB). PEAP and EAP-TTLS need only a username and password if you use MS-CHAPV2 or some such method, though you still need valid server-side certificates.
Puneet
I know a lot of people rag on 1x because it isn't supported by every POS WiFi card out there but the security enhancement you get is really indispensible espeically when you consider that your average corporate WEP network is no safer than my linksys AP at home.
A really great client for getting multiple cards to work on 1x networks is the Aegis client from Meetinghouse Their supplicant will take many standard WiFi cards and allow them to use 1x.
Our IT dept doesn't support it (most probably won't) but if you're a frustrated user who doesn't want to buy a new card for a 1x network they've got a 15 day demo which should give you enough time to figure out if it works for you.
I used it on my last contract. 802.1x with WindowsXP SP1 works just fine. We used PEAP and Microsoft's IIS server for RADIUS authentication.
We wanted PEAP since it doesn't require manual certificates.
It took a lot of tweaking on the server, a small bit on the AP, but the client settings were just what you'd expect them to be.
I didn't try it with OS X (even though I used a Powerbook on the job). Take a look at http://www.mtghouse.com/
Per the message boards I've read, their client should work just fine.
Failure is not an option. It comes bundled with your Microsoft product. -- Ferenc Mantfeld
i alway thought that 802.1x was a set of protocols - i always thoughs the x was a varaible... i know better now. :(
You are confusing me with someone who cares.
using dlink's new firmware for the 900ap+ which supposedly supports 1x and funk softwares radius server and winxp sp1 i thought i would give it all a try...lets just say its not as easy as i would have expected. and in my experience, if its not easy to impliment then people wont use it. let alone how picky you have to be with OS's,clients,hardware that will actually support it.
We just rolled out 802.1x at Baylor University this week. Where are you located? I know they are also rolling out at Memphis.edu and Kstate.edu in the fall. E-mail me if I can be of any help...
Well, I work for a large company. We're just getting 802.11b with Cisco's LEAP authentication fully deployed throughout the country. I doubt they will move forward (unless Cisco tells them to).
*sigh*
Outside of the Access-points we used all pre-existing equipment. We already had a Enterprise Root Cert Authority setup on our Root Win2k DC. We then created a cert for wireless access. We deployed the cert by using policies and used IAS to authenticate the users against a remote access policy that verified users group memberships.
For Hardware we used Cisco 1100's and Zyair B1000's (Http://www.zyxel.com). The B1000's have a beta firmware to support EAP-TLS and cost less than $100 bucks!
We only allow Win2k and Windows XP clients to use wireless, setting up the few win98 clients we have is too much of a pain!
With Windows XP Service Pack1 the user will get a prompt that says there is a wireless network available. Included in that is a check box to use 802.1x authentication and since the default is Certificates all the user does is click connect and they are on!
If you have clients other than windows clients you can still use the win2k cert server, just have then download the cert via the web manager. IT will be http://certservername/certsrv. Works great.
My impression is that this is a much needed, but still nubile technology. I wouldn't be surprised to see stronger support flourish in the 'alternate' (non-MSFT) OSes within the next year or so. Microsoft seems to be a bit ahead of the game on this one.
I don't know about you who use WEP, but please STOP.
It is BROKEN.
Use IPSec. There are many tutorials for using IPSec in tunnel mode as a replacement for WEP. Google it. I wrote the 3rd or 4th one down - it isn't that hard, guys. Please don't use WEP, it really isn't smart.
802.1x authentication is not a new concept. It was developed many years ago for incorporation into the HP ProCurve product line for port based authentication. The good thing about 802.1x is that at least it does provide some encryption from the authenticator to the radius server. So its either this of captive portal, which is implemented into hotspot controllers to provide authentication via redirection of http requests to a website that requests user/password pairs authenticated off a radius server. Pick your tool, something needs to be done.
At our University we deployed 802.1x and in this
way we reached the highest possible level of security - nobody, even the authorized personel can not log-in. This means that users have complete
protection from hackers, viruses and similar.
While there are multiple solutions and types of 1x, they do seem to work together. We support EAP-TTLS, TLS, PEAP, and LEAP on our network just by enabling it on the server side. Mac address filtering would provide way to many headaches for the number of users we have to support. Fortunately, with Cisco hardware, they manage to support more OS's than most. As soon as there is an open source PEAP client, I don't even think it will be an issue anymore. That's seems to be the direction things are going considering future windows support.
Another feature of 1x is that it provides fairly good encryption through rotating keys. This is much better than 40/128bit encryption. In the end, it comes down to support issues and decent security. We have several linux/BSD users on our network but they all have to use cisco hardware. Other than the cost, it works great, but our network is 150+ APs, so this sort of solution might not work on a small scale.
The IPSec tunnel is established between the two computers communicating. There would be no reason for the AP to do any processing other than what it already does - moving packets.
right now IPSec should be the solution. Given what the question asker just posted it's pretty clear that 802.1x is "half baked" as far as a standard goes. IPSec howerver has been out for a while and it's evils are pretty well known. Certainly not easy to setup but as far as ubiquity goes, it's available on almost every platform. In addition - IPSec enhances not only the security of your wireless connections, it also enhances the security of the wired network. With a good certificate distribution infrastructure and a knowledgeable support staff IPSec is a viable alternative.
Hi,
s Whitepaper.pdf
e x.html
;)
I work at the University of Utah. We're currently rolling out 802.1x.
My building has already rolled out 802.1x on about 36 access points. We've been running for over a month and a half.
We've got a lot of people interested in what we're doing. We're using a decentralized model that allows us to let various departments use their user accounts everywhere else on campus (that is using 802.1x).
Check out our whitepaper for more information:
http://utahgeeks.sourceforge.net/projects/Wireles
The paper covers various issues. Keep in mind that the paper is not quite done yet, but it does have a lot of useful information.
We're officially supporting Mac OS X, Windows 98, Windows 2k, and Windows XP. We're not officially supporting Linux, but my boss and I are lead developers on the open1x project (http://open1x.sourceforge.net).
It has Linux and Mac OS X support. We support TTLS, TLS, PEAP (in CVS), MD5, and we're going to be implementing EAP_AKA pretty soon.
If you're interested in the specifics please check out some of our support pages:
http://www.laptop.lib.utah.edu/global/support/ind
The biggest problem has been support for various cards on Windows. The support link above lists the cards we've tested.
We're currently only supporting Airport on Mac OS X due to the lack of a public API from Apple. (Please let apple know that you want a public wireless API so we can support more cards...
We're using a campus site license of the Meetinghouse supplicant for Mac OS X, and Windows. We're using Radiator, a perl based (VERY NICE!) radius server. It's 802.1x implementation rocks.
More info on Radiator: http://www.open.com.au
802.1x is becoming the University of Utah campus standard. All future wireless purchases made with student task force moneys will be required to be 802.1x compatible.
Please let us know if you have any questions regarding our setup.
I'm running a public WI-FI access point and I've had several people tell me that I should look into one of these encryption methods. Personally, I don't get it. If you're using WI-FI for your internal network then I understand, smb passwords flying around, people dropping into your NFS system, but for simple, public internet access does it really matter?
It seems to me that this type of encryption may not even belong at the connection level. Any type of encryption is going to add significant overhead so shouldn't be up to the application to use make secure connections as needed? For most web browsing, who cares if the signal is intercepted, if you're sending passwords or credit info you should be using https anyway. Likewise IMAP, POP3, FTP and SMTP, use the SSL wrapped alternatives.
Is there something I'm missing here? Shouldn't it generally be up to the app to determine if the overhead of encryption is required.
Check out the open1x project.
;)
http://open1x.sourceforge.net
I'm not only a client, I'm also a developer.
At NU the IT department has deployed hotspots at a variety of locations. The campus cafe, parts of the student center, certain locations in the dorms, libraries, as well as other locations provide wireless access.
WEP is not used to secure the network. Instead they're using VPN to provide authentication as well as secure/encrypted connections. Nothing beyond the VPN server and other clients of the AP are accessible without connecting to VPN. As an added benefit VPN allows off-campus users to use the NU mail relays, and other things that are restricted the university subnets.
Check it out:
http://www.tss.northwestern.edu/wireless/
http://www.tss.northwestern.edu/vpn/
What we've done is placed a small firewall just outside our main firewall on the same ISP subnet. All clients must use the same VPN software they use when traveling to then access the network through the main firewall. Rules in place on the small firewall only allow authenticated traffic hubbed through the main firewall and nothing else. So you don't even get a free ride on Internet access if you break into the network. 802.1x is definitely next and we may or may not keep the IPSec.
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
802.1X gives you an authentication mechanism, and a way of automatically distributing WEP keys.
WPA is an "early release" snapshot of 802.11i. It requires the 802.1X access control mechanisms and a souped-up version of 802.1X key management. Whether WPA requires EAP-based (RADIUS-based) authentication or a manually-entered key depends on how you configure it.
I have had plenty of experience with 802.1x installed at a major american university (which may be the same university the article submitter works at).
Thanks to the 802.1x deployment, I have zero wireless networking capability under FreeBSD. Ah, that takes me back to my freshmen year of 1996.
One future, two choices. Oppose them or let them destroy us.
There's a good piece in the June NetworkWorldFusion talking about MSFT, Cisco and few other large installations.
Protect the upper layers not below 3
Hack layer two... yippee! yippee!
Since WEP 40/128 provide NO security at the high layer... people feel they're getting something
with WPA (most won't run the required auth/radius server though.. so it's even worse).
Layer 2 is still open. You'll have to wait until next year when the 11i crew comes out with something.
As for a resource, use Dr. Arbaugh's new book on the subject.
http://www.amasin.com/-/0321136209/Real
802.11x is little more than Cisco's LEAP technology that has been turned into an industry standard.
Trying to secure a network at layer two is extremely dificult. You're not dealing with enough intelligence and flexibility. Taking it up another layer to layer three (network layer) gives you much greater flexability.
You need to look into the wireless gateway technologies. Its easiest to think of these as being a firewall and VPN concentrator combined into one box.
Just as an internet firewall is designed to secure internal corporate networks from external internet communications, the wireless gateway once again segments your network with wired and wireless.
Encryption takes place at layer 3 using IPSec when required. Using a wireless gateway, you can have a guest user log into your network as a guest, and the gateway will allow them to access the internet, and only the internet -- and you can throttle their bandwidth down to 56kbps or whatever you'd like. However, if I were to login to the network as an internal user, the gateway would build a 3DES IPSec tunnel out to my PC before it would allow me to access ANY internal network resources.
It allows you the flexibility to give different users various levels of security based upon their login. The best part is that it does not require a client to be loaded on any end user device, and because it operates at layer 3, it is layer 2 agnostic - meaning it doesn't matter what kind of Access Point or radio card you're using.
I've deployed these solutions in hospitals, universities, even classified government facilities. (WEP is not FIPS certified, 3DES is)
Good security is based upon reality and common sense. Common sense is a function of having common knowledge.
802.1X, TKIP, WPA and so on are all nice methods to control WLAN access, but even they cannot correct a louzy WLAN architecture.
The problem is that in several, even most places, people are connecting their access points directly to their intranet and then rely only on the WEP key, MAC address lists, 802.1X and the WiFi security standard of your choice. In this kind of architecture when a standard is broken or the access point is compromised or just mis-configured, the attacker is able to gain access instantly to the protected network.
In our university this was the starting situation. Every department had their own WLAN with own WEP keys and MAC lists and some didn't even have those, just completely open network without any kind of access control. Not to mention about radio channel allocation or planning. Instead of the seamless, combined radio coverage there were several separate networks often disturbing each other.
A project was then started to define a common architecture for building wireless network securely and to provide that seamless combined radio coverage instead of all these kind of wild networks. What we decided was that WLAN networks are hostile networks and they should be treated as such. In the new architecture the organisation wide WLAN network is separated outside protected networks so that even if the access control of the wireless networks is breached, the only access the attacker directly gains is the access to the Internet, not to organisation's protected networks.
We didn't choose to use WEP key and MAC access control lists because they were useless. We didn't yet integrate 802.1X as a access control, because the terminals aren't yet ready for it. Instead we chose to build our WLAN network by using a captive portal to control the traffic demanding less security and VPNs to protect the traffic demanding more. By providing several means to authenticate we achieved the better interoperability and usability of the WLAN network than before.
With this architecture we are now able to server several different terminals, utilise old access points not capable of WEP encryption and support the customised solutions the different departments want to use. The architecture supports even Radius-based WLAN roaming so that people between organisations may use their home user accounts for authentication in the roaming partner's public access network. The same roaming architecture can be then used even if the WLAN network is in the future migrated to the 802.1X.
-- Karri Huhtanen http://www.iki.fi/khuhtanen/
The only credible attack in that paper was a DOS attack. A properly configured system would be able to avoid the man in the middle and session hijacking attacks described there. DOS probably isn't a really huge problem with low power wireless since it will be pretty easy to locate the attacker.
I don't want free as in beer. I just want free beer.
We are running Funk Software's Steel Belted RADIUS (SBR) on Solaris for 1x authentication requests using TTLS. SBR verifies user credentials on the back end against our OpenLDAP server. We also return the group membership of the validated user with each login so the RAS can implement individual firewalls (at the user's point of access!) based on each users' credentials (aka User Personalized Networking). This is essential for supporting large numbers of open-access ports (i.e. dorms, Library, Student Center, labs...)
We use Enterasys equipment exclusively, including their R2 access points for wireless. We use their Netsight Atlas Policy Manager software to enforce UPN policies.
We have an academic site license for the Meeting House Aegis 1x client. This has worked brilliantly with 2000/XP and MacOS. Linux support has been shaky (it's beta) but we have had success with Open1x in that application. The problem with the Mac is that it doesn't come preconfigured with any certificate authorities under OpenSSL, so we have had to add one manually to each station.
The only problems we have had is a small bug in SBR that caused it to periodically lose contact with LDAP (fixed in SBR 4.0.4) and some quirky early versions of the Aegis clients (fixed). Meeting House has also just released (beta) an enterprise-deployment option that allows us to distribute a preconfigured client. Funk's client is worth looking at also, but it is very pricey.
My sugestions: plan well, test a LOT, and stay the HECK away from any of the MS garbage -- your life will be MUCH simpler!
Why not use IPsec instead?
:>
It's more standardized, it's available on more clients, and if you have a large number of connections through hosts you can use crypto accelerator boards on your routers (running BSD or Linux).
The main issue would be distributing public-key certificates. This could be automated though: have a web page where the netops staff fill in fields for the user infromation (including a valid email address), generate the certificate witha Perl script/CGI and enter all the information in a database. The generated certificate is then emailed (in clear-text, I know) to the user with a link to a PDF on how to setup their client.
For student accounts you could have the certificates expire on a yearly basis so you don't have old ones lining about. I don't know about the expiration of staff/faculty certificates though. You could perhaps generate a certifacte-revocation list (CRL) and transfer that to your routers using something like scp/scp/rsync.
1x is not widely deployed so people are still trying to figure things out. You're basically a beta tester for the rest of us.