The world of network access control is being drawn, irresistibly, into Microsoft's orbit now that the Redmond giant's full repertoire of Network Access Protection client, server and policy components are out there in the real world.
Last year's Interop Labs showed mostly wares adhering to the Trusted Computing Group's Trusted Network Connect (TCG/TNC) standard all working together nicely. But it's a new game this year because Microsoft has completely rolled out its NAP piece parts with Vista, Service Pack 3 for Windows XP and Windows Server 2008; Cisco has had to regroup its entire NAC strategy, quietly abandoning its own framework while forging ahead with adapting its Cisco Clean Access server for NAP deployments; and, there has been a relatively slow adoption of NAC in the enterprise.
If one were to write a history of NAC, the release of Microsoft Vista, Windows Server 2008, and Service Pack 3 (at the 'release candidate' level during our testing) to Windows XP would be regarded as the turning point in how enterprises deploy NAC. In the Interop Labs, we found a widespread assumption among team members and participating vendors that enterprises will want to start with Microsoft's built-in – not to mention free -- NAP clients in Vista and XP SP3 and build a full NAC solution on top of those. (Read a related story on whether ACLs and NAC can make for security success.)
While both Cisco and Juniper participated in the Interop Labs testing, both focused their effort on their NAC policy servers and network infrastructure rather than their own NAC clients. Cisco supported the Interop Labs with network enforcement points (including its own switches and wireless equipment) and its Access Control Server (ACS) policy server, but chose not to bring in its own NAC framework client. (Compare NAC products.)
Our testing followed that assumption, by demonstrating interoperability between the Microsoft NAP client and each of five NAC policy servers, including Avenda Systems' eTIPS policy server, Cisco's ACS, Juniper's Unified Access Controller (UAC), Microsoft's Network Policy Server (NPS) and Open Systems Consultant's Radiator.
Another change in the world of NAC is the slow merger of some of the TCG/TNC NAC standards with Microsoft's NAP technology. Microsoft and the TCG last year announced that Microsoft's Statement of Health (SoH) protocol would also be an official TCG/TNC protocol. The SoH protocol, whether in Microsoft's NAP or TCG's TNC, is used to communicate end-point security information from the client trying to connect to the network to a policy server.
While one communication protocol out of a whole access control framework doesn't mean that NAP and TNC are fully merged, it does mean that end-point security vendors such as McAfee, Symantec, and Trend Micro could kill two birds with one stone. If they can make a SoH call within a Microsoft NAP deployment with the newly minted Windows Server 2008 and its NAP policy server in place, they should also be able to make that same type of call within any TCG/TNC deployment.
Each of the titans (McAfee, Symantec and Trend Micro) of end-point security market have participated in the Interop NAC Labs in the past, but were conspicuously absent from this year's testing where they would have been expected to have fully baked solutions that operate in both NAP- and TCG/TNC-based networks.
Instead, newcomers Blue Ridge Networks and Avenda Systems, along with Microsoft, came to prove that their end-point security assessment and control tools could indeed work in a multivendor world.
End-point security assessment is divided into two pieces: a client piece that collects data and a server side piece that gives a thumbs-up or thumbs-down on the state of the client. The client side is called a System Health Agent (SHA) in NAP; the server side is called a System Health Validator (SHV). In the TCG/TNC world, these are called Integrity Measurement Collector and Integrity Measurement Verifier.
The SHAs we tested were Avenda's Universal System Health Agent (USHA), Blue Ridge's EdgeGuard, and Microsoft's Vista SHA on top of the built-in NAP client in Windows XP SP3 and Vista. The team achieved good interoperability passing health information to the policy servers as long as we had a Microsoft Network Policy Server (NPS) running the SHV side to validate posture.
When we tried to use other policy servers, we were able to get Avenda's eTIPS, Cisco's ACS, and Juniper's UAC to work, but only with a chain of policy servers. For example, to use Cisco's ACS policy server with a third-party SHA other than Cisco's, we had to link the ACS server to NPS server to the third-party SHV and have all three running all the time to make everything work.
One of the main reasons for this is that the end-point security vendors are betting that Microsoft's NPS will be a preferred platform for early adopters, and have written to Microsoft's specifications on the policy server side, rather than the TCG/TNC specifications.
Getting these chunks to work in the Interop Labs was likely eased by the presence of our own on-site Microsoft NPS guru, engineer Pat Fetty. But in an enterprise deployment with requirements for high availability and scalability, getting things up and running would likely be a more complex endeavor, much like getting a three cheese fondue to properly meld together.
One exception to the problem of stacking multiple policy servers together was with Microsoft's own SHA, a built-in part of its NAP client. This SHA/SHV pair was directly manageable from Juniper's UAC and didn't require us to stack servers together.
Anyone else?
While the focus on testing was in the Microsoft realm, we did attempt some TCG/TNC compatibility runs.
For example, we tried to use a "pure" open source TCG/TNC environment from Fachhochschule Hannover (FHH), which consisted of a Microsoft Windows client and the FreeRADIUS policy server. We discovered that while the FHH client talked to the FHH server, there was no end-point security check (a big issue in the world of NAC) and the FHH client wouldn't talk to other TCG/TNC servers — because it wasn't using the same internal protocols.
We also didn't find overwhelming support for non-Windows operating systems anywhere in the test bed. Avenda was the only vendor to bring its USHA for Linux (and matching SHV) and showed interoperability across the Interop Labs infrastructure. Although Avenda is also working on a NAP client for Mac OS X, no one brought working code to the Interop Labs to show it off.
The Interop Labs team was able to successfully integrate devices with no NAC client (such as Avaya and Cisco VoIP phones) and gear with only an 802.1X client running on it (such as Axis video cameras) into the network, if additional NAC deployment methods were in place. For example, we authenticated the VoIP phones using their Ethernet media access control addresses, and then used Great Bay Software's Beacon device profiler to make sure that the VoIP phones really were VoIP phones. This skips the posture checking part of NAC (although it's not really clear what security posture a VoIP phone in an embedded device might have), but does help to assure that only authenticated devices are allowed on the network.
Another area we hoped to test, but were not able to, was the new NAC specification from the TNC for “Meta-data Access Point" communication, called IF-MAP. This extension to the TNC architecture lets other network elements such as intrusion prevention/detection systems or firewalls report on misbehaving end points on the network. Since TCG hasn't publicly announced the protocol before making the announcement this week, no vendor was willing to test its fledgling IF-MAP support in the 2008 Interop Labs, but there is always 2009.
NAC retrenching
Overall, the team found that momentum in the NAC world is now focusing on Microsoft's NAP client. With Vista (and its built-in client) well out the door and the Microsoft NAP client for Windows XP expected to be released tomorrow (April 29) as part of Service Pack 3, the majority of corporate desktops will have a NAP client built-in. The expectation we found from the participating vendors (and some that didn't show up) is that a free, built-in client will be the base that everyone builds on when constructing an interoperable NAC solution.
The Interop Labs team will be showing everything they've learned on the show floor at Interop in Las Vegas this week, and further results, white papers, and configurations from the testing are all posted online.
< Return to main story: Interop Labs: Network engineers focus on NAC, UC products >