I’m sure Cisco would love to be the only network device that its customer have, and to be honest, there are many companies where that is true. However, it is just not the reality of 100% of companies that deploy Cisco ISE or ACS.
One item in particular that I am asked about frequently is MAC Authentication Bypass (MAB). This is the process of a non-authenticating device (a device without an 802.1X supplicant running on it) connecting to a network with 802.1X enabled. Since there is no supplicant to answer the EAP identity requests from the authenticator (switch, wireless controller, etc) the authenticator will generate the authentication request FOR the endpoint using the endpoint’s MAC address as the username/password for the Access-Request message.
Background on MAB
Take a look at Figure-1. This graphic is displaying a printer w/ a mac address of 00.00.0c.ab.cd.ef which is connected to a switch that has 802.1X enabled on its ports and sends the authentication requests to a RADIUS server.
In Figure-1, the printer did not have a supplicant, and therefore is unable to participate in the 802.1X identity exchange. Therefore the switch sends a RADIUS Access-Request to the RADIUS server, which determines if the device is allowed on the network. Assuming it is allowed on the network, the server sends a RADIUS Access-Accept message to the switch, allowing the printer to participate on the network.
It is important to note that while 802.1X is a standard, MAB is not. MAB is something that each vendor could implement differently if they so choose, just as long as the RADIUS communication complies with the standard for RADIUS.
How does a switch (authenticator) know when the endpoint that is plugged into it does not have a supplicant? Following the 802.1X standard, the method is simply a timeout. The authenticator is meant to send EAP over LAN identity request frames every 30 seconds by default. After 3 timeouts (a period of 90 seconds by default) it is assumed that the endpoint must not have a supplicant. As with most Cisco switch features, timers are adjustable. Figure-2 shows the timeouts occurring three times before MAB begins.
Keep in mind that MAB is inherently not a secure technology. When implementing MAB you are bypassing the stronger security of 802.1X by allowing specific MAC addresses to gain access without authentication. When using MAB, always follow a defense-in-depth approach. This means a device that has been authorized to use the network from a MAB request should be granted access to the networks and services that device is required to speak to only.
In other words: don’t provide full access to devices that have been MAB’d, instead provided them with an authorization that is more limited. Since MAB is a standard RADIUS authentication and the authorization decision is being sent from the authentication server (ISE), there really are no limitations to the type of authorization results that can be sent to the authenticator.
Examples are:
- Downloadable ACLs (dACLs)
- Dynamic VLAN assignment (dVLAN)
- URL-redirection
- Security Group Tag (SGT)
- Smart port macros
- Many more
Keep in mind that if an endpoint does not have a supplicant, it is never recommended to change its VLAN. When changing a VLAN assigned to an endpoint, that endpoint must know (somehow) to renew its IP Address. The best solution is to not use VLAN changes on open networks, because there is nothing on the client to detect the VLAN change & trigger the DHCP renewal. When the network uses 802.1X, there is a supplicant on the endpoint to do the VLAN change detection (is gateway reachable, etc.) & trigger the DHCP renewal.
If you still choose to change the VLAN on open networks, then you have only a few choices (none are considered a best-practice). You can set the DHCP lease time to something VERY low, so it will renew the address frequently. There is also an option to use an ActiveX or Java Applet on the portal that will do the VLAN change detection in lieu of a supplicant.
Cisco and non-Cisco MAB
As mentioned previously: there is no standard for MAB. Different vendors will implement MAB in different ways, using different RADIUS values. There is a key RADIUS attribute that is used to determine what type of authentication request is being sent: Service-Type. Some common values for Service-Type with Cisco network access devices are listed here:
- Service-Type=Framed (signals an 802.1X authentication)
- Service-Type=Login (signals WebAuth)
- Service-Type=Call-Check (signals MAB)
Since MAB is not a standard, some vendors will send a RADIUS service-type of “Login” with MAB, some will send a RADIUS service-type of “framed”. So, why would Cisco use service-type of “Call-Check” if no other vendor does? Why does Cisco perform MAB differently than everyone else? Quick answer: security.
Many years ago, before Cisco released Cisco ISE or the Cisco ACS 5.x server, there was a possible security vulnerability with MAB. That security vulnerability is still possible with other solutions and other network devices. The issue was/is the lack of differentiation between a MAC Authentication Bypass request and a Local Web Authentication request. Both requests will come from the network device with the same service-type and the same format. There was no database separation of user-id’s from endpoint-id’s (mac-addresses). As displayed in Figure-3, a malicious user could enter a mac-address into the username and password fields of a web authentication or maybe even into the endpoint supplicant, and gain access to the network.
In an effort to close this security hole, and make MAB a bit more secure, Cisco changed the way it does MAB. The Key Differences are listed here:
- For authentication requests to be processed as MAB (by default), service-type must be Call-Check
- RADIUS Servers (ACS & ISE) maintain a separate Endpoint Database
- The calling-station-id is the value that will be compared to the Endpoint Database, ignoring the username and password fields of the MAB request
Figure-4 illustrates the concept of a Cisco compliant MAB. A packet capture is listed on the left side to highlight the fields of importance.
All supported Cisco Network Access Devices will use a service-type of “call-check” for MAB requests. They will also ensure the calling-station-id is populated with the mac-address of endpoint. Lastly, Cisco ISE uses a simple check-box within the allowed-protocols configuration as another method to permit or deny the access into the endpoint database for the MAB request, as seen in Figure-5.
Configuring Cisco ISE for 3rd Party MAB
While Cisco ISE allows for the acceptance of non-Cisco MAB, it is not typically something you should or would want to do for all incoming requests, only where absolutely necessary. I recommend that you separate this out by using a different policy set for non-Cisco switches. I normally do this by creating a Network Device Group (NDG) for all NADs that are non-Cisco, as seen in Figure-6.
Once you have your NDG’s setup and the non-Cisco NADs added to those NDG’s; you can then build the new policy set. Figure-7 shows the policy set, and the rule that matches the policy set, which is translated as: “if NDG starts-with ThirdParty then use the ThirdParty policy set”.
Each network device may have different capabilities with sending usernames/passwords and even filling in the calling-station-id field with the MAC address of the endpoint. In my personal tests I have found the following:
- Juniper EX Switch: Leave both Calling-Station-ID and Password options checked.
- HP (H3C) Switch: Uncheck Calling-Station-ID. Leave Password option checked.
- RuggedCom Switch: Uncheck Calling-Station-ID. Leave Password option checked.
- Avaya (Nortel) Switch: Uncheck BOTH Calling-Station-ID and Password options.
- Alcatel Switch: Uncheck BOTH Calling-Station-ID and Password options.
Next, you will need to have an “Allowed Protocols” set that is configured for the 3rd party product you are using. You may need to create one for each vendor, which would be the most explicit and secure way to configure the options. Figure-8 shows an example 3rd Party Allowed Protocol set that would work for Juniper EX switches (in my testing).
Once you have created all the “Allowed Protocol” sets that you need, you will then create the authentication rule(s) for each one. Figure-9 illustrates an authentication rule that would work for both Nortel and Alcatel switches, based on my testing.
Figure-10 illustrates an authentication rule that would work for Juniper EX Switches, based on my testing results. It also includes the new default rule at the bottom of the ThirdParty policy set that deny’s all non-matching traffic.
Well that about covers MAB with 3rd Party devices. I hope you found this blog post useful! As always, I look forward to reading & responding to any comments you may have.
Security of Everything 