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).
The 802.1x group is currently researching different 802.1x (aka 1x ) clients see project brief: 802.1x Wireless Client Status Report Brief
- 1 Introduction
- 2 Implementation
- 3 Eduroam
- 4 And Finally
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.
There are a multitude of clients which claim to support 802.1x on various platforms. These include:
|MacOS 802.1x agent|
|Windows XP 802.1x agent|
These clients have all been looked into, with special regard for Xsuplicant.
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
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
Additional chains to the firewall (example interface ath1 as 802.1x compliant):
iptables -F X8021 iptables -N X8021 iptables -I X8021 -j NET iptables -I X8021 -j SOWN
ip6tables -F X8021 ip6tables -N X8021 ip6tables -I X8021 -j NET ip6tables -I X8021 -j SOWN
iptables -I FORWARD 2 -o ath1 -j ACCEPT iptables -I FORWARD 5 -i ath1 -j X8021
ip6tables -I FORWARD 2 -o ath1 -j ACCEPT ip6tables -I FORWARD 3 -i ath1 -j X8021
iptables -t nat -A PREROUTING -i ath1 -j ACCEPT
This is ok if and when traffic on ath1 is authenticated. In its current form, it will allow anyone full access.
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.
Hostapd requires an accessible radius server. SOWN runs a FreeRadius server installed on sown-auth for authenticating SOWN community accounts. FreeRadius can peer with ECS radius servers for authentication of Academic accounts.
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 (email@example.com) 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.
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.
Currently there are several different types of EAP:
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.
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.
Specific configuration regarding logging and time can be found in the FreeRadius documentation.
802.1x What it is, How it’s broken, and How to fix it.
IEEE 802.1X Pre-Authentication