802.1x

IEEE 802.1X is an IEEE standard for port-based Network Access Control; it is part of the IEEE 802 (802.1) group of protocols. It provides authentication to devices attached to a LAN port, establishing a point-to-point connection or preventing access from that port if authentication fails. It is used for certain closed wireless access points, and is based on the EAP, Extensible Authentication Protocol (originally RFC 2284, now RFC 3748).

Introduction

Summer Internship (2008)

As part of JANETs ongoing research into 802.1x and the progression of the OpenSEA Alliance, money was maid available for funding of 2 interns User:StuartHarland and Sean Hughes. Their brief was to investigate 802.1x clients (specifically Xsupplicant) and to provide feedback on its development.
Further to this, a case study of implementation was required, and as such the integration of 802.1X into SOWN commenced.

Interoperability with SOWN

The secondary objective of the Internship is to see how SOWN can be improved with regard to the introduction of 802.1x into its network. ECS Wireless currently offers limited 802.1x support, via eduroam but it is keen to extend this to all of its wireless, reasons for this include security flaws with MAC address authentication. Similar issues exist with SOWN.

Clients

There are a multitude of clients which claim to support 802.1x on various platforms. These include:

These clients have all been looked into, with special regard for Xsuplicant.

Implementation

Access Points

Captive Portal

802.1x isn't directly compatible with our Captive Portal. With it enabled on a wireless interface, noone can connect without a valid EAP login. This is further exasibated by the current firewall permissions, that deny any wireless traffic. Obviously if you have taken the trouble to authenticate via 802.1x, you do not want to have to then login via our captive portal

Firewall

Luckilly the MadWifi driver for the Atheros chipset supports multiple SSIDs on multiple virtual interfaces. These are assigned via athN
Under 802.3 ethernet cards, ordinarilly it creates a virtual interface on eth?:? which is handled by the firewall as eth%1. Using athN means that iptables can handle traffic on each interface seperatelly as opposed to all wlan traffic being grouped together. Subsequently adding an iptables firewall that grants access to all FORWARD traffic on athN will allow any authenticated device on the 802.1x interface to access the interface

This is ok if and when traffic on ath1 is authenticated. In its current form, it will allow anyone full access.

NAS software

This is where hostapd comes in. Hostapd is a Linux authentication daemon. It forwards 802.1x packets to a radius server which authenticates the user. This then sends back an Access-Accept or Access-Reject packet which either grants or disallows access to the AP.

Hostapd is available for OpenWRT as an ipkg. Specific setup instructions are available on its page.

Radius

Captive Portal

At the commencement of the project all SOWN authentication was conducted via Captive portal login.

Old Authentication Peering

The captive Portal software connects to different services for authentication of different realms. For ISS computing accounts (user@soton.ac.uk) SOWN authenticates against ISS LDAP servers. For ECS wireless accounts and eduroam accounts authentication occurs against the ECS Radius servers, and for SOWN community accounts authentication occurs locally on SOWN's Radius server.

802.1x Peering

As SOWN wishes to authenticate Community accounts as well as ECS and ISS accounts, it is nescessary to directly peer SOWN radius with a Radius server which can handle both requests. ECS Radius servers are directly peered with ISS and they in turn are peered with JRS servers. Subsequently it is nescessary to directly peer with ECS Radius servers- radius1 and radius2. They can handle/forward EAP requests for anything identified as non-sown accounts.

EAP Concerns

Currently there are several different types of EAP:

EAP-MD5

EAP-TLS

EAP-TTLS

EAP-PEAP

They each support varying different inner protocols for handling password handshakes. EAP-MD5 is considered insecure as it is vulnerable to various attacks, and hence should not be used by SOWN. EAP-TLS is intended mostly for Certificate login, which is more secure, but is beyond the scope of a user-authentication system such as a SOWN implementation.
This leaves two main implementations which are viable for SOWN use: EAP-TTLS and EAP-PEAP.

Current handshake permutations:

EAP-PEAPv0 supports MSCHAPv2

EAP-PEAPv1 supports Gtc

EAP-ttls can support PAP,chap,mschap,mschapv2,and md5 crypts.

For security reasons, SOWN stores community accounts using a secure one-way hash. This is not compatible with any of the CHAP or md5 protocols. Gtc has apparent inconsistent behaviour (although this could be due to client faults - further testing underway). Subsequently, due to the limitations imposed by our preexisting implementation, the only mechanism viable for authentication of SOWN community users using EAP sessions is EAP-ttls+PAP. This is less ideal than a challenge-handshake authentication method, however it should be secure enough for the level of access granted to SOWN community users.

ISS/ECS Radius both support EAP-ttls + PAP,MSCHAP,CHAP,MSCHAPv2, PEAPv0 and PEAPv1.

As for eduroam users, this is dependant on the Home server which is beyond our control. Due to the limitations of Windows XP it should normally be expected that PEAPv0 would be implemented.

SOWN Meraki Management Instructions

To roll this out under the central management system, goto the node management page, add a new interface, with athN name. Add details for ipv4/24 ipv6/64 and select "offer dhcp", add an SSID, and select "hostap", select the encryption type from the drop down box, and finally click submit. (preferably WPA+WPA2)

Under the "SetupNode" page, select configure_ipv6, configure_network, configure_dnsmasq, configure_firewall, configure_wireless, install_hostapd, configure_hostapd. click submit. The page will go through its process of updating the node. When it is done, it will say "Job Complete". Check for any weird error messages. Assuming there are none, the node is now set up. To initiate it, simply power-cycle the node.

Complience

Eduroam and and JRS have specific requirements which are laid out in their Technical Specification. Although SOWN does not directly peer with the JANET NRPS, SOWN adhears to all of the current requirements

A full listing of our compliance to the JRS TOS and what measures we undertake to ensure the integrity of our servers are available on the Eduroam Compliance Page.

Configuration

Specific configuration regarding logging and time can be found in the FreeRadius documentation.