In-Depth

An Rx for Network Authentication Anarchy

A new appliance acts as a meta-broker to the wild profusion of competing network access control schemes

• By Stephen Swoyer
• 12/06/2005

If Slim Pickens were alive today, he’d probably say the best way to lock down an enterprise network is to head potential intruders off at the pass.

Several vendors—including Cisco Systems Inc. and Microsoft Corp.—have taken that advice to heart, introducing network access control programs. Now Identity Engines Inc., a start-up vendor with a Cisco-heavy pedigree, has introduced its own variation on this theme.

The company pitches its Ignition 3000E rack-mounted appliance as a sort of meta-head-‘em-off-at-the-pass network access control system, providing support for authentication, authorization, and auditing services for distributed network infrastructures. Identity Engines says Ignition integrates with networking equipment from Cisco, Nortel Networks, and other prominent vendors, and the Ignition appliance supports standards (or de facto standards) such as RADIUS, 802.1x, Microsoft’s Active Directory, and Lightweight Directory Access Protocol (LDAP).

“It’s an appliance-based product that does authentication within the enterprise. It’s designed to interact with all of the major manufacturers out there—Cisco, Nortel, wireless VPNs—through standard protocols,” says Roy Chua, co-founder and vice-president of marketing with Identity Engines. “Equipment manufacturers were doing a great job building the silicon for network enforcement itself. What was missing was the sort of identity infrastructure behind it that could scale appropriately to serve the needs of the connected enterprise. That’s what we do.”

Chua and other Identity Engines officials say there’s a pressing need for a product such as Ignition. For one thing, they argue, the best laid interoperability plans of Cisco and other networking giants haven’t yet resulted in a silver bullet for universal network authentication and access. “There are quite a few players trying to wrest control by putting an in-line product in place. Our view is that it’s much better to go in there and work with what customers already have—the Ciscos, the Extremes, the Foundrys. We work with what’s already there.”

In many cases, Chua says, organizations are still using a flavor of RADIUS—the same technology used to authenticate dial-up remote access sessions—to authenticate their LAN, WAN, and VPN clients. Not that RADIUS isn’t an acceptable way of doing this, officials stress—just that no two RADIUS implementations are alike. There’s another consideration, too: network security is a growth industry. Market watcher Infonetics Research says worldwide VPN services revenue (to take just one market segment) will reach $30 billion by 2009, while worldwide security service revenues should eclipse $8 billion over the same period. With so much money up for grabs, heterogeneous authentication and access control schemes are bound to proliferate, too.

Enter Ignition, a kind of meta-broker to the wild profusion of competing network authentication schemes. Officials position it as a single point of administration for the authentication, authorization, and accounting (AAA, in network security-speak) of network clients.

“At the core of our product, we have a robust policy engine that allows you to do authentication from any connection, using any protocol,” says Sean Convery, chief technical officer with Identity Engines, and a Cisco veteran. “The idea is that by using standards-based protocols and managing and enforcing policies, we’re allowing organizations to take advantage of the gear they already have in their infrastructures.”

A Case in Point

Consider Cisco’s network security stack, for example. Two years ago, the company launched its network admission control (NAC) program. NAC is a multi-vendor effort that, to date, involves IBM Corp., Symantec Corp., Trend Micro Inc., and a host of other software vendors. Although it’s still gestating, NAC’s promise is two-fold: it’s designed to help contain potential threats (head ‘em off at the pass, so to speak) and to manage overall network authentication at both the client endpoint and in switches, routers, and other networking devices.

While NAC’s goals are laudable, its execution—especially with respect to Cisco’s labyrinthine product stack—has been choppy.

In October, Cisco announced new outbreak and intrusion prevention technologies designed to protect against malicious worms and viruses. The new offerings heaped additional confusion on Cisco’s already befuddling product set. Analysts were underwhelmed, and some assailed what might be called Cisco’s scattergun approach to network self defense.

“[T]he Cisco Incident Control System and outbreak containment features underscore the complexity and multi-layered nature of a Cisco Self-Defending Network in a particularly negative manner,” wrote analysts Charlotte Dunlap and Joel Conover, both of Current Analysis. “Perhaps more concerning is the fact that this portion of Cisco’s outbreak prevention strategy doesn’t even touch its desktop offerings. Cisco’s security offering has grown so large and multifaceted that it is impossible to administer from a single central console, making the system more complex and more expensive to own.”

Some users, too, have had enough. “I think Cisco has a lot of good pieces for a security solution, but they don’t have any easy way to manage all the different pieces. I work for a [medium]-sized business [that] has over a dozen pieces of Cisco security equipment, and there is no easy way for me to manage every device from one console,” writes one poster to the CertCities.com Web site.

An Rx for Authentication Anarchy

Convery says Ignition can interoperate with NAC, with Microsoft’s own Network Access Protection (NAP) program, and with other (de jure or de facto) proposed access and authentication standards.

“There are several emerging standards in this space. But right now, there [are] five to seven ways you could try to solve this problem, none of which is fully embracing open standards yet,” he observes. “But there are other issues, too. For one thing, there are new considerations around the deployment of these technologies. Today when you connect to a network, you get on or you don’t get on, and the number of steps you go through [to do so] is relatively small. When you get into things like policy access, the complexities in troubleshooting [authentication or resource access problems] can grow exponentially.”

It’s a recipe for anarchy, Convery argues, because organizations don’t just authenticate at the network level. Most large companies also tap enterprise directory services (e.g., Active Directory, Novell Directory Services, Network Information Service), single sign-on services, or other access control technologies. In many cases—e.g., for access to resources on a particular subnet, for the next-generation access control and authentication services (NAC, NAP, etc.) that are just now emerging—these need to interoperate with authentication services at the switch or router level.

“From a technology perspective, as you look at the complexity involved, what often happens is that if a currently deployed product isn’t flexible enough to meet the specific configuration requirements of a given technology, often multiple legacy [devices] will have to be deployed to manage wireless access versus LAN access [for example],” he explains. “Because of the policy decisions we can make out in front of the product, we’re able to centralize that so that we can have a record of all authentication requests coming into the product. When you think of an existing RADIUS server, you’re going to need to connect to an LDAP store or an Active Directory store in order to gain access to certain resources,” he notes.

Elsewhere, Ignition supports an SDK for guest-user provisioning that lets organizations delegate authority for creating guest accounts to the help desk, for example. This simplifies the process by which guests are usually accommodated, Chua argues, because network administrators no longer have to manually create and then destroy guest accounts. Instead, network administrators can use Ignition to create templates that have the correct user permissions already in place. “We’re able to authenticate users and differentiate between guests and corporate users and put them in different VLANs,” says Chua.

A single 1U Ignition appliance can support between 500 and 2,000 clients, officials say. The Ignition 3000E is a LAN-only device, but Identity Engines expects to ship a WAN-capable device early next year.