Archive for May, 2006

802.1X and the Default VLAN

Friday, May 26th, 2006

When discussing 802.1X, authenticated networks, and RADIUS with customers I’m often confronted with a small bit on confusion with regard to the deployment options. The standard way of thinking about 802.1X is that it represents an all or nothing proposition. You either configure and install supplicants on all endpoints (with standard exceptions for printers and the like) or you use an overlay (non-802.1X) authentication technology which typically employs some variation of a captive portal. The captive portal is a device that forces traffic through itself and can force authentication at that step (just like hotel broadband). However, a nice feature on most switches enables smoother 802.1X migration as well as long term interoperability with non-802.1X systems (like guest or contractor machines). This feature is the default VLAN and what it basically says is if the client does not respond to the EAPoL challenge it is placed on a default VLAN. One viable deployment choice has this default VLAN routing traffic through a captive portal where web-based authentication can take the place of the 802.1X authentication step. Some network devices support this web authentication on their hardware directly which represents yet another choice.

Regardless of which technique you choose this gives IT departments the ability to roll-out authenticated networks without managing massive exception lists or maintaining support for 802.1X supplicants on outdated client OSs. It also gives a natural incentive in places like universities to encourage migration. Because the 802.1X route can be considered “fast-path” as it doesn’t involve sending traffic through an unnecessary intermediary device, students can be encouraged to deploy a supplicant to get faster network access.

RADIUS and Authentication Woes

Friday, May 5th, 2006

Network World Magazine recently ran a review of Cisco’s new ASA 5500 SSL VPN technology. Nestled in the review are a couple great tidbits about why direct integration between user directories and network infrastructure devices is a bad idea, and why the flexibility of your authentication infrastructure is key to allowing user AAA to work as promised by the tenets of NAC.

In our authentication and authorization tests, we discovered that while the ASA claims to support Active directory and Sun’s Lightweight Directory Access Protocol server, it didn’t support our schema of the Sun LDAP server. When we tried switching over to our SecurID RADIUS server, we discovered that Cisco fully supports the additional RADIUS messages required to integrate with SecurID.

However, Cisco had no flexibility in mapping users to groups, and would have required us to change our existing RADIUS schema, breaking all the other applications plugged into SecurID.

The two critical bits of learning here are first that in real-world deployments, schemas are rarely designed to support the network infrastructure device and often they are non-standard. This is one of the many reasons why direct integration from the network infrastructure device to the directory is architecturally a bad idea. The fact that this was exposed even in a test environment simply magnifies the concern. Second, many current RADIUS servers simply lack the capability to integrate the directories and network devices with the flexibility required by today’s deployments. Interconnecting between ethernet switches, firewalls, VPN gateways, wireless APs, dial-up servers, and Microsoft Active Directory, LDAP, and token servers requires approaching the policy-based AAA problem in a new way.

Ignition 3.0

Tuesday, May 2nd, 2006

My company, Identity Engines, just released version 3.0 of our policy decision / AAA platform. You can read the press release here. The major new feature is a user provisioning framework that allows Ignition to send a set of arbitrary VSAs to the enforcement point as a result of the policy decision. These VSAs can be tuned based on the vendor of the enforcement point, the location on the network, or any information we learn about the user from the back end directories. This is the next step in offering some ability to centralize authorization rules within the platform. We’re out at Interop this week showcasing the new functionality. If you are in town, feel free to stop by and say hello.