WiFi networks are affected by unauthorized access problems much more than cable networks. This is obvious if you think about that fact that to access the latter a physical access point is required (RJ45 socket), in wireless networks you just have to be within the coverage range to access it. An initial solution to the problem was WEP (Wired Equivalent Privacy). However, this method, associated with the presence of symmetrical encrypted keys on both the Access Points and all the clients authorized for access, gave network administrators the job of periodically changing these keys and communicating the change to all users. The result was that the WEP keys remained unchanged for long periods of time, making the network insecure.
The 802.1x protocol introduced authentication and support for dynamic management of the WEP keys. This way, once the client is authenticated the keys that the wireless traffic is encrypted with are automatically supplied and changed even more than once during a work session. The validity period of the keys is short enough to make them difficult to determine by an intruder attempting an attack.
From a practical point of view, the 802.1x protocol is none other than the EAP (Extensible Authentication Protocol) authentication frame used to authenticate point to point connections, adapted to run on Ethernet frames instead of PPP packets. For this reason the 802.1x protocol is also known as EAPoL (EAP over LAN).
In EAP terminology the entities that play a role during the authentication process include: the supplicant, i.e. the client asking to access the network; the authenticator which in wireless networks coincides with the Access Point; the authentication server which checks whether the users are really who they say they are. The authentication server is often one and the same as the RADIUS server, while the authenticator is what is defined as NAS (Network Access Server) in the RADIUS protocol.
As mentioned above EAP is only an authentication frame which gives the supplicant and authentication server the task of establishing the actual authentication method to use. It may be seen that the Access Point is transparent from this standpoint, since its only job is to forward the packets from the supplicant via EAPoL to the RADIUS server and encapsulate them in IP (the RADIUS server can be reached by the wired part of the AP) and vice versa.
The Zeroshell RADIUS server supports the authentication methods described below because they include those which provide a greater guarantee of security and are supported by most supplicants.
- EAP-TLS which use TLS for mutual authentication between supplicant and Access Point. Both the RADIUS server and supplicant must have a private key and relevant X509 certificate. Aside from the task of having to equip each user with a certificate, this is certainly the most secure and convenient authentication method, since no user password needs to be entered.
- PEAP (Protected EAP) which instead uses TLS to authenticate the Access Point and establish an encrypted tunnel where MS-CHAPv2 is used to authenticate the supplicant with a username and password. The advantage of this method is that only the RADIUS server needs to have the server certificate and private key, while the user uses the same password used to authenticate with Kerberos 5 on the other network services.
Apparently, with EAP-TLS just as with PEAP, the Access Points do not prove their identities to supplicants since they are not supplied with a certificate and private key. Actually this is not the case since the Access Points share a secret with the RADIUS which makes them trusted for it. This trust makes it possible for a supplicant which trusts a RADIUS (thanks to TLS) to also trust Access Points.
In addition to the 802.1x protocol, in Access Points which manage multi SSID mapped on tagged 802.1Q VLAN, Zeroshell supports the association on a particular VLAN based on the username supplied in the certificate CN if the authentication is EAP-TLS, on the username supplied by the supplicant in the case of PEAP, on the user belonging to a group for which a VLAN has been assigned and on the client MAC Address if the previous methods do not define a VLAN.