|
Before the Trusted Computing Group (TCG) introduced its Network Access Control (NAC) standard in 2007, available NAC technology was proprietary. In the last few years, a full suite of TCG NAC standards has been developed and compliant products have been introduced. Understanding these standards is essential to make informed decisions about NAC products from any vendor.
NAC Needs Standards
The simplest NAC process consists of the assessment of an endpoint, an evaluation to reach a decision, and enforcement that allows or blocks access. Other aspects may include remediation and ongoing monitoring. In addition, the assessment portion may include user authentication, endpoint authentication, extensive endpoint health checks, and/or ongoing monitoring of endpoint health.
Based on this process, NAC products have been available for two to three years. As a result, some IT departments have or are implementing NAC, while others are still in the evaluation phase or performing a pilot deployment. With these early deployments, the common requirements for NAC have started to emerge and include strong and effective security, powerful management tools, multi-vendor interoperability, scalability, gradual deployment, and more.
With any new product, making the right choice is always a concern. When the selection process impacts an organization as significantly as NAC, the right choice is critical. To simplify the decision process, standards provide flexibility, allow transitions to other suppliers and, in general, help avoid costly mistakes.
Developed by the Trusted Computing Group, Trusted Network Connect (TNC) is an open, vendor-neutral NAC architecture and set of standards. TNC provides the same sort of open security standards that other TCG specifications have afforded to computers and mobile phones. Since a variety of networking and security vendors worked to develop the TNC standards, the standards provide a reference architecture for NAC operation, the definition of architecture entities, and specifications for how these entities work together.
Even though the TNC standards were developed with broad industry support, they were not the only approach to NAC. However, on May 21, 2007, Microsoft and TCG announced the interoperability of Microsoft’s Network Access Protection (NAP) and products that support the TNC standards. As a result, two of the major NAC architectures have come together in a single interoperable community.
The latest TNC architecture specification (available along with all the other TNC specifications at https://www.trustedcomputinggroup.org/specs/TNC) defines an architecture common to NAP and other TNC-compatible NAC systems. Figure 1 shows the three entities in the TNC architecture: Access Requestor (AR), Policy Enforcement Point (PEP), and Policy Decision Point (PDP). Within each entity are components that perform specific functions. For example, the Integrity Measurement Collectors (IMCs) gather measurements of the Access Requestor’s health and the Integrity Measurement Verifiers (IMVs) verify those measurements against policy. These components communicate using standard interfaces, denoted in the figure with dotted lines.
Figure 1. Developed by TCG’s Trusted Network Connect (TNC) Work Group, the TNC architecture defines specific entities and interfaces (IFs) for NAC.
Microsoft’s NAP policy enforcement platform allows users to protect network assets by enforcing compliance with system health requirements. Figure 2 shows that Microsoft’s NAP architecture is a specific configuration of the TNC architecture. Unique entities in the architecture include the System Health Agent (SHA) and NAP Enforcement Client (EC). Since Microsoft contributed its SOH (Statement of Health) client-server protocol specification to TCG, now known as IF-TNCCS-SOH, it provides the basis for NAP-TNC interoperability. This convergence of key standards provides market stability and should ensure confidence for making NAC decisions today.
Figure 2. The Health Statements (IF-TNCCS-SOH) in Microsoft’s NAP architecture provide interoperability with TCG’s TNC.
Applying NAC Standards
The TNC layered architecture has three client-server protocols. At the lowest level, a transport protocol, IF-T, provides many options for transporting messages from the client to the server and back. IF-T can use a Secure Sockets Layer (SSL), Virtual Private Networks (VPNs) or an IPsec (Internet protocol security) VPN for remote access. The Extensible Authentication Protocol Over LAN (EAPOL) and Remote Authentication Dial-In User Service (RADIUS) standard protocols defined in IEEE 802.1X can be used as client-server transports for both wired and wireless networks.
At the top level, the IF-M protocol conveys measurements from the IMCs to the IMVs. Between these levels, the IF TNCCS protocol manages different phases of the health check and the overall health check status and parameters as well.
To communicate with the Policy Enforcement Point, the IF-PEP interface provides many options for enforcement: switches, wireless access points, routers, firewalls, VPN Gateways, and more. Since each enforcement option has its own pros and cons, using a standard protocol interface allows the choice of the right one for a specific application. For example, this allows a firewall to provide fine-grained access control for limited access to certain portions of the network or restricted bandwidth instead of making a simple yes or no access decision.
IF-IMC on the client and IF-IMV on the server side are extension points that allow the addition of plug-in modules that can add health checks to the system. For example, a customer or vendor can create a new IMC and IMV. The added IMC collects information about the client and an added IMV on the server side receives that information, evaluates it against policy, and makes a recommendation.
The IF-PTS extension point is optional but provides unique capability. This interface allows access to the Platform Trust Service (PTS) that includes the Trusted Platform Module (TPM) and the TPM Software Stack (TSS). One of the initial constructs based on TCG specifications, the TPM is a microcontroller that stores digital keys, passwords, and certificates. The TPM is an integral part of over 50 million corporate laptop and desktop computers. Its value to NAC is best demonstrated in an example, the lying endpoint problem.
In Network Access Control, if an endpoint becomes infected by a virus or other malware attack, the infection may cause the machine to lie about its health status creating a situation known as a lying endpoint. As a result, a lying endpoint can gain access to the network and infect other machines. Software can reduce the likelihood of access by a lying endpoint, but it cannot totally eliminate the problem because the software can be modified by malware.
A hardware security component such as the TPM can overcome the limitations of software-based approaches to lying endpoints. In addition to its use in disk encryption and strong authentication, in the TNC architecture, the TPM enables integrity measurement and remote attestation.
The TPM measures critical software and firmware on the computer during the computer’s boot sequence, before it is loaded, and stores the measurements in protected TPM memory. In this secure hardware location, the measurements cannot be modified. When the computer attempts to connect to the network, the Policy Decision Point securely interrogates the TPM, obtains the measurements, and passes them to the server side where they are checked against the server’s list of acceptable configurations. A non-match identifies an infected endpoint that can be quarantined. Without a TPM, endpoints can only be checked with the normal software techniques and cannot provide the same level of trust.
NAC’s Future Direction
Today’s TNC specifications allow customers to use an endpoint from one vendor with a NAC server from another vendor. With a commitment to interoperability, TCG will continue to promote the enhancement and adoption of the TNC specifications. The specifications will expand to include and standardize new features for NAC as they are defined, which should provide confidence to both network developers and enterprise network users.
Additional improvements to the specifications are already being considered. The interfaces created so far have addressed the most urgent needs for interoperability in NAC systems. A possible new interface would support and perform checks on non-responsive nodes that do not have any TNC software, such as a printer or other endpoint without NAC software. While individual NAC vendors have their own solution, a standard in this area would provide improved interoperability.
All of TCG’s existing TNC specifications can be found at https://www.trustedcomputinggroup.org/specs/TNC.
About the Author:
Steve Hanna, the Distinguished Engineer with Juniper Networks, is Co-Chair of Trusted Network Connect Work Group, Trusted Computing Group.
Go Back
|
