NAC/802.1X support in access switches is all over the map

Many switches today support 802.1X authentication, a basic building block in NAC. The key question is what kind of access authenticated users can expect. In the six-test scenarios we developed for this project, we uncovered major differences among products in terms of the conditions under which they'll grant access as well as what sort of access they'll permit.

In the first 802.1X scenario, a client (or supplicant, in 802.1X-speak) successfully gets authenticated and the switch places the client into a statically defined VLAN. All switches passed this basic test, in which the switch connected Juniper Odyssey supplicants to a Juniper Steel-Belted Radius server (see 802.1X table)

The second scenario, involving so-called multi-auth, turned out to be the most problematic, with failures from the Cisco and Dell switches. In this scenario, there are multiple users attached to a single switch port and each must be authenticated before being granted access to the network. We attached multiple users using an unmanaged hub (a common use case in many corporate conference rooms where there's only one Ethernet drop). Other uses for multi-auth include IP phones (which sometimes have a two-port switch to attach a PC through the phone) and wireless LAN access points (especially so-called thin access points, which attach to a switch/controller and field associations from multiple wireless clients).

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Many switches today support 802.1X authentication, a basic building block in NAC. The key question is what kind of access authenticated users can expect. In the six-test scenarios we developed for this project, we uncovered major differences among products in terms of the conditions under which they'll grant access as well as what sort of access they'll permit.

In the first 802.1X scenario, a client (or supplicant, in 802.1X-speak) successfully gets authenticated and the switch places the client into a statically defined VLAN. All switches passed this basic test, in which the switch connected Juniper Odyssey supplicants to a Juniper Steel-Belted Radius server (see 802.1X table)

The second scenario, involving so-called multi-auth, turned out to be the most problematic, with failures from the Cisco and Dell switches. In this scenario, there are multiple users attached to a single switch port and each must be authenticated before being granted access to the network. We attached multiple users using an unmanaged hub (a common use case in many corporate conference rooms where there's only one Ethernet drop). Other uses for multi-auth include IP phones (which sometimes have a two-port switch to attach a PC through the phone) and wireless LAN access points (especially so-called thin access points, which attach to a switch/controller and field associations from multiple wireless clients).

Most switches require that multi-auth be explicitly configured. The Extreme switch required no additional configuration for multi-auth. After doing so, the Cisco and Dell switches authenticated the first user – but then allowed traffic from the second and subsequent users onto the network without authentication.

The physical-world analog of this behavior is "badge tailgaiting," in which someone with a door badge enters an office building and others follow while the door is open. The security implications are obvious.

Cisco says it strongly discourages customers from using multi-auth except for certain uses, such as an IP phone with a PC attached, and then encourages customers to segregate traffic onto different VLANs.

Strictly speaking, multi-auth is actually a violation of the IEEE's 802.1X standard. The spec's MAC relay function (the port access entity) includes a logical switch that's either on or off. There's no provision for a sort of "selective on/off" state that permits some frames but denies others (see Breaking the standards sidebar). 

Still, since there are common use cases for multi-auth, it's fairly widely supported. The danger, as our test results show, is that network managers may be lulled into a false sense of security, erroneously believing that enabling 802.1X will result in authentication for all traffic.

The third scenario, involving dynamic VLANs, was far more straightforward. This scenario modeled networks in which a roving population of laptop users may plug into any switch port at random. The goal was for the switch to dynamically assign a switch port into a given VLAN after successful authentication.