The RADIUS (Remote Authentication Dial-In User Service) protocol has long been a standard authentication, authorization and accounting protocol for Internet service providers and businesses. It determines who you are, what you’re allowed to do, and records how long you did it for. It works for more than just dialup users- it also works for DSL, cable, and wireless users.
Anytime you study RADIUS, you read about “AAA”, the authentication/authorization/accounting functions. Sometimes it is even called RADIUS-AAA. (And now you know it’s not about a twelve-step program or automobile club.) The accounting part can be used for billing or statistical analysis. RADIUS can use text files of users for authentication, or hook into Linux/Unix password files, NIS (Network Information Service), LDAP (Lightweight Directory Access Protocol) directories, MySQL and other databases.
RADIUS works in a rather interesting fashion. It uses a distributed architecture – it sits separately from the NAS (Network Access Server). You store user access data on a central RADIUS server that is available to many NAS. The NAS provide the physical access to the network, such as a dialup server, managed Ethernet switch, or wireless access point. This scheme adds security and flexibility, and is a lot easier to manage than having to individually configure every entry point to your network to perform user authentication.
Note that we’re not talking about your cheapie five-port switches from joeskewlnetworkcrap.com for twenty clams; you need the higher-end managed switches that support 802.11i, such as the Netgear ProSafe GSM7212, or the Cisco Catalyst switches, or some such. These are smart switches that support all sorts of security protocols.
There are a number of RADIUS servers; the Free/Open Source edition is called FreeRADIUS. Its maintainers claim it’s not ready for public use, but we are going to forge boldly and publicly ahead and use it anyway.
So what is the attraction in using RADIUS for wireless authentication? To answer that we must take a quick look at how wireless authentication works. It ain’t pretty.
Wireless Authentication Protocols
You know already that WEP (Wired Equivalent Privacy) is poo, and easily cracked. WepLab, aircrack, AirSnort, Kismet, John the Ripper, and other easily obtainable tools make WEP cracking a yawn rather than a challenge.
WPA (Wi-Fi Protected Access) is the next evolution of wireless security. It’s an intermediate step until the 802.11i protocol is finalized. The bit we are interested in is its implementation of the 802.1x authentication protocol and the TKIP protocol.
The 802.1x protocol uses port-based access control. This sets up a gateway on the NAS to prevent traffic from entering the network until it has been identified and authenticated. Of course you see the flaw in this at once – wireless packets fly heedlessly through the air, and care not a fig for silly ports, whether physical or logical. So this does not prevent an attacker from capturing wireless packets. However, it does prevent an attacker from doing things like getting a DHCP lease, or trying for a static IP, or forging a MAC address, because she can’t send data through the port.
The steps of the authentication process go like this:
- The wireless client (also known as the supplicant, with all of its overtones of forelock-tugging and kowtowing) requests network access from the NAS.
- The NAS, or authenticator, passes any credentials presented by the supplicant to the RADIUS server.
- The RADIUS server, or authentication server, gives the thumbs-up or thumbs-down to the authenticator. If it’s thumbs-down, the supplicant is out of luck. It can beat at the door of the NAS, but that’s as far as it will get. It can even beat at the doors of other NAS on the same network, but since they all query the same mean old authentication server, too bad so sad.
The type of authentication is important. We don’t want some dumb ole login/password deal, that’s just too lame. The Extensible Authentication Protocol (EAP), which is part of 802.1x, can be thought of as a container that holds whatever authentication credentials required of the supplicant. WPA is designed to be extensible, which is the usual good news/bads news scenario found so often in the Linux world: as old authentication protocols are deprecated or become unfashionable, and new ones introduced, WPA can be modified to keep pace. Which means that it’s a moving target, and us hardworking admins cannot rest on our shiny new knowledge, but must continually keep up with new developments.
Here is a sampling of some WPA authentication protocols:
- EAP-Transport Layer Protocol (EAP-TLS). TLS is a descendant of SSL. It relies on certificates, and it is a nice strong method of authentication, but it is a bit cumbersome. You have to manage public and private key pairs, and creating/revoking them as users come and go can get old.
- EAP-MD5 does a simple comparison of hashed usernames and passwords against a database on the server. There are a couple of problems with this: the hash can be captured and broken, and the server is not authenticated to the supplicant. (See Bruce Schneier’s take on breaking MD5, and Val Henson’s. Val was one of the first to recognize its weaknesses, and the flaws of compare-by-hash in general.)
- PEAP (Protected EAP). PEAP sets up an encrypted tunnel, sort of like TLS, to protect feebler encryption protocols like MS-CHAP and MD5. The full name is Protected EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2), and since it is a Microsoft protocol some folks consider it to be too icky to use, and choose TLS instead. It works fine, but I won’t force anyone to like it.
- EAPOL, or EAP Over LANs. You don’t need to do anything to make this work, it’s the transport used over wired connections.
- EAPOW is the transport for wireless connections.
Which brings us to …
Key Exchanges
When a supplicant is authenticated by one of the EAP protocols, the next thing that happens is a secure encryption key exchange. The Temporal Key Integrity Protocol (TKIP) is the mechanism for transmitting the keys. This is an important step, as it adds a layer of real security, because both the authenticator and the supplicant must authenticate to each other. Another option is to use pre-shared keys. We’ll look at both of these next week, when we pull it all together and make it go.
Resources
