Building a Secure Wireless Network Using FreeRADIUS

Markos Gogoulos and Konstantinos Lizos

Wireless networks have penetrated our daily lives in the most amazing and rapid way. The wireless capabilities, the ease of accessing network resources, and increasing bandwidth utilization have all lead to the substitution of obsolete copper wire networks with new, cutting-edge wireless technologies such as Wi-Fi networks.

In this article, we will present the framework (i.e., open source tools, technical equipment, programming methods, and techniques) that we utilized to form a secure wireless network infrastructure for our university campus, capable of supporting 100 simultaneous users and providing them with sufficient Internet bandwidth.

The University of Aegean is dispersed in a complex of five islands, among which is the Island of Samos, situated in the Karlovassi vicinity. (In Samos, a great mathematician called Pythagoras lived 2500 years ago, giving birth to the Pythagorean cult.) There, Aegean University (in September 2003) sponsored us for the development of a wireless network, which would work in parallel with the conventional, wired Ethernet network situated in the university campus district. Although the university suggested conventional wireless technologies, we were eager to try something different.

Project Requirements

The university stated the following technical, performance, and design requirements:

Open source tools -- This requirement was mostly applied so that the system architecture could be altered easily in the near future without changing basic software functionality. Cost was also a strong consideration.

Low-cost hardware equipment -- Due to restricted budget, we were forced to use low-processing hardware with small RAM memory (128 MB).

Security -- Security was a strong issue, since the university required end-to-end security, both in the sense of mutual-authentication and encryption mechanisms. No unauthorized access should be allowed. Also, we had to take into account functions for direct revocation mechanisms and expiration of the client access to the network facilities (in case the service was to be audited in the near future). Furthermore, physical security for the central equipment was to be investigated.

Number of users -- 1000 students currently comprise the university in Samos. It is estimated that the maximum number of students possessing wireless equipment at this time (e.g., wireless laptops, PDAs, etc.) is 100.

Expandability -- The system must be designed in a well-structured manner to expand or shrink according to future requirements.

Centralized management -- The derived system should be structured to be administered from one computer, giving a centralized form of management.

The structural and design requirements presented here for the development of this hybrid network gave birth to a variety of considerations ranging from security aspects to desired coverage area. We utilized the spiral model in order to gradually design and implement that network. We began by designing and implementing independent modules, which we agreed on.

Security Considerations

We were convinced that a conventional password solution was inadequate because there would be a lot of complaints during the operational phase (e.g., forgotten passwords, stolen passwords, etc.). We were also interested in providing a simple, transparent, yet secure solution for the authentication mechanism. We considered the following:

WE P (Wired Equivalent Privacy) -- This technique is applied in many simple wireless systems with less strict operational requirements. It only authenticates the system, not the client. WEP aims to support security through the encryption of data over radio waves so that it is protected as it is transmitted from one end point to another. However, it has been found that WEP possesses many security vulnerabilities (especially in the RC4 encryption algorithm) that can't prevent a determined attacker from penetrating the network.

Filtering MAC addresses -- An alternative solution was to filter the MAC addresses. This method -- though quick and efficient -- is not effective because MAC filtering has an innate flaw. A potential attacker can spoof MAC addresses. This, of course, entails some type of sniffing and MAC virtual replacement, which for the typical user is hard to achieve, but still it is a security hazard that can't be overcome.

VPN (Virtual Private Network) -- This technology is one of the best in the area of secure WLANs and covered all of our requirements effectively. A plethora of commercial VPN firewall servers exist, but since our budget was restricted, that idea was rather discouraging. Even though there are also some free, open source tools involving IPSec [1], we chose not to use this technology for several reasons. First, increased customization would be required from the server's side as opposed to the next technological solution. Second, increased customization must occur on the client side in order to create a functional interconnection. And third, the encryption level of a VPN is superb for our requirements, thus there would be an unnecessary burden for the system (even if the VPN is in the kernel, the delay is inevitable).

Additional security solutions implemented in wired networks (ssh, ssl, pgp) are also options. Our primary goal was a friendly, easy to use, transparent, quick, and secure communication system capable of supporting strong encryption mechanisms and mutual-authentication techniques.

EAP-TLS over RADIUS

RADIUS (remote authentication dial-in user service) is an authentication protocol, developed by the IETF (Internet Engineering Task Force) Radius Working Group. It is an open source software-based tool, capable of supporting configuration, authorization, accounting, and authentication procedures.

On the other hand, EAP (Extensible Authentication Protocol) denotes an authentication infrastructure able to support multiple authentication schemes, with additional capability of creating new security schemas. It was primarily designed as a PPP (Point-to-Point) enhancement (and perhaps replacement). EAP-TLS over RADIUS was eventually our choice, which is explained below.

Figure 1 presents the authentication mechanism for an EAP-TLS authentication schema. From our research, we concluded that this authentication schema covers every security requirement. Apart from the fact that RADIUS is a free, customizable, stable tool, we managed to insert proper scripts, firewall, IP tables, and nocat commands to control and filter the accepting services, the available per user bandwidth, the ports, and the IP addresses so that routing could be dealt with quite easily.

There are both free and commercially available servers (e.g., Microsoft RADIUS, OpenRADIUS) but we chose FreeRADIUS, which has the following functionalities:

Mutual Authentication -- In the first phase, the server is authenticated to the client, and in the second phase the client is authenticated in the server with the use of proper certificates. The certificates are created with the user's personal data and signed with a private key, which the user must insert during the creation of the certificate.

Authorization -- For each new connection, this functionality provides information to the remote access or WLAN access point device, such as what IP address to use, session time-limit information, or which type of tunnel to set up.

Accounting -- Logs all remote and WLAN connections, including usernames and connection duration for tracking and billing.

Central User Authentication -- If more than one RADIUS server is necessary, one of those can play the role of the proxy.

CRL (Certificate Revocation List) -- Certification revocation is a simple task because certificate management is performed in a centralized manner. This functionality is essential in the real-life security management of the system. Although the server did actually cover the full extent of the functional requirements from the university's perspective, we were pretty concerned about the performance of that server under stress conditions (i.e., heavy traffic for user authentication).

Since stress testing was a primary concern, we focused on the design and implementation of a simple programming script, aiming to simulate an unremitting traffic pattern wanting to be served by the RADIUS server. The program is written in C programming language, utilizing the fork() function, and is shown in Listing 1. We were astonished by the results, since the performance and the stability of the server, even with 50 authentication requests per second, resulted in a very small time delay -- infinitesimal and negligible, especially when the signal was in excellent condition (more than 50% signal-to-noise ratio). Table 1 shows the results from the stress simulation.

Setting Up the System

FreeRADIUS was installed onto one Linux computer, with a Pentium IV processor (1.4 GHz) running our favorite distribution, Slackware Linux. Also, OpenSSL 0.9.7c was used for the creation of the digital certificates (for the mutual-authentication phase). We configured FreeRADIUS for proper installation of the FreeRADIUS certificate and for acceptance of communication from the specific IP addresses (concerning the AP) with the proper password verification mechanism (preventing rogue access point attacks).

The process of communication is clear. The client activates the wireless interface (with the desired AP). If more than one exists, the user must choose the correct SSID. A new, TLS channel is underway with the RADIUS server, from the AP and back, requesting the authenticator certificate.

Validation of names and dates take place in the next phase. If successful, the RADIUS server authenticates the client's certificate. If no entry for the user exists in the user record storage facility, or if the certificate is incorrect or expired, FreeRADIUS returns a reject signal to the AP for that specific user and the AP terminates the corresponding session.

If the entry exists and is valid, a WEP key is created for the specific user session and is sent encrypted to the AP (using the RADIUS shared secret). The WEP key can expire after a period (60 minutes, for example) and a new one is exchanged (transparently). AP sends the client the WEP key, with which the user is entitled to encrypt the transmitted data. The wireless interface acquires its IP address from the DHCP server (hosted even by the AP, if requested).

In our case, we have our firewall running NAT (Network Address Translation) and DHCPD, entailing that the connected users are granted virtual addresses. This saves us the trouble of allocating real IP addresses and enhances the network security, because if the firewall is well protected, no penetration to our wireless clients can occur. Even if an intruder breaks the key code, it is impossible for him to log into the network.

System Implementation and Integration

There are three wonderful HOW-TOs for FreeRADIUS EAP/TLS architecture schema [2,3,4]. All three are lucid and understandable. All the same, we need to make the following clarification. Because those HOW-TOs were written before 2003, they required a snapshot version of FreeRADIUS and three different OpenSSL versions (a stable version, a recent snap version, and a beta version), whereas now only one stable is necessary. These HOW-TO's were written when EAP-TLS over RADIUS was experimental. Now, with FreeRADIUS 0.9.3 and OpenSSL 0.9.7c, the scenario can be developed more efficiently. Both OpenSSL and FreeRADIUS are easy to use. In our scenario, FreeRADIUS was compiled with EAP-TLS quite easily. Customizing the following files of FreeRADIUS is necessary, however:

radiusd.conf -- Change: tls=default_eap_type. We must also define where the server certificates are located and provide the FreeRADIUS server with the password that we used to sign them -- more on these later. Further modifications are valid (e.g., arguments; deactivation of other eap types, such as md5; deactivation of other authentication protocols, such as chap; LDAP authentication; PAP; and many more).

clients.conf -- In this file, we define the APs that can communicate legitimately with the FreeRADIUS server. It is imperative to specify their IP (or the subnet to which they belong) and the secret code, which is used to encrypt the messages exchanged with the FreeRADIUS server.

The process is as follows. First, a certification authority (CA) is created. Second, the server certificates and then the user certificates are created. Two files give meaning to the authentication server -- root.pem and <freeradiusservername>.pem. On the other hand, the following files are necessary for every user: root.der (for server authentication), <clientusername>.p12 (client certificate), and an entry addition to the user file [client fullusername and Auth-Type:=EAP].

As far as AP customization is concerned, it is necessary to modify AP settings so that it can take advantage of FreeRADIUS existence. Specifically, we supply the IP of FreeRADIUS and the secret key defined in the clients.conf. With this secret code, the messages that FreeRADIUS and AP exchange are encrypted. Furthermore, we regulate the AP to supply DHCP services (if we haven't declared a DHCP server). We chose mixed security mode, which is authentication through Radius and WEP key creation for every connection and for every client (128 bits long).

Certificates

In this section, we present three scripts plus an OID extensions file for Windows XP clients that would generate the CA, server certificate, and client certificates. These scripts are barely altered from those used by the corresponding HOW-TOs. In particular, we have:

xpextensions - OID extensions (used by CA.clt, CA.svr)
[ xpclient_ext]
extendedKeyUsage = 1.3.6.1.5.5.7.3.2
[ xpserver_ext ]
extendedKeyUsage = 1.3.6.1.5.5.7.3.1

CA.root
#!/bin/sh
rm -rf demoCA
openssl req -new -x509 -keyout newreq.pem -out newreq.pem \
  -days 730 -passin pass:hardcore_pass  -passout pass:hardcore_pass
openssl pkcs12 -export -in demoCA/cacert.pem -inkey newreq.pem \
  -out root.p12 -cacerts -passin pass:hardcore_pass \
  -passout pass:hardcore_pass
openssl pkcs12 -in root.p12 -out root.pem \
  -passin pass:hardcore_pass -passout pass:hardcore_pass
openssl x509 -inform PEM -outform DER -in root.pem -out root.der
rm -rf newreq.pem

CA.svr
#!/bin/sh
openssl req -new -keyout newreq.pem -out newreq.pem -days 730 \
  -passin pass:hardcore_pass2 -passout pass:hardcore_pass2
openssl ca -policy policy_anything -out newcert.pem \
  -passin pass:hardcore_pass2 -key hardcore_pass2  \
  -extensions xpserver_ext -extfile xpextensions -infiles newreq.pem
openssl pkcs12 -export -in newcert.pem -inkey newreq.pem \
  -out $1.p12 -clcerts -passin pass:hardcore_pass2 \
  -passout pass:hardcore_pass2
openssl pkcs12 -in $1.p12 -out $1.pem \
  -passin pass:hardcore_pass2 -passout pass:hardcore_pass2
openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der
rm -rf newert.pem newreq.pem

CA.clt  
#!/bin/sh
openssl req -new -keyout newreq.pem -out newreq.pem  -days 730  \
  -passin pass:user_password -passout pass:user_password
openssl ca -policy policy_anything -out newcert.pem \
  -passin pass:user_password -key user_password -extensions \
  xpclient_ext -extfile xpextensions -infiles newreq.pem
openssl pkcs12 -export -in newcert.pem -inkey newreq.pem \
  -out $1.p12 -clcerts -passin pass:user_password \
  -passout pass:user_password
openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:user_password \
  -passout pass:user_password
openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der
rm -rf newcert newreq.pem

Requirements for Typical Wireless User

A legitimate user who wants to participate in the wireless network must buy a wireless network card. This wireless card must be compatible with the 802.11g technology solution (since our network is operating in the g technology frequency band). All commercial wireless cards are currently supported by Windows XP platform (as far as Windows is concerned). In Linux or Unix, the user must read the specifications of each card for compatibility issues; some cards are supported inherently.

Afterwards, the user must visit the NOC administration department, where he will be supplied a proper certification (customized to the personal data of that person). By default, this certificate is valid for 2 years, but it can be altered for additional or fewer. During the phase of certification generation, a password code will be given to the user. That password must be used during installation to sign the certificate, otherwise the certificate can't be installed. For that reason, the NOC provides a difficult-to-break password. Furthermore, the NOC administration adds an entry to the user's file, located in the FreeRADIUS constellation, in the following form:

"Name Surname" Auth-Type := EAP

Public Key Infrastructure Functionality

What if a computer or laptop is stolen? In that case, we erase the public key of that specific user and supply a new one. The same, of course, applies when the user suspects that his certificate has been stolen. We must also examine the case when a user for some reason loses access to the network (e.g., illegal activities). We erase the corresponding entry from the user's file, resulting in the exclusion of that user from the network. Finally, when a certificate expires, the administration department is responsible for supplying a new one that the user must install.

Conclusions

Utilizing well-designed and well-documented tools from the open source scientific community is an effective way to implement secure wireless network architecture, achieving mutual authentication with the use of digital certificates while also implementing authorization and accounting functions transparently for the end-user. Furthermore, this setup acts as a PKI, assuring the confidentiality of the transmitted data.

Our network is supplemented with DHCPD and NAT services running on our firewall. This, along with the proper firewall scripts for system resource control and the creation of DMZ zones and nocat resource allocation, allowed us to achieve all our goals for supplying a stable and functional wireless network infrastructure, and we can consider our project utterly successful. Furthermore, achieving the same goals with commercial software and equipment would have required an enormous amount of money without guaranteeing the success of the venture.

Future Work

Our future work will focus on the extension of the current wireless network infrastructure -- no further security tuning will be involved. Even in the case of additional FreeRADIUS server installations, the existing will be the central coordinating party. The only remaining task has to do with the expiration of the CA's certificates (in a period of 730 days because that is the time defined by our security policy), ensuring that the legitimate users are supplied with the new certificate and that they properly install it.

References

1. Jarkko Turkulainen: Securing 802.11 with OpenBSD --http://www.klake.org/~jt/tips/80211.html

2. Raymond McKay: FreeRADIUS EAP/TLS/WinXP HOW-TO -- http://www.impossiblereflex.com/8021x/eap-tls-HOWTO.htm

3. Adam Sulmicki's HOW-TO on EAP/TLS Authentication between FreeRADIUS and Xsupplicant [Linux clients] -- http://www.missl.cs.umd.edu/wireless/eaptls/

4. Ken Roser's HOW-TO: EAP/TLS Setup for FreeRADIUS and Windows XP Supplicant -- http://www.freeradius.org/doc/EAPTLS.pdf

5. FreeRADIUS [current stable version: 0.9.3] -- http://www.freeradius.org

6. OpenSSL [current stable version: 0.9.7c] -- http://www.openssl.org

7. Iptables -- http://www.netfilter.org/

8. NoCatAuth: Access control and resource allocation solution implemented on Access Points and written in Perl -- http://nocat.net

Markos Gogoulos is currently doing undergraduate studies in the Aegean University. His main interests are information and communication systems security and systems administration. He is an enthusiast of the free software movement and can be reached at: cs00013@icsd.aegean.gr.

Konstantinos Lizos is a postgraduate student in the Aegean University and is involved in numerous scientific projects. His special interests are in prime number encryption. He can be reached at: icsdm03020@icsd.aegean.gr.