With a number of different terms floating around it is easy to get confused by them all. This post will explore some of the differences, dig into some of the details and review how different components are combined to make a coherent solution. Hopefully by the end of this post you will understand 802.1x and MAB in a bit more detail.
This post follows on from one of my previous ones – The Importance of Network Access Control. If you haven’t already I’d recommend reviewing that first.
Is 802.1X the same as NAC?
No. You may hear the two terms used interchangeably but they are not the same. Let’s review what they are at a high-level.
- 802.1x – 802.1x is a standards-based framework that defines a model to provide network-based authentication. On its own it is nothing really more than a method of providing authentication (proof of identity)
- NAC – NAC tends to refer to an overall solution and encompasses more than just authentication alone. NAC solutions often (but not always) utilise 802.1x in order to authenticate users or devices, but typically provide a lot more services on top of this
What about MAB?
MAB stands for MAC Address Bypass and is another way a network device, such as a switch, can “authenticate” (though it’s not really authentication) a device to a NAC solution. Not all devices can support 802.1x and where this is the case, MAB is often used as a fallback method. Think of it as simply being a method of letting the NAC solution know about a connecting device without the use of 802.1x authentication.
So all NAC solutions use 802.1x and MAB?
Not quite! There are NAC solutions on the market that don’t utilise 802.1x or MAB and typically achieve similar results using a combination of endpoint agents, SNMP and NETCONF configuration. I have no experience of these products personally so will not be focussing on them in this article. If you have used, or currently use such a solution I’d be keen to hear more on how you find it so get in touch!
A closer look at 802.1x
As I touched on before, 802.1x isn’t really a protocol in its own right, but an authentication framework. As part of the 802.1x framework there are a number of different roles and protocols in use – the main ones you’ll come across are:
- Supplicant – The supplicant is the 802.1x software that runs on the endpoint. This software is responsible for handling communication with the authenticator and sending authentication credentials to the authentication server. Lots of devices support 802.1x nowadays including PCs, laptops, phones, printers and video conference units. Supplicant software more often than not comes built into the operating system, but additional third-party software is also available (and sometimes required for certain features)
- Authenticator – The authenticator is the network device that is acting as a “gatekeeper” to the network – typically a switch or Wireless LAN Controller (WLC). It prevents access to the network (if configured to do so) until the authentication server tells it otherwise. The authenticator is responsible for taking the messages from the supplicant, encapsulating them in RADIUS and sending them to the authentication server for processing
- Authentication Server – The brains of the operation! The authentication server is the component that ultimately decides if clients can access the network or not, as well as any restrictions that must be applied to the session
- EAP – Stands for Extensible Authentication Protocol and it provides a number of different “methods” for authentication. I review some of these a bit further on in this post. The actual EAP conversation ultimately takes place between the supplicant and the authentication server, with the authenticator just acting as a middle man and tunnelling the messages in RADIUS. This allows the two parties to communicate before the supplicant has an IP address
- EAPOL – Stands for EAP Over LAN. It is a network layer protocol that encapsulates EAP messages between the supplicant and the authenticator. Don’t get too hung up on the details of this – it is just how the messages are encapsulated between the supplicant and the authenticator
- RADIUS – Stands for Remote Authentication Dial-In User Service. It is a standards-based network protocol that can provide authentication, authorisation and accounting. RADIUS is used by the authenticator to tunnel EAP messages from the supplicant to the authentication server. When the authentication server has made an access decision it communicates this to the authenticator by way of RADIUS Access-Accept or Access-Reject messages. RADIUS also provides extensible Attribute Value Pairs (AVPs) which allows the authentication server to dictate certain dynamic actions such as “put the device in VLAN x” or “apply a downloadable access-control list to the port”
The authentication process
The diagram and points below give you a simplified overview of the 802.1x authentication process.
- This first message may or may not occur. If the switch sends the request/identity message first you won’t see it
- The switch sends a request message prompting the endpoint to send its identity
- The endpoint sends its identity. What this identity value is will vary based on a) the type of authentication in use and b) the configured security settings. The identity could be the hostname of the PC, a person’s username or could be a dummy/anonymous value if identity privacy is in use. Why might you want to use identity privacy? There is no TLS tunnel protecting data yet and vanilla RADIUS doesn’t encrypt the username field
- The authenticator relays the user identity as a RADIUS message to the authentication server. The EAP protocol is packaged up as RADIUS AVPs
- Based on its configuration, the authentication server will pick an EAP method and respond. Note, it is possible more than one method will be allowed and as such there may be some additional message exchanges as the client/authentication server negotiate what they are going to use
- The message is relayed to the supplicant and for most EAP methods this will also include the authentication server’s EAP certificate. This is used to setup a secure end-to-end TLS tunnel between the supplicant and authentication server. Which certificates are trusted will depend on the supplicant settings. As highlighted above, this is a simplified overview and there may be more back and forth between the supplicant and authentication server depending on configuration and EAP method used
- Once a secure tunnel is established (for most EAP methods anyway) the supplicant sends its authentication credentials. What the credentials are will depend on the EAP method in use but are typically MSCHAPv2 credentials or a signed certificate
- Credentials are relayed to the authentication server by the authenticator. It is worth noting that for most EAP methods these will be secured inside TLS and will not visible even if sniffing traffic
- Dependant on the authentication server’s policies it will decide to send an accept or reject message. As highlighted earlier NAC offers a lot of features, so the decision to allow or deny is likely not based solely on whether the authentication passed or failed
- The EAP success/failure message is sent to the supplicant and dependant on a number of factors, such as supplicant and authenticator configuration, a session will begin, or it won’t. Any restrictions being applied by the authentication server would be applied to the session by the authenticator
- Optionally, and dependant on device support, you may also see EAP logoff messages when devices are disconnecting from the network. You may also see a variant of this known as an EAP proxy logoff message – this is commonly seen when PCs or laptops connect behind an IP phone and disconnect. If the phone supports proxy logoff then it can notify the upstream switch that the device has disconnected and the session has been cleared. Without this notification the switch would have to rely on timers to clear the session as it would have no way of knowing the device had disconnected (as the link state remained up on the switchport due to the phone)
There are a number of EAP methods that can be used to authenticate supplicants. Most of the commonly used ones offer mutual authentication whereby the client also authenticates the server (i.e. by checking its certificate). The EAP method you choose will depend on the environment you are deploying NAC to and what you are looking to achieve. The most commonly used methods in real world deployments, along with some pros and cons are shown below.
Stands for Protected EAP and it requires a server-side certificate on the authentication server. Before any authentication credentials are passed from the supplicant a TLS tunnel is setup. This allows the client to first authenticate the server and then pass credentials in an encrypted tunnel. PEAP is known as a tunnel method, whereby the actual authentication is carried out using a separate inner method that could be a number of different things such as MSCHAPv2 or Generic Token Card. Most commonly PEAP is used with MSCHAPv2 to tunnel user or machine credentials.
- Pros – One of the simplest EAP methods to setup and manage. It does not require client-side certificates allowing easier deployment and management in the future
- Cons – PEAP with MSCHAPv2 is more susceptible to Man in The Middle attacks if the supplicant has not been configured correctly. It also requires server-side certificates (is that really a con nowadays though?!). For machine-based authentication this really only works in a scalable manner when using an Active Directory environment
Uses both server-side and client-side certificates to carry out strong mutual authentication. Again, this can be based on user or machine certificates.
- Pros – Probably the strongest EAP method available and resistant to Man in the Middle attacks by design. Allows support for multiple device types (phones, Windows AD devices, non-AD devices such as Macs etc.)
- Cons – Requires that every supplicant device has a valid certificate installed. This can be additional management overhead if you don’t already have this setup in your environment and often puts organisations off
Another tunnel method like PEAP that was originally developed by Cisco. Unlike PEAP this one has some more complexity and isn’t as widely used. EAP-FAST uses something known as Protected Access Credentials (PACs) that are a bit like TLS session tickets. I only tend to see this used for one of two reasons – 1) The need to authenticate Cisco wireless access points to the wired network and 2) To support EAP-Chaining where both the user and computer authentication is taken into account – EAP-FAST is the only method that can currently handle both and tie them together.
- Pros – Provides more features such as the ability to do EAP-Chaining. It doesn’t strictly require a server-side certificate, though this would still be recommended and preferred
- Cons – Not supported on a lot of operating systems and typically requires third party supplicant software (though I believe this is changing in Windows 10 – but not by default). Understanding the additional complexity can be a little challenging
I didn’t really want to mention this one as it is legacy and insecure, however there have been some older devices that only supported this and in many ways it is still better than MAB alone (though still requires restrictions – more on that in the next section).
- Pros – None really, other than some old devices support it and if it is all you can do it is still better than nothing – though it shouldn’t be relied on for strong security and its use should be minimal
- Cons – Everything! It is insecure, doesn’t perform server-side authentication, is easily subject to Man in The Middle attacks and is just basically a bit rubbish
The list above is by no means exhaustive – there are a lot more EAP methods than this, however these tend to be the ones you come across in most real-world deployments.
A quick note on EAP-Chaining
I’ve touched on EAP-Chaining a couple of times – what do I really mean by this? Most EAP methods were only designed to do a single authentication – either the machine or the user, but not both. You can configure both in your NAC policies, but by default one is just going to override the other – the status of both isn’t taken into consideration. I won’t get too much into the details now, but this usually ends up in the ability for a user to connect any device they like – as long as they enter their username and password into the supplicant. But what happens if you want to restrict the type of device (machine authentication) but then apply policies based on user groups?
Depending on the NAC solution there are a number of ways to achieve this, some good, some not so good. But one of the most secure ways is EAP-Chaining. Using the “EAP-FAST” method, it allows both machine and user authentication to be tied together securely and considered in policies. Your policies would then look something like:
- If only the machine is authenticated – do “x”
- If machine and user are authenticated – do “y”
- If user only authenticated – do “z”
A closer look at MAB
MAB is a fallback option for devices that don’t support 802.1x. It is virtually always used in deployments in some way shape or form. MAB works by having the authenticator take the connecting device’s MAC address and send it to the authentication server as its username and password. The authentication server will check its policies and send back an Access-Accept or Access-Reject just like it would with 802.1x. It doesn’t take a genius to work out that MAB is not a secure authentication method.
Now, MAB is not always used in isolation – you will often find that the authentication server is taking other attributes into account when making its decision (such as profiling information that helps to identify what the device may be – e.g. printer, phone etc.) however it is still susceptible to trivial spoofing. For this reason, all sessions authorised by way of MAB should be restricted in what they can do. For example, if you provide access to a printer based on MAB it should be restricted with something such as a downloadable ACL so that it can only talk to the required resources (i.e. print servers). If an attacker does come along and spoof the device’s MAC address they are going to be limited in what they can access – they will not have full unrestricted access.
This isn’t to say you shouldn’t apply restrictions to 802.1x authenticated sessions as well – it is good practice to do so. The principle of providing least privilege is a good one to follow regardless of the authentication mechanism. You should however definitely be restricting any sessions allowed on the network by MAB.
Hopefully this post has given you a better understanding of 802.1x and MAB. Importantly as well, how they are both used together to form a coherent NAC solution.
Questions? Comments? Please get in touch!
2018-06-04 01:00 +0100