MAB Operation
As indicated in preceding sections for 802.1X deployments, only EAPOL control frames are typically processed by switch ports while 802.1X is maintained in an operating and active state. However, this also means that MAC addresses from any edge device might not be known until EAPOL frames are processed from it. These are the security benefits of 802.1X, and they do not change in any way with respect to any MAB implementation. Because it is noteworthy to this discussion, spanning tree is not even in a forwarding state on the port until it is authorized through 802.1X.
There is no differentiation capability for the Guest-VLAN. If the client on the wire cannot speak 802.1X, the Guest-VLAN is enabled. Any device deployed into a Guest-VLAN might be a machine on the network that an administrator does not need or want to be placed in a Guest-VLAN. Hence, the ability to employ differentiated services based on the MAC
address alone is advantageous for identification purposes. Upstream, the Guest-VLAN might also only have access to limited resources, as defined by the network administrator. Prior to MAB, a MAC address might only be known to a switch port after the port is enabled and placed into a Guest-VLAN. Also, after a port is enabled and placed into a Guest-VLAN, no authentication (other than EAPOL initiation by a supplicant) takes place on the port directly, and the system can learn any number of MAC addresses on the port by default (which inherently does not provide security). Hence, there are limitations in attempting to use the Guest-VLAN concept as a solution to provide access for any managed non-802.1X devices in the context of IBNS.
So, what is needed is a way to update a switch CAM table with a (single) MAC address while not circumventing the value added from a port-based 802.1X solution to begin with.
MAB makes an effort to leverage similar efforts that are already applied to other authentication schemes or mechanisms (802.1X/EAP). This makes deployments easier for you to deploy and understand. MAB provides this controlled access to devices based on their MAC address. MAB should allow non-802.1X compliant end devices to be governed by controlled access to the network in a transparent manner using a prepopulated database technique. The requirement for enabling access for clients that do not support 802.1X supplicant functionality is applicable to IBNS, where a need exists to enable network access for all clients. It is critical to IBNS for MAB to leverage dynamic policy assignment. MAB allows end users to authenticate (without any supplied credentials). MAB is not intended to directly provide a MAC address learning capability, in much the same way, that 802.1X does not directly provide a credential learning mechanism. It is to be provided solely as a means of authentication and enforcement. Although MAB requires some form of a provisioning process, the described functionality is independent of any existing processes. Alone, this process assumes MAC addresses are already known. MAB should then allow clients that cannot/do not support 802.1X the necessary functionality to integrate into an IBNS strategy. Like 802.1X, MAB is designed for the access layer and to address the need for network-edge authentication similar in nature and benefits to the functionality provided by the IEEE 802.1X framework (without the requirement for client-side code).
Much like the Guest-VLAN, MAB operates based on an 802.1X timeout condition. After a switch port can ascertain that an 802.1X supplicant is not present on the port, it falls back to checking the MAC address (which is an authentication technique of lesser security). After timing out 802.1X on the port, a switch can learn a MAC address through classic MAC learning techniques. After a MAC address is learned, it is authenticated in much the same way an 802.1X supplicant would be authenticated. RADIUS is used as an AAA protocol for admission criteria, and the switch acts as a proxy. Figure 17-7 illustrates a complete operational flow of MAB.
Figure 17-7 MAB Operation Client
00.0a.95.7f.de.06
EAPOL-Request (Identity)
Dot1x/MAB Upon Linkup
RADIUS
EAPOL-Request (Identity)
Dot1x/MAB Upon Linkup
|
-4- |
v |
EAPOL-Request (Identity) D = 01.80.c2.00.00.03 © |
30 Seconds |
|
v |
EAPOL-Request (Identity) D = 01.80.c2.00.00.03 © |
30 Seconds |
|
|
o |
EAPOL-Timeout ^ Initiate MAB 14 |
30 Seconds |
|
|
■ |
Learn MAC © |
Variable ► |
Port Enabled
RADIUS-Access Request
RADIUS-Access Accept fl
As Figure 17-7 illustrates, MAB only initiates after an 802.1X timeout. MAB then requires a variable amount of time for the end station to attempt to send traffic into the network for the MAC to be learned by the switch. After this occurs, RADIUS is initiated to the backend, asking if the MAC should be allowed network access.
After a host/device fails to supply 802.1X authentication credentials, the network-access device takes the learned MAC address and hands it off to the authentication server as both the username and password. If the host/device fails to authenticate at this level, a user can optionally be placed into a predetermined Guest-VLAN and, at this time, other authentication methods can be attempted. Alternatively, the Guest-VLAN can be used as a means to support a provisioning process of MAC address through scanning techniques or captive portal techniques, if end users are applicable to the devices seeking to be authenticated. Ultimately, if the host/device passes with MAB credentials, the user can then be placed into the configured VLAN and acquire an IP address to begin its desired functions. Operationally, MAB largely relies on an 802.1X timeout condition; this timeout is configurable. See the section, "802.1X Guest-VLAN Timing," for timeout specifics.
Optionally, dynamic policy can be downloaded from RADIUS the same way this can be achieved with 802.1X in the form of VLAN assignment. This allows for consistent processing of authentication features to be applied in a consistent manner. Dynamic policy downloaded from an authentication server includes any capability currently available with 802.1X on the access switch in question (such as per-user ACLs, VLAN assignment, and so on). Also, the validity of the authorized session is enforced on the switch in much the same way it is enforced with 802.1X. This enforcement is achieved by restricting the traffic originating on the authenticated port to come from only the authorized MAC address. With MAB, by default, only one host can be authenticated and locked down per port. Any new MAC address that is seen to attempt to pass traffic on a port is treated as a security violation.
Like 802.1X, MAB is a port-based feature; it is required to be discretely enabled on ports. The following represents specific port configurations with MAB added:
interface FastEthernet0/1 switchport access vlan 2 switchport mode access dot1x mac-auth-bypass dot1x pae authenticator dot1x port-control auto
MAB activates when 802.1X times out waiting for an EAPOL packet on the wire. The 802.1X state machine enters a waiting state and relinquishes control over to MAB to begin device authorization upon this timeout occurring. MAB runs passively and does not transmit any packets to detect devices. Again, the responsibility lies with the attached device to send traffic. If a device sends no traffic, technically, a port could be listening for packets forever after MAB activates. When packets arrive on a port where MAB is active, this results in the switch forwarding packets to the CPU. The source MAC address is gleaned off the packet and forwarded to the MAB process for authentication. The trigger packet itself is needed for session state creation. Any time MAB activates, if an EAPOL packet is detected on the wire (such as an EAPOL-Start from an 802.1X supplicant), 802.1X never relinquishes control over to MAB. The history of EAPOL packets seen on the wire is maintained as long as the port is physically connected. This history is lost upon a physical link change, because the state machine for both technologies is directly reliant on link state.
After MAB activates, a port is typically in an unauthorized state (because 802.1X times out). So, while waiting for a packet to glean a MAC address, if an EAPOL packet is detected, MAB deactivates and relinquishes complete control to 802.1X. 802.1X then attempts to authenticate the port. From then on, MAB never activates as long as the link is never lost on the port.
In some cases, MAB might have authorized a port already, and 802.1X is then seen on the wire. An example of this might be a successful MAB attempt before 802.1X has started on the client (such as when timers are tweaked for early timeout), or MAB being executed in an effort to assist the end station in downloading 802.1X-supplicant software. Typically, in this condition, the MAC addresses from both events match. However, if a port is authorized with MAC address A, and an EAPOL packet arrives with a source MAC address of B, this triggers a security violation by the switch.
The Guest-VLAN also serves as a failure condition for MAB if configured on the same port as MAB. Else, the failure process for MAB is to continually try and 802.1X authenticate the port again. Today, for Cisco IOS-based switches, this is primarily caused by a MAB failure actually causing the port to go into the failure state, just like when an 802.1X supplicant fails authentication. So, after 802.1X is attempted again, times out again, MAB
is attempted again. However, because the Guest-VLAN can serve as the failure criteria for MAB if it's configured along with MAB, this might provide systemic value. An example of the value it could provide is for MAB and the Guest-VLAN to indirectly provide a means to provision credentials in an identity store for MAC addresses that might not be known in advance to a network. Figure 17-8 depicts this operation.
Figure 17-8 802.1X, MAB, and Guest-VLAN Interaction
Figure 17-8 802.1X, MAB, and Guest-VLAN Interaction
The operational nature of this feature interaction was designed primarily as part of MAB to support backward-compatibility for devices that cannot speak 802.1X and have deployed the Guest-VLAN.
NOTE If a port is initially configured for 802.1X with Guest-VLAN, and the port activates in Guest-VLAN, it remains there even though a network administrator enables MAB. The port link status must be flapped to initialize the 802.1X state machine.
In summary, MAB functions as a port-based feature. It is primarily used as a fallback mechanism to 802.1X. Like 802.1X, there is no de facto ability to support more than one MAC per port. A MAB port can be optionally enabled for multihost mode, just like it is done with 802.1X. MAB cannot be used as a means to deal with failed 802.1X authentication attempts. MAB provides more options if you have bought into port security with configured MAC addresses. These options include the promotion of mobility, dynamic downloading of policy, and so on. MAB provides a migration path from legacy technologies, such as VMPS. MAB also works with any standard RADIUS server (with a default timeout of 30 seconds with three retries). This means that the total timeout period is at least 90 seconds by default, which is the same minimum default timeout of the Guest-VLAN. A device must also send traffic into a switch for the MAC to be learned after the 802.1X timeout. If MAB fails, network access is implicitly denied. If MAB fails and the Guest-VLAN is also configured, the Guest-VLAN is enabled (for backward-compatibility). MAB does not call for a provisioning mechanism, although the Guest-VLAN can assist in this process.
Continue reading here: Current State Authentication with 8021X
Was this article helpful?