I'd like to upgrade my WiFi from "WPA2 Personal" to "WPA2 Enterprise" mode because I know that in principle, on a WiFi secured with "WPA2 Personal", devices who know the PSK can sniff on each other's traffic once they captured the association between the station and the AP. In order to reduce the effect that a single compromised device on the WiFi would have (in "WPA2 Personal" mode, it would be able to decrypt other, uncompromised WiFi client's traffic, if it had before captured the "associated requests" from the other clients in promiscuous/monitor mode) I'd like to upgrade my WiFi to "WPA2 Enterprise" security, where, according to my understanding, this is no longer possible.

Now, unfortunately, for "WPA2 Enterprise", you need a RADIUS server.

Now, as far as I understand, the RADIUS server only performs authentication, but does not perform encryption or exchange of key material. So basically, an AP gets an association request from an STA, the client provides credentials, then the AP passes them to the RADIUS server, the RADIUS server says "credentials are OK", then the AP lets the STA associate, otherwise not.

Is this the right model? If so, then the RADIUS server is basically nothing but a database full of user credentials (username and password pairs). If this is so, then I'm curious why they require a full-blown server machine for this, since, even for thousands of users, usernames and passwords are not a lot of data to store and verifying credentials is a fairly basic task, so it seems that this is a thing that could also be easily done by the AP itself. So why require a dedicated server for this?

So perhaps I got this wrong and the RADIUS server is not only used for authentication, but for the actual encryption? If an STA sends data to a network using "WPA2 Enterprise", it encrypts it with some session key, then the AP receives the encrypted data, but, contrary to "WPA2 Personal", it cannot decrypt it, so it passes the data on to the RADIUS server, which has the key material (and computational power) to decrypt it. After the RADIUS has obtained the clear text, it then passes the unencrypted material back onto the wired network. Is this how it is done?

The reason I want to know this is the following. I have a rather old device here, which has a RADIUS server running on it. But, like I said, the device is pretty old and thus implements an old version of RADIUS with known security weaknesses. Now I'd like to know whether this would compromise my WiFi security if used for "WPA2 Enterprise" mode encryption. If an attacker can talk to the RADIUS server when not authenticated, this might compromise my network's security, so I should not do this. On the other hand, if the attacker can only talk to the AP, which in turn talks to the RADIUS server for checking the credentials, then a "vulnerable RADIUS server" might not be much of a problem, since the attacker wouldn't get into the WiFi network, and thus wouldn't be able to talk to the RADIUS server, in the first place. The only device talking to the RADIUS server would be the AP itself, for checking the credentials, with all the key material generated and cryptography performed on the (uncompromised) AP itself. The attacker would get revoked and thus not be able to join the network and exploit weaknesses on the potentially vulnerable RADIUS server.

So how exactly is the RADIUS server involved with "WPA2 Enterprise" security?


WPA2 Enterprise is based on parts of 802.11i that are based on 802.1X. 802.1X does NOT require a RADIUS server, but that's how it's commonly done for legacy reasons.

The RADIUS server's role is only at the beginning of the connection, but it does do one little thing more than you mentioned. As part of the authentication mechanism, keying material is securely generated on the RADIUS server (and the same keying material is also generated on the WPA2 client). After the RADIUS server tells the AP to accept that connection request, the RADIUS server sends that keying material in a RADIUS "key" message (they reused a RADIUS MPPE-KEY message/attribute that Microsoft had pioneered) to the AP, so the AP knows what per-user-per-session keys (including the Pairwise Temporal Key or PTK) to use for that session. That ends the RADIUS server's involvement.

You're absolutely right that it really doesn't take much server horsepower to run a RADIUS server. Just like a DHCP server or a DNS server for a small network or domain, you really don't need "server class" hardware to run it on. Probably any little low-power embedded network box will do. There are a lot of protocols in modern networking where the "server" end doesn't require much horsepower by todays standards. Just because you hear the term "server", don't assume it requires heavy-duty server hardware.


You see, RADIUS was originally a way to move authentication out of your dial-up modem PPP servers, and into a centralized server. That's why it stands for "Remote Authentication Dial-In User Service" (it should be "Dial-In User Remote Authentication Service", but DIURAS doesn't sound as good as RADIUS). When PPP started being used for DSL authentication (PPPoE, PPPoA) and VPN authentication (PPTP and L2TP-over-IPSec are both "PPP inside an encrypted tunnel"), it was natural to continue to use the same RADIUS servers for centralized authentication for all your enterprise's "Remote Access Servers".

PPP's original authentication mechanisms were lacking, and took a lot of standards-body involvement to create new ones, so eventually, the Extensible Authentication Protocol (EAP) was created to be a auth-type plug-in system for PPP-like authentication. Naturally, RADIUS servers and PPP clients were the first places that needed to support EAP. You could, of course, have your dial-in modem/PPP server, or your VPN server, or your PPPoE/PPPoA (really, L2TP PPP) server, or whatever, implement EAP locally, but by now, RADIUS was so widely deployed that it was mostly RADIUS servers that implemented it.

Eventually someone wanted a way to require authentication whenever someone plugs into an unguarded Ethernet port in the lobby or a conference room, so "EAP over LANs" was created for this. "EAPoL" as it was known, was standardized as 802.1X. 802.1X was later applied to 802.11 networks in IEEE 802.11i. And the Wi-Fi Alliance created an interoperability certification /branding/marketing program around 802.11i, and called it Wi-Fi Protected Access 2 (WPA2).

So, while your 802.11 AP itself could fulfill the entire 802.1X (WPA2-Enterprise) "Authenticator" role all by itself (without the help of a RADIUS server), it's just not commonly done. In fact, in some APs that are able to do 802.1X standalone, they actually built and open source RADIUS server into their firmware, and do 802.1X authentication via RADIUS via loopback, because it's easier to hook it up that way rather than trying to implement your own EAP authenticator code, or copy of the code out of some open source RADIUS server software and try to directly integrate it into your AP firmware's 802.11-related daemons.

Given that backstory, and depending on how old your proposed RADIUS server is, the important question is whether it implements the EAP type(s) you want to use for authentication on your network. PEAP? TTLS?

Also, note that RADIUS traditionally uses a "Shared Secret" known to the RADIUS client (the RADIUS client is the "Network Access Server": the AP in this case, or a VPN or PPP server or other "Remote Access Server" in other cases) and the RADIUS server, to both authenticate the RADIUS client and server to each other, and to encrypt their communication. Most RADIUS servers let you specify different Shared Secrets for each AP, based on the IP address of the AP. So an attacker on your network would have to be able to take over that IP address, and guess that shared secret, in order to have the RADIUS server talk to it. If the attacker wasn't on the network yet, the attacker would only be able to try to send specially-crafted/corrupted EAP messages that the AP would relay via RADIUS to the RADIUS server. If the security issue you're concerned about could be exploited via malformed EAP messages, then you could still have a problem.

| improve this answer | |
  • I'd probably use EAP-EKE or alternatively EAP-PWD if I can. All I want to do is basically protect users, which are able to connect to the network, from being able to intercept other's traffic. If WPA2-PSK would establish "session keys" via DH, that would be perfect for me but unfortunately (for whatever reason) it does not. I don't need any sophisticated authentication methods. All I want is to prevent stations from intercepting each other's traffic. For everything else, I'm fine with the security of WPA2-PSK. – no.human.being Mar 12 '14 at 19:22
  • @no.human.being Beware that not all EAP methods support creating the keying material necessary for 802.11i/WPA2-Enterprise. I'm not familiar with the two types you mentioned, so you might want to check elsewhere to make sure they'll be suitable for this purpose. – Spiff Mar 12 '14 at 23:16
  • 1
    Nice write up. You did not mention one important reason there is a separate server. This does not apply to home deployments, but it is a big part of "why this exists." In any enterprise deployment, the access points are actually untrusted, since they are located in public areas and therefore should not contain any user information. Additionally, with any EAP type that provides a secure tunnel to the client (PEAP, TTLS, TLS), the AP doesn't even participate in the authentication at all, so it cannot intercept user credentials even if it gets compromised by someone with a ladder :) – Ammo Goettsch Oct 16 '17 at 18:56

WPA Enterprise (WPA with EAP) allows you to have many other authentication methods, like digital certificates, RSA tokens, etc. It should be implemented with a radius server, because all those methods are beyond simple usernames+passwords and the radius protocol is the de facto standard for most systems which need AAA (authentication, authorization, accounting).

This being said,

1) the radius server can be easily protected by firewall rules, accepting packets only from APs (the wifi client will never speak directly to the radius server)

2) using an old radius might not work, i recommend one of the latest freeradius servers

More details about how this works and what you need to do: http://wiki.freeradius.org/guide/WPA-HOWTO#Why-Would-I-Want-WPA?

| improve this answer | |
  • Yeah. I just thought I could save power (and noise) by not putting up an actual server for RADIUS because I don't need "sophisticated authentication methods", I'd just like to prevent wireless clients from "sniffing on each other" (they probably won't, it's just some extra paranoia ;-) ). So basically I want the privacy of a "switched network" on wireless (which is an inherently broadcast medium) so I need actual "per link" or "per client" keys. "WPA2 Enterprise" would probably suit my needs. I might try setting up RADIUS on an embedded board running Linux. – no.human.being Mar 8 '14 at 22:27

FreeRadius will happly run on a Raspberry PI. The usual OS is Raspbian which is a flavour of Debian -so it will do all the things you might want a server to do eg DHCP / DNS. It is cheap - 40 dollars for a bare board- but budget 80 or 90 dollars to have "option" extras - such as a case, and power supply... I have been running radius on a Pi for a couple of years -24/7. It also has zenmap and Wireshark. It is a create platform for trying things out as it runs off an SD card and you can copy the SD card to your PC. Try something, and restore the SD from you PC if you mucked it up.

| improve this answer | |
  • 2
    This answer does not explain the role of a RADIUS server – janv8000 Jan 13 '17 at 7:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.