USENIX Association Proceedings of the FREENIX Track: 2002 USENIX Annual Technical Conference Monterey, California, USA June 10-15, 2002 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2002 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Authorization and charging in public WLANs using FreeBSD and 802.1x Pekka Nikander Ericsson Research NomadicLab [email protected] Abstract The IEEE 802.1x standard defines a link-layer level authentication protocol for local area networks. While originally designed to authenticate users in a switched Ethernet environment, it looks like the most important need for 802.1x lies in wireless networks, especially IEEE 802.11b based Wireless LANs. Furthermore, due to the flexibility of the Extensible Authentication Protocol (EAP), the heart of 802.1x, it looks like 802.1x could be used for many purposes its original designers have not foreseen. In this paper, we describe an FreeBSD-based open source 802.1x implementation, and show how it can be used to implement different authorization and charging systems for public WLANs, including a pre-paid, pay-per-use charg- ing system and another one based on community membership. The implementation is based on the netgraph facility, resulting in a surprisingly flexible and simple implementation. 1 Introduction Protocol (PPP). Now 802.1x is extending the same architecture to LANs, both wireline and wireless. With the advent of 802.11 based Wireless Local Area At the basic level, the 802.1x architecture, properly Networks (WLANs) and the proliferation of laptops and augmented with the RADIUS [3], allows the existing PDAs, the usage of Ethernet networks is changing. What PPP based authentication, authorization and accounting once was meant to statically connect computers belong- infrastructure to be used to control LAN access in addi- ing to a single organization, is now increasingly being tion to PPP access. The solution works well in current used to provide Internet connectivity for mobile profes- environments, where the network providers and network sionals. This change is very visible at certain high pro- users have an existing, pre-established relationship. file telecommunication and computer science confer- However, if we consider public WLAN offerings at air- ences, including IETF meetings, where an increasing ports, hotels, cafes, and even offices and homes, it number of people are utilizing the wireless networks becomes more common than before that the prospective provided by the organizers. network user has no relationship with the provider. The changing usage patterns brings forth new security Thus, something new must be introduced, something problems. From the network point of view, the most that allows such a relationship to be build on the fly. prominent problem is that of access control. The net- In this paper, we show how it is possible to set up a work must somehow decide if and how to allow a net- public WLAN environment that supports various kinds work node to utilize the resources provided by the of authorization and charging schemes, including com- network. The IEEE 802.1x standard [1] is designed to munity membership based and pre-paid, pay-per-use provide a solution framework for this problem. accounts. The new schemes allow more flexible user– The 802.1x standard defines a method to run the provider relationship management than the existing Extensible Authentication Protocol (EAP) [2] in raw ones. The implementation is based on IEEE 802.1x, and (non-IP) Ethernet frames. The resulting protocol is the prototype runs under FreeBSD. The architecture is called EAP over LAN (EAPOL). The EAP protocol was geared to small service providers, eventually scaling originally designed as a flexible authentication solution down to the level of individuals offering WLAN based for modem connections using the Point-to-Point Internet access through their xDSL or cable modem. The rest of this paper is organized as follows. In Section 2, we briefly describe the IEEE 802.1x standard Authentication Corporate and the FreeBSD netgraph facility. After that, in Server Intranet Section 3, we describe our 802.1x implementation in broad terms, and in Section 4 we cover the implementa- tion details. In Section 5 we describe how the imple- RADIUS mentation can be configured to support different usage Access point or Ethernet switch scenarios, including pre-paid pay-per-usage accounts and community membership based accounts, and EAPOL Section 6 includes our initial performance measure- authenticator ments. In Section 7, we discuss a number of open issues and future possibilities related to this ongoing work. type = EAPOL any other type Finally, Section 8 includes our conclusions that we have Ethernet frames been able to achieve so far. Client 2 Background EAPOL Other supplicant applications Our work is mostly based on existing technologies, inte- grating them in a novel way. The only significant piece Figure 1: Basic IEEE 802.1x architecture of new software that we have written is the base 802.1x EAPOL protocol [1], which is implemented as a pair of server, the protocol is mediated by an EAPOL authenti- FreeBSD netgraph [4] nodes. Since we cannot assume cator function located at the access point. The EAPOL that all readers are familiar with the IEEE 802.1x stan- authenticator takes care of two functions. First, it medi- dard and the netgraph facility, we introduce them briefly ates the EAP packets between RADIUS, used towards in this section. Additionally, we discuss related work. the authentication server, and EAPOL, used towards the client. Second, it contains a state machine that “snoops” 2.1 IEEE 802.1x the EAP protocol, learning whether the authentication server was able to authenticate the user identity or not. If the user was authenticated, it permits the client to freely IEEE 802.1x [1] is a forthcoming standard for authenti- communicate; otherwise the client is denied access from cating and authorizing users in Ethernet like local area the network. In the figure, this latter function is depicted network (LAN) environments. It is primarily meant to with the on/off switch within the access point. secure switched Ethernet wireline networks and IEEE 802.11 based WLANs. In the typical usage scenarios, It is important to note that 802.1x implements only the network requires user authentication before any authentication and MAC address based access control. other traffic is allowed, i.e., even before the client com- Since MAC spoofing is fairly easy, the resulting system, puter is assigned an IP address. This allows corporations as such, might not be secure enough. The need for addi- to strictly control access to their networks. tional security measures depends on the usage scenario; see Section 7.1 for the details. The 802.1x overall architecture is depicted in Figure 1. The central point of the architecture is an Ethernet switch or WLAN access point. Now, instead of 2.2 EAPOL directly connecting clients to the network, the access points contains additional controls, basically preventing The EAPOL protocol is run between the EAPOL suppli- the clients from communicating before they have posi- cant, running on the client, and the EAPOL authentica- tively authenticated themselves. The authentication tor, running on the access point. It is a fairly simple pro- takes place between an EAPOL supplicant, running on tocol, consisting of a packet structure and state the client, and a background authenticator server. This is machines running on both the supplicant and the authen- denoted with the thick, dashed arrow line. The authenti- ticator. The packets are based on raw Ethernet frames cation protocol can be any supported by the Extensible with little additional structure, as depicted in Figure 2, Authentication Protocol (EAP) standard [2]. on the next page. Even though the actual authentication protocol is run The protocol is typically initiated by the authenticator between the supplicant client and the authentication as soon as it detects that a new client has been connected Src Ethernet Addr mpd Dst Ethernet Addr Ether type = 888E socket node TCP/IP Vers Type Body length Body (e.g. EAP frame) iface node inet Figure 2: EAPOL packet structure inet PPP node to an switched Ethernet port or that a new client has link0 joined to a WLAN access point. However, the protocol session can also be triggered by the client by sending an PPPoE node EAPOL start packet. ethernet A typical protocol run is depicted in Figure 3, below. orphan The first message is an EAP identity request, sent by the Ethernet device driver node EAPOL authenticator. The supplicant replies with an Figure 4: A netgraph stack implementing PPPoE EAP identity response, which is passed to the authenti- cator server. The authenticator server replies by running such as HDLC, Frame Relay, and PPP, in different ways. one of the possible EAP subprotocols within EAP Furthermore, it allows intelligent filtering and pseudo- request and response frames. Once the authentication interfaces, thereby making it possible to make a differ- phase has been completed, the authentication server ence between LAN clients based on their MAC ad- sends an EAP success (or failure), indicating that the dresses. user identity was verified (or could not be verified). The From the implementor’s and administrator’s point of EAPOL authenticator notices this message, and allows view, netgraph is extremely flexible. Firstly, new proto- (or disallows) the client to communicate. col nodes are implemented as loadable kernel modules, In addition to the base authentication, EAPOL also making development and testing fairly easy.