Traditionally, wired Ethernet networks have been open to everyone that had a cable attached to the segment. Once the cable is plugged in and the correct IP information is configured, either statically or dynamically via DHCP, the device is granted access to the network. Back when Ethernet was originally created, nobody gave it much thought as to how to ensure that the connected device or user was actually authorized to access the network. With the advent of wireless networks, it quickly became obvious that some sort of mechanism that provided access control to a network was needed. With wireless, this is even more important, as radio waves are not easily confined to a specific area or location; they leak out windows, doors, and walls. This means that a person passing by outside can listen in on the transmission and gain access to the network, so in order to prevent that, some sort of network control system is needed.
The 802.1x framework defines three different roles for the various devices involved:
- Supplicant: This is the device providing the crendentials in order for it to be granted access to the network. For instance, this can be a wireless client associating to an SSID.
- Authenticator: This is the device the supplicant is attached to. For instance, this can be a user access switch or a wireless controller. The authenticator can also impose restrictions on what the supplicant has access to.
- Authentication server: This is the device responsible for verifying the credentials provided by the supplicant.
In an effort to avoid that everyone can simply get access, and also to ensure that traffic cannot be easily eavesdropped on, the WPA2 suite allows the use of a pre-shared key on a given wireless network. Not only does this require the device to be configured with the correct pre-shared key in order to get access to the network, it is also used to derive the encryption keys used when traffic is transmitted over the air. The drawback of this method is that if the pre-shared key is leaked or otherwise compromised, it has to be changed. This includes changing it on the wireless network itself, and also that every single device accessing the network is reconfigured to use the updated pre-shared key. In larger organizations, this could put a significant burden on the IT department, as it, in some cases, is required to manually perform the change on the devices, as not all operating systems allow for a centralized change of the pre-shared key for a WLAN.
At this point, neither of the scenarios described above really restricts who can get on the network, only what can get access. As long as the pre-shared key (PSK) is known, every user, friendly or malicious, can get access. The PSK method doesn't provide information about who is using the device, and whether the device itself is authorized to access the network. Considering the security concerns of today, this might no longer acceptable or sufficient. On a corporate wireless network, the security policies often mandate that the identity of the user accessing the network is known, and/or in many cases also that only authorized devices can get access. The PSK method does not supply this, so another method need to be used.
To obtain user and/or device credentials, we can turn to WPA2 with 802.1x (also known as WPA2 Enterprise). This leverages the 802.1x framework with various EAP types to challenge the connecting device to provide some sort of credentials, most often as a username/password combination or a certificate. If no credentials are provided, or the provided ones fail validation, the device is either flat out not granted access to the network, or it can be classified as a guest device and put on a guest network. If the credentials are successfully validated, based on the received credentials, we now know which device, user, or even both, that is trying to gain access to the network.
...and for wired
As the original Ethernet specificiations did not have provisions for authenticating connecting devices, a method had to be developed. This lead to the development of EAPoL (EAP over LAN), which allows the 802.1x framework to operate over LANs. In the most restrictive configuration, a switchport configured for 802.1x will only allow EAPoL frames to be sent and received, effectively meaning that no user traffic is allowed until the EAP process has been completed. Again, the connecting device will provide some sort of credentials to identify itself and/or the user. Like the case with wireless, both username/password based authentications and certificate based authentications can be used. If the authentication is successful, the user is granted access to the network. In case of an unsuccessful authentication, the device or user can either be flat out denied access to the network, or can be placed in a restricted VLAN, for instance one that only provides internet access. This is in 802.1x terms referred to as closed mode.
If a more lenient approach to controlling access to a wired network is acceptable, it is possible to allow a subset of traffic by using an ACL, or simply allow all traffic on a port prior to the completion of the EAPoL process. For instance, this can be used in scenarios where diskless systems are involved. Often these utilize the PXE protocol to load their base operating system from a network location. More often than not, 802.1x is not available in this early stage of the boot process, so an implementation where no traffic is allowed prior to authentication would cause problems for such devices, and will most likely cause them to fail to boot. By loosening up the restrictions a bit, devices depending on PXE can be allowed to operate in such an environment.
No 802.1x? Then what?
Another way to allow PXE machines or any non-802.1x capable machines to gain access to the network is use their MAC address as the credentials. This is technically not 802.1x, as the switch simply grabs the MAC address from the first packet received on the port after it transitioned to an up state, and then attempts to validate it. The is known as MAC Authentication Bypass, or simply MAB. It is possible to combine both 802.1x and MAB on the same physical port, making it possible for a device to start off by being validated using its MAC address, and then, once the operating syatem has booted up, switch to 802.1x. This will also allow the use of a PXE scenario.
However, as MAB simply takes the source MAC address of the first packet received, MAB is open to spoofed MAC addresses. As long as the connected device uses a MAC address, that can be successfully validated, it will gain access. As such, use of MAB should be limited to cases, where it is not possible to engage 802.1x.
On the backend
On the switch side, 802.1x authentication requests and MAB requests will be forwarded to an external entity for validation. While it is techically possible to validate the credentials locally, it is most often not a feasible way since it would require maintaining a decentralized database of users, MAC addresses and so on. Having a centralized repository of users and MAC addresses helps create a scalable solution that can be accessed from numerous devices. The de facto standard for doing this is by using RADIUS as the protocol between the switch (or other network device, where users and devices attach). Once received from the connecting device, the credentials are forwarded to the RADIUS server for validation, and based on the configured policies on the RADIUS server, the request is either denied or accepted. If the result is an accept, the RADIUS server can also include attributes in its response, such as on which VLAN to put the user or device, which QoS profile that should be applied, and so on. The options can either be standards based, or based on a vendor specific dictionary. Each platform supports different attributes and options, so to get an idea of what is possible, refer to the documentation for that platform.
Previously, the concepts of username/password and certificate based authentications were introduced. The EAP framework allows use of several type of authentication schemes. Some EAP types are not authentication methods by themselves - they instead establish an encrypted tunnel, known as the outer method, to protect the credentials of the connected user/device. The credentials are then handled by an inner method, which most often is MS-CHAPv2 for username/password based authentications. It is also possible to use TLS as an inner method for certificate based authentications, but it seems most implementations use EAP-TLS as the EAP type for that.
Some of the EAP types require the use of a server-side certificate, even if the actual authentication method used is username/password based. This includes EAP-FAST and EAP-PEAP, both of which uses the server-side certificate to establish a secure tunnel between the supplcant and the authentication server. As the server-side certificate is presented to the connecting device, the certificate should be issued by a trusted CA. Otherwise, depending on the configuration on the device, the end user may be presented with a certificate warning. In most cases, it is possible to disable the validation of the certificate, but since validating the certificate adds to the security, this should be avoided when possible.
If using an EAP type that allows for certificate-based authentications, such as EAP-TLS, the supplicant still has the option to validate the server-side certificate (again, it should do so for security reasons). In addition to this, the authentication server will always validate the supplicant's certificate against its configured trusted CA servers. If the certificate is not issued by one of the authentication server's trusted CAs or subCAs, the authentication will fail, and the client will not be granted access to the network. The use of certificates is seen as the most secure method of validating the device or user trying to connect to the network, being wired or wireless.
It should be noted that using a certificate based authentication scheme requires a fully operational Public Key Infrastructure (PKI). The client certificate needs to be issued and signed in order for the certificates to be usable for authentication. To avoid the administrative overhead of doing this manually, most implementations uses third-party certificate management systems for handling all aspects of issuing and maintaining certificates. The authentication server would simply tap into this infrastructure in order to validate the certificates it receives during authentication.
Even if the connecting device can provide credentials that checks out fine, that is not a guarantee that it will get on the network. Once the authentication has passed, the next step is evaluating which level of access the device should get. This step is called the authorization phase. For instance, the result of the evaluation of the authorization policies might specify that an access-list is going to be placed on the client session, effectively restricting access to only certain parts of the network, and it could also dynamically place the client in a different VLAN. The authorization phase is the final step before the actual response is sent back to the authenticator (the device to which the user is connecting). An interesting fact is that even at this point, the result of the authorization process can still be a rejection, despite the fact that the provided credentials were correct. This allows including and checking other attributes than just the credentials, before making a decision on whether to allow or deny the device access to the network.
Controlling access to the network using 802.1x or, to some extent, MAB, is a great way of ensuring that only authorized users or devices can access your network, and it makes it relatively easy to revoke access to the network when needed. From a security perspective, it also makes it possible to determine who was active on the network at a given time, which for instance can be useful in forensics analytics, or if unwanted activities has been conducted from the network.