IEEE 802.1X is a protocol meant to grant access to clients (whether wireless or wired) on a network at the level of ethernet frames. A rough schematic is the following:

With the following components:

• the client can be any device that wants to connect to a network, usually a laptop, a phone or a PC.
• the authenticator is usually a switch that supports 802.1X - the switch takes care of talking to the RADIUS backend to authenticate clients and most importantly, the switch should be able to block any other traffic to the network until the client has authenticated.
• the authentication server usually provides a mechanism called AAA: authentication, authorization and accounting. In cases such as FreeRADIUS, it usually supports a large number of backends itself for the accounting part, such as LDAP, SQL, PAM, and so on…

For this tutorial, we will use a PC as a client, hostapd as an authenticator, FreeRADIUS as an authentication server and PAM as an accounting backend. When 802.1X is implemented on the network, the general desire is to block any traffic to the network until the client has successfully been authenticated by the authentication server. This is generally called a "captive portal" because any client will be able to join an isolated network until the client has authenticated and will be able to access a limited amount of services - usually, that implies a dud webpage, such as the ones found in airports, hotels or others where you have to pay to access the Internet.

The major issue in this setup is that hostapd does not have hooks to trigger scripts once a client has authenticated (and de-authenticated) and thus traffic cannot be blocked at the switch level using hostapd. However, some workarounds are possible in case the authentication server (FreeRADIUS in this case) runs on the same machine as the authenticator hostapd and they will be illustrated here but they should not be taken as a proper implementation of 802.1X.

On Debian-like systems, FreeRADIUS is installed using:

aptitude install FreeRADIUS

After which a few configuration changes have to be made to enable PAM and, more generally, to set-up FreeRADIUS to serve requests from the authenticator hostapd.

One of the advantages of Debian-like systems with package management is that you generally are lucky enough to get an "almost-working" set-up right from the install. That is, Debian already generates the certificates necessary to run FreeRADIUS as well as setting-up the necessary if-up/down hooks for it.

The clients.conf configuration file that can be found in /etc/FreeRADIUS/clients.conf needs to be edited in order to set a password that will be used between the authenticator (hostapd in this case) and FreeRADIUS.

The only suggested change on Debian is to change the secret line around line 100 in the clients.conf configuration file in order to set a password:

--- clients.conf.dist	2013-07-10 07:11:04.000000000 +0100
+++ clients.conf	2013-07-09 23:17:20.000000000 +0100
@@ -98,7 +98,7 @@
 	#  The default secret below is only for testing, and should
 	#  not be used in any real environment.
 	#
-	secret		= testing123
+	secret		= p0rd
 
 	#
 	#  Old-style clients do not send a Message-Authenticator

This snippet changes the password to p0rd, but any other password can be set. Note that this password will be used between hostapd and FreeRADIUS and will not be used by any client machine - it is an additional layer of security to make sure than an authenticator, such as hostapd will only be able to use the authenticator service (FreeRADIUS in this case) to authenticate clients.

The eap.conf configuration file in /etc/FreeRADIUS can should be changed to enable PEAP and to optionally turn on credential caching:

--- eap.conf.dist	2013-07-10 07:11:08.000000000 +0100
+++ eap.conf	2013-07-10 00:05:09.000000000 +0100
@@ -27,7 +27,7 @@
 		#  then that EAP type takes precedence over the
 		#  default type configured here.
 		#
-		default_eap_type = md5
+		default_eap_type = peap
 
 		#  A list is maintained to correlate EAP-Response
 		#  packets with EAP-Request packets.  After a
@@ -315,7 +315,7 @@
 			      #  enable resumption for just one user
 			      #  by setting the above attribute to "yes".
 			      #
-			      enable = no
+			      enable = yes
 
 			      #
 			      #  Lifetime of the cached entries, in hours.

PAM can be enabled by editing the configuration file /etc/FreeRADIUS/sites-enabled/default:

--- default.dist	2013-07-11 01:10:59.000000000 +0100
+++ default	2013-07-10 11:58:04.000000000 +0100
@@ -263,7 +263,7 @@
 
 	#
 	#  Pluggable Authentication Modules.
-#	pam
+	pam
 
 	#
 	#  See 'man getpwent' for information on how the 'unix'
@@ -469,6 +469,9 @@
 	#
 #	ldap
 
+	# perl module
+	perl
+
 	# For Exec-Program and Exec-Program-Wait
 	exec

The perl addition after ldap on line 473 is not necessary but will be used later to illustrate a simple (and broken) demonstration of a captive portal.

PAM is used in this case because it is an authentication mechanism that is used extensively in Debian-like systems. One could opt for something more elaborate such as ldap or even SQL but that would increase dependencies and the purpose is to integrate 802.1X as much as possible with the existing system.

PAM has one distinct limitation: passwords that will be used to authenticate against the PAM system will have to be supplied in plaintext by the client. This is the reason why, for example, PPPd servers do support PAM but the authentication scheme must use PAP instead of, say, MSCHAPv2.

Having said that, the tutorial will use TTLS-PAP to authenticate - TTLS is a cryptographic encapsulation mechanism that provides secure inner-authentication mechanisms such as PAP, CHAP, MSCHAPv2, and so on… Thus, even though we will be sending plaintext passwords by using PAP, they will be encapsulated within an encrypted layer provided by TTLS making them impervious to packet sniffing.

The screenshot above shows how to enable 802.1X with TTLS-PAP as authenticator on Mac OSX.

The inner-tunnel configuration file at /etc/FreeRADIUS/sites-enabled/inner-tunnel has to be modified to update the auth-mechanism to PAM. This can go after the ldap auth-type:

--- inner-tunnel.dist	2013-07-11 01:11:15.000000000 +0100
+++ inner-tunnel	2013-07-10 00:00:10.000000000 +0100
@@ -141,6 +141,10 @@
 	#  already been set
 #	ldap
 
+        update control { 
+                Auth-Type := PAM 
+        }
+ 
 	#
 	#  Enforce daily limits on time spent logged in.
 #	daily
@@ -212,7 +216,7 @@
 
 	#
 	#  Pluggable Authentication Modules.
-#	pam
+	pam
 
 	#
 	#  See 'man getpwent' for information on how the 'unix'

The following block:

         update control { 
                 Auth-Type := PAM 
         }

is essential, otherwise clients will fail to authenticate via PAM (this took a lot of digging through the documentation).

hostapd can be installed by issuing:

aptitude install hostapd

After that a configuration file, for example, /etc/hostapd.conf has to be created including the following:

# The wired interface
interface=eth0
# ... and wired driver
driver=wired

# Enable 802.1X
ieee8021x=1
# We are not an EAP server
eap_server=0

# Crucial to allow quick 
# re-authentication
ap_max_inactivity=5

## RADIUS is on localhost
# Authentication
auth_server_addr=127.0.0.1
auth_server_port=1812
auth_server_shared_secret=p0rd
# Accounting
acct_server_addr=127.0.0.1
acct_server_port=1813
acct_server_shared_secret=p0rd

Aside from the obvious, an interesting setting here is ap_max_inactivity = 5 that allows a client to re-authenticate 5 seconds after it has disconnected. Without this setting, and by using the default, if a client disconnects, it will have to wait longer until it can authenticate again.

After these settings are made, hostapd can be enabled by editing /etc/defaults/hostapd and setting the DAEMON_CONF variable:

DAEMON_CONF="/etc/hostapd.conf"

Now, hostapd is ready to be started using /etc/init.d/hostapd restart.

Several software bundles can be used to create "formal" captive portals. Probably, the most notable ones are:

• Grase Hotspot
• Coova Chilli

They are complete solutions, including webpages, proxy set-ups, etc…

They are heavy-weight solutions that rely on other software packages and that is why we provide two alternate solutions that can use hostapd and provide a decent captive portal without the need to install additional software.

One should note that 802.1X can be used to grant clients access to trusted network but 802.1X by itself does not provide traffic encryption. The authentication phase is encrypted but after that all packets are transmitted in clear.

802.1X could be combined with IPSec to provide for additional traffic encryption in case the "trusted network" is not to be trusted.