Wireless LAN Security using IEEE 802.1x and RADIUS


At work, we were considering using RADIUS and EAP-TTLS in one of our wireless WAN system designs. In general, I get a better understanding of how things work from making things work than I get from reading how things work. Therefore, I decided to upgrade my home wireless LAN equipment to support IEEE 802.1x so that I could experiment with RADIUS and EAP-TTLS at home.


I bought a D-Link DWL-7000AP IEEE 802.11a/b/g access point. While I did not need IEEE 802.11a/g support, I thought that it would be fun to play with that too, so when I bought an access point with IEEE 802.11a/g support. Among other things, the access point supports IEEE 802.1x and WPA-Enterprise (which uses IEEE 802.1x) for improved security.

Authetication Protocol

Neither IEEE 802.1x nor WPA-Enterprise specify a particular authentication protocol. However, for maximum security I wanted a protocol that

In theory, both EAP-TTLS. and EAP-PEAP meet the criteria, but practice shows that EAP-PEAP implementations do not protect the client's identity from eavesdroppers. In addition, EAP-TTLS appears to have more support within the IETF. Therefore, I would prefer to use only EAP-TTLS. However, while Windows XP, MacOS X and GNU/Linux have built-in EAP-PEAP support, only MacOS X and GNU/Linux have built-in EAP-TTLS support. Therefore, in order to make setup easier for Windows XP clients, I decided to support both EAP-TTLS and EAP-PEAP.

Tunneled Authentication Protocol

Both EAP-TTLS and EAP-PEAP establish an encrypted tunnel between the authentication server and the client. Then, the authentication exchange is performed inside the encrypted tunnel. Both EAP-TTLS and EAP-PEAP can tunnel many different authentication protocols.

Naturally, Windows XP clients tunnel EAP-MS-CHAPv2 inside an EAP-PEAP tunnel. As a result, I support EAP-MS-CHAPv2 inside EAP-PEAP.

GNU/Linux clients using either xsupplicant or WPA supplicant support a variety of authentication protocols inside an EAP-TTLS tunnel, including PAP, CHAP, MS-CHAP and MS-CHAPv2. MacOS X clients have similar support. Since I store hashed passwords (SSHA, NT and LM) in LDAP, I cannot use CHAP. Therefore, I support PAP inside EAP-TTLS. In addition, because I am already supporting EAP-MS-CHAPv2 for PEAP, I support MS-CHAPv2 inside EAP-TTLS.

Security Considerations

After EAP-TTLS and EAP-PEAP were developed, they were found to be susceptable to a man-in-the-middle attack under certain situations. The attack and possible solutions are outlined in EAP binding. If the client does not allow the use of the same authentication protocol inside and outside the tunnel, then this man-in-the-middle attack is not possible Therefore, until the protocols are fixed, care should be taken in configuring the clients. Personally, I configure my clients so that they will not use any authentication protocol outside the tunnel.


Both IEEE 802.1x and WPA-Enterprise use a RADIUS server for centralized account management.

For GNU/Linux in general and CentOS in particular, the RADIUS server of choice is FreeRADIUS.

Of course, in order to support my goal of a single account per user, I needed to backend may RADIUS server into my LDAP server. Thankfully, this is supported by FreeRADIUS.

FreeRADIUS Configuration

I tailored some of the FreeRADIUS configuration files (found in /etc/raddb) in order to match our configuration.

Feel free to look at my tailored configuration files (/etc/raddb/radiusd.conf, /etc/raddb/eap.conf, /etc/raddb/clients.conf and /etc/raddb/users) I have removed the LDAP password from radiusd.conf and the RADIUS secret from clients.conf.

OpenLDAP Configuration

FreeRADIUS needs to search the LDAP database for users and groups. In addition, FreeRADIUS needs to be able to read the sambaNTPassword attribute in order to validate the MS-CHAPv2 response, I have configured FreeRADIUS to bind as the user radiusd for searching and reading. Therefore, I have configured the OpenLDAP /etc/openldap/slapd.conf file to allow the radiusd user to search the users and groups subtrees and to read the sambaNTPassword attribute.

Finally, I added the users-wlan group to the LDAP directory to act as the group that controls wireless LAN access.