Thursday, November 26, 2009
Configuring Strong Wi-fi (802.1x) Authentication in Linux
In this tutorial series, we'll first see how 802.1X authentication fits into the big picture of wireless LAN security.
Then we'll configure the authentication settings in Ubuntu. Lastly, we'll review the manual configuration of 802.1X supplicants.
Lets get started!
The transition from WEP to WPA to WPA2
Back when the vulnerabilities of WEP encryption for Wi-Fi networks were uncovered, the IEEE and wireless industry started developing new protocols and standards.
They came up with the 802.11i, a standard to finally implement a fully secure encryption mechanism for wireless LANs.
Before it was completed, the Wi-Fi Alliance released the Wi-Fi Protected Access (WPA) encryption standard, loosely based on 802.11i using TKIP for the underlying encryption.
Later they released WPA2, which includes full support for 802.11i using AES/CCMP encryption.
As many news outlets have discussed lately, there have been more flaws found in the first version of WPA.
However, unlike some reports say, it hasn't been cracked; full encryption keys or passphrases haven't been recovered.
The flaws apply to the underlying TKIP encryption and affects both the Enterprise and PSK modes of the first version of WPA.
This does not have anything to do with WPA2, which uses a fully secure AES/CCMP encryption.
Though WPA currently provides adequate security, especially with long and mixed character passphrases, you should try to migrate to WPA2--and make sure you don't use WEP at all.
The two modes of Wi-Fi Protected Access
Both WPA and WPA2 can be used in two very different modes: Enterprise (802.1X/EAP) and Personal (PSK).
In full WPA and WPA2 implementations, wireless clients authenticate themselves via the 802.1X/EAP protocol to an external RADIUS server, whereas the Personal mode doesn't.
Though the Personal mode is much easier to setup and is fine for residential use, it is necessary to authenticate clients on business networks.
Instead of entering static encryption keys into clients, the keys in the Enterprise mode are negotiated and changed automatically in the background after authentication when connecting to the network.
This dynamic keying of the Enterprise mode has real-world benefits. The actual encryption keys that unlock the Wi-Fi connections aren't stored on the computers like with the Personal mode.
Therefore, if a computer is stolen, the thief doesn't have the keys to the network. Plus employees would never see the keys.
They'd present a username and password, digital certificate, or smart card in order to access the network, which would be used in the 802.1X authentication.
These credentials could be revoked by the network administrators as needed, unlike when using the Personal mode, where they'd have to change the encryption keys on all the computers.
802.1X supplicants
A fancy name for the client software that represents the client end of the authentication is a 802.1X supplicant.
You input the credentials into the supplicant. The supplicant communicates with the authenticator, such as a wireless access point or switch, which then talks to the authentication (RADIUS) server.
So in order to connect to a 802.1X-enabled network, you must install a client. Years ago this wasn't the easiest task when using Linux. Cisco and Microsoft basically held the only supplicants.
Even though open source supplicants were developed, they weren't very simple to configure.
However, now some Linux distributions have integrated the 802.1X settings into the OS GUI, where configuring them and inputting the credentials is pretty trivial.
The two main 802.1X supplicants projects in Linux are Xsupplicant and wpa_supplicant.
The Xsupplicant has been around since 2003 and is developed by Open1X and backed by the OpenSEA Alliance.
The wpa_supplicant has been around since 2004 and is developed by Jouni Malinen and other contributors.
Both clients run on Linux and Windows and have a GUI application in addition to text-based configuration.
The wpa_supplicant project also supports BSD and Mac OS X.
Not only is Ubuntu 9.10 already loaded with the wpa_supplicant, its own networking GUI communicates directly with the supplicant.
Configuring 802.1X authentication and connecting to WPA or WPA2 Enterprise networks in Ubuntu is pretty straightforward.
When you're ready to connect, simply click the network icon on the top of the screen and select the network from the list.
If you're using a password-based EAP protocol, like the popular PEAPv0/EAP-MSCHAPv2, you'll be prompted to enter the authentication settings, such as seen in Figure 1.
This also assumes the wireless card and driver supports WPA/WPA2.
First, verify Wireless Security is set to WPA & WPA2 Enterprise. Then choose the Authentication protocol that's supported by the authentication server, such as the popular PEAP protocol.
Unless your authentication server is set to accept anonymous connections, ignore that setting.
Next you should choose a CA Certificate file, so the client can verify it's connecting to a legitimate authentication server before completing its authentication.
Though you can skip this setting, it's recommended to validate the server's certificate for full security.
If the authentication server is loaded with a SSL certificate purchased from a Certificate Authority like VeriSign or Godaddy, you'll have to download their public root certificates from their site since Ubuntu isn't already loaded with them like in Windows.
If you created your own self signed certificates like with openssl, you need to select the root CA certificate that was created.
Now you can set the other settings for the EAP type you selected. If you selected PEAP, for example, you can leave the PEAP Version as Automatic and the Inner Authentication as MSCHAPv2.
Finally, input a Username and Password that's setup in the authentication server or backend database.
When you're done, click Connect. Give it a couple of seconds to complete the 802.1X process and it should successfully connect up to the network.
If not, double-check the settings and check the debug or logs on the authentication server.
Stay tuned--in the next part, we'll see how to manually configure the 802.1X supplicants.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment