Network Access Control (NAC) systems limit entry to enterprise networks based on user identity, machine health and other factors. These capabilities are a blessing for IT managers faced with tight compliance requirements and growing demands for network access for contractors, partners, and customers. But many NAC systems are closed, unable to interface with an enterprise's policy servers, authentication servers, network equipment and security systems. Fortunately, hardware and software standards developed by the Trusted Computing Group (TCG) provide standard extension points that enable this necessary multi-vendor interoperability. Based on recent industry progress in the NAC area, the timing is right to explore how these extensions work and how they may be used.
Within the past few years, Network Access Control has entered the spotlight as a technique to provide improved network security. Major vendors have introduced NAC products and customers have begun to deploy them. To ensure interoperability between NAC products and open interfaces between NAC products and other complementary systems, the Trusted Computing Group (TCG) introduced in 2005 the Trusted Network Connect (TNC) architecture and specifications. The open TNC specifications, available at www.trustedcomputinggroup.com, allow NAC products from different vendors to work with each other and with existing network equipment, authentication servers and other components. In May, TCG and Microsoft announced interoperability between Microsoft's Network Access Protection (NAP) architecture and the Trusted Network Connect (TNC) architectures. By examining these two architectures and then diving deeper into the TNC approach, the possibilities now available to ISVs (independent software vendors) and ultimately to users, will be better understood.
NAC Architectures
Two of the major NAC architectures that exist today are the TNC architecture developed by TCG's Trusted Network Connect (TNC) Work Group and the Network Access Protection (NAP) approach developed by Microsoft. There are dozens of other proprietary architectures available from different companies, but for the purpose of this article, the focus is on open standards.
Based on the latest TNC specification, TNC and NAP can now interoperate. However, they do have differences. As shown in Figure 1, the TNC architecture has an Access Requestor, Policy Enforcement Point, Policy Decision Point (PDP), and three different abstraction layers. The specific entities and interfaces (IFs) in this architecture will be discussed. later.
Microsoft's NAP policy enforcement platform, built into Windows Vista and to be included in Windows Server 2008 and Windows XP Service Pack 3, allows users to protect network assets by enforcing compliance with system health requirements. As shown in Figure 2, Microsoft's NAP architecture is a specific instance of the TNC architecture. Although the names of components differ slightly, the functions are identical and interoperability is now possible.
Using Standard Protocols
In order for a NAC system to provide comprehensive network security, any system that connects to the network should have a health check and the user should have an authentication and authorization check performed whenever they connect to the network. Client-server protocols are required to perform the checks.
The TNC architecture has a layered architecture with three client-server protocols. The lowest level is IF-T, a transport protocol that provides many options for transporting messages from the client to the server and back. For remote access, a Secure Sockets Layer (SSL) Virtual Private Networks (VPNs) or an IPsec (Internet protocol security) VPN may be used for IF-T. For 802.1X , the widely-supported Extensible Authentication Protocol Over LAN ( EAPOL) and Remote Authentication Dial-In User Service (RADIUS) standard protocols can serve as client-server transports for both wired and wireless networks .
At the next higher level, the IF TNCCS protocol manages different phases of the health check as well as the overall health check status and parameters. The top level in the TNC architecture uses the IF-M protocol to convey measurements from the Integrity Measurement Collectors (IMCs) to the Integrity Measurement Verifiers (IMVs). This is where the greatest potential for extensibility, diversity and creativity come into play. With a small level of programming ability, anyone can implement a custom health check software module and plug this module into the TNC system. For example, a webcam check can be created by writing a new IMC, a simple piece of software loaded onto the Access Requestor. The IMC checks whether a webcam is installed on the client and sends a message with the answer, using the IF-M protocol to the server where a matching IMV receives the message and decides if access should be granted.
Communication between IMCs and IMVs occurs through the IF-M protocol. Since TNC is a layered architecture, the IF-M is carried by the IF-TNCCS protocol, which resides on top of the IF-T protocol. This approach is similar to the layering used to carry HTTP over TCP over IP. It allows the IMC-IMV communication to operate over any transport protocol without having to worry about the details of this transport or of the overall health check.
Since TCG has standards in this area, a network client from one vendor can work with a server from another. For example, a Microsoft Windows client attempting to connect to a network can be health checked and authenticated by a Juniper Policy Decision Point. Since both support the standard protocols, they can work together.
Using Extensions to NAC Systems
IF-PEP is a standard protocol used to communicate with the Policy Enforcement Point. The IF-PEP standard interface provides many options for enforcement, including switches, wireless access points, routers, firewalls, VPN Gateways and more. By using a standard protocol to interface with each enforcement option, the right one can be chosen for a specific application. For example, rather than a simple yes or no access decision, a firewall can provide the fine-grained access control needed to allow limited access to certain portions of the network for a contractor or restrict the bandwidth used by a student.
IF-IMC and IF-IMV are matching interfaces, one on the client and one on the server. These interfaces allow the addition of plug-in modules on the client and the server. The IMCs and IMVs provide the opportunity to perform additional health checks for the client and verify them on the server. For example, a health check could be developed and added to determine if a USB drive is plugged into a machine or determine if a webcam built into a laptop is turned on. An added IMC gathers information about the client and an IMV added on the server side receives that information and makes a recommendation. A non-compliant client can be quarantined and a message sent describing how to fix the problem.
The last extension point, IF- PTS, is optional but unique and very powerful. Using a Trusted Platform Module (TPM) , the limitations of software-implemented security checks can be overcome. The TPM is one of the initial constructs based on TCG specifications. It is a microcontroller that stores digital keys, passwords and certificates. More than 50 million corporate laptop and desktop computers have a TPM. During the computer's boot sequence, the TPM measures critical software and firmware on the computer before it is run and stores the measurements in protected memory. In this hardware location, the date is secure from modification.
Developing Extensions
To develop an extension such as the webcam example discussed previously, there are basically two alternatives, either do-it-yourself or find an expert to do it for you. For do-it-yourselfers, TCG's Web site provides the specifications for all of these interfaces and other information. With the details provided in the specification and other support documents, a software engineer can develop user-specific extensions. The site also has forums that could provide direction and an opportunity to discuss issues.
An additional resource is TNC Central, a Web site community for IT administrators, contractors and vendors who are building TNC products and extensions. Although separate from TCG, the site is based on the standardization efforts of TCG's TNC Work Group.
Future Direction
The existing TNC interfaces that have been discussed were created to address the most urgent needs for interoperability in NAC systems. That does not mean they are the only needs. An important future direction for the TNC Work Group in developing NAC standards and extensibility interfaces is to support and perform checks on non-responsive nodes (ones that do not have any TNC software). Currently, there is no standard way for a NAC system to handle a printer or other endpoint device that does not have any NAC software.
A broader trend focuses on integrating network security components and other network elements into the network access control system. For example, Intrusion Detection Systems and Anomaly Detection Systems sit on the network, watching for anomalies or signs that a particular machine is infected or not operating as expected (i.e., running peer-to-peer file sharing or attacking other computers on the network). When problems are detected, a traditional Intrusion Detection System or Anomaly Detection System raises an alarm. But if everyone has gone home and it's late at night, subsequent action presents a problem. It requires sending a page or a call to address the interrupt and shut down the offending node. Tying these systems into NAC can automatically initiate action. An access requestor that is attacking other computers on the network or, in general, not conforming to acceptable network behavior and policies can be stopped immediately. These actions are not possible today, but with interoperable standards, they are a very real possibility in the future.
Steve Hanna is a distinguished engineer at Juniper Networks. He is co-chair of the Trusted Network Connect Work Group in the Trusted Computing Group and co-chair of the Network Endpoint Assessment Working Group in the Internet Engineering Task Force. Hanna is active in other networking and security standards groups such as the Open Group and OASIS. He holds an A.B. in Computer Science from Harvard University.
