Trusted Computing Group

Trusted Network Connect (TNC) is an open, non-proprietary specification that enables the application and enforcement of security requirements for endpoints connecting to the corporate network. The TNC architecture helps IT organizations enforce corporate configuration requirements and to prevent and detect malware outbreaks, as well as the resulting security breaches and downtime in multi-vendor networks.

The TNC architecture has been designed to assist network administrators in protecting networks by allowing them to audit endpoint configurations and impose enterprise security policies before network connectivity is established. This can help prevent inappropriate and unauthorized access that can result in viruses and email worms, Trojan horses, denial of service attacks, and other malicious activities.

First, the specification focuses on the collection of endpoint configuration data in conjunction with user authentication information, for comparison with a pre-defined set of organization criteria for access to the protected network. This creates a "security" or "safe computing" profile for a system. Second, the specification addresses providing an appropriate level of network access based on the detected level of policy compliance, including full access, partial access or directed access, or no access.

In 2006, the TNC made available three new specifications. These specifications are:

• IF-TNCCS, which specifies interoperability between the TNC Client (TNCC) and the TNC Server (TNCS);
• IF-T for Tunneled EAP Methods, which is the specification for support of various transports; and,
• IF-PEP for RADIUS, specifying a standard integration with Policy Enforcement Points (PEP).

These specifications are in addition to the existing TNC specifications - IF-IMC and IF-IMV, which provide standardized APIs for client plug-ins (IMCs) and server plug-ins (IMVs) to enable TNC functionality; and the TNC architecture specification - which were all published in May 2005. All TNC specifications are available free to anyone who wishes to download them from the TCG website, www.trustedcomputinggroup.org.

These specifications are intended to be used in the following manner:

• IF-TNCCS describes a standard method for the TNC Client (TNCC) and the TNC Server (TNCS) to exchange messages. Since the TNC architecture is layered, IF-TNCCS carries messages from IMCs to IMVs and vice versa. It also carries control messages between the TNCC and TNCS. IFTNCCS is transport-independent so it can be carried over a variety of transports.
• IF-T for Tunneled EAP Methods specifies how IF-TNCCS should be carried over Extensible Authentication Protocol (EAP) tunneled methods such as EAP-TTLS, EAP-FAST, and EAPPEAP.  Supporting these EAP methods allows the TNC architecture to work with a variety of network technologies that support EAP authentication: 802.1x, IKEv2, etc.
• IF-PEP for RADIUS specifies how to use the RADIUS protocol for communications between a Network Access Authority (NAA) - typically an AAA/RADIUS server - and a Policy Enforcement Point (PEP). IF-PEP is used to send network access decisions from the NAA to the PEP, enabling the PEP to enforce the access decisions on an endpoint's network traffic. The network access decision will trigger enforcement action by the PEP, such as allowing access, denying access, or granting limited access.

In February 2007, the TCG announced the release of updates to four existing specifications. The new specification names are IF-IMC 1.2, IF-IMV 1.2, IF-TNCCS 1.1, and IF-PEP for RADIUS 1.1. These updated specifications provide valuable enhancements to the original versions, adding features requested by customers and incorporating fixes in response to feedback from implementers.

The following new features are provided:

• Java Platform Binding to IF-IMC (integrity measurement collector) and IF-IMV (integrity measurement verifier)
• Support allowing each IMV to give a human-readable, localized reason string explaining itsrecommendation (in IF-IMV and IF-TNCCS)
• Support for VLAN-aware endpoints(in IF-PEP (policy enforcement point)

The main benefits of these features are:

• TNC client software can be deployed more quickly and easily since it can be dynamically downloaded over the network as Java code.
• TNC client and server software can be developed to run on any system that supports Java 2 Standard Edition version 1.4.2 or later.
• In case of problems, messages can be presented in the user's native language.
• Endpoints can employ multiple VLANs for applications like telephony.

The IF-TNCCS-SOH 1.0 protocol now is an open standard published by TCG (under the TCG royalty free cross-licensing model) and available for anyone to implement for free. It is implemented in Windows Vista and to be implemented in Windows XP and Windows "Longhorn". We believe it will become the prevalent method for network access control client-server protocols. SOH will enable any device to participate in a TNC or NAP network and have its health checked.

As a result of making SOH part of TNC, customers benefit in several ways:

• Interoperability: Customers can now be assured of interoperability between Microsoft NAP and other TNC implementations.
• Choice: Customers can now choose from any of the wide array of products that support Microsoft NAP and TCG TNC based on customer needs.
• Compatibility: Network access control products will now be much more compatible, allowing customers to interconnect a wide range of network, client, and server components.
• Clarification: Customers who have been waiting for consolidation and clarification in the confusing maze of network access control architectures and standards can now proceed with deployments of NAP and TNC products, confident that they will interoperate.
• Single Client Agent: Computers running Windows Vista, Windows Server "Longhorn", and future versions of Windows XP include the NAP Agent component as part of the core operating system. The NAP Agent will be used for both NAP and TNC, greatly simplifying deployment of a network access control solution. To support client operating systems other than Windows, Microsoft will license elements of the NAP client technology that support both NAP and TCG TNC to third-party software developers.

TNC is based on the twin concepts of integrity and identity. Integrity is used in this case to describe the desired state of an endpoint's "health" or configuration, as defined by IT policies. Examples might be to check if the system adheres to pre-determined policies and determine the system is not engaged in unusual or malicious behavior. Identity ensures that systems are authenticated for authorized users only; clients with the TPM offer additional security in that identity is established through hardware. The TPM also provides a trusted boot mechanism that uniquely helps thwart root kits, stealthy infections that are otherwise almost impossible to detect.

Another key attribute of TNC is its focus on heterogeneous networking environments, with products from a variety of vendors. TNC support will enhance many existing products. Users can benefit quickly because they can implement TNC within the infrastructure products and vendors already deployed on their networks. The architecture is based on existing, widely used standards such as EAP and TLS, and integrates with mature technologies such as IPsec and 802.1x.

The TNC architecture is constructed on top of traditional network access architecture - for instance, the switches in a wired LAN. A Network Access Requester (NAR) is client software on the endpoint that begins the network access attempt. 802.1x supplicants, VPN clients or Web browsers initiating SSL connections could all be NARs in a TNC environment.

The Policy Enforcement Point (PEP) - usually a network infrastructure device like a switch or a VPN concentrator - is configured to require 802.1X authentication, and forwards information about the NAR and its network connection attempt to a Policy Decision Point (PDP), where a Network Access Authority (NAA) determines whether the endpoint should be admitted to the network.

The TNC extends this standard architecture with two layers on the endpoint and two layers on the PDP. On the endpoint, a TNC Client gathers reports from Integrity Measurement Collectors (IMCs, plug-in modules that report on the endpoint's health). The TNC client delivers these reports ("integrity measurements"), using the 802.1X connection, to Integrity Measurement Verifiers (IMVs) on the PDP, which check the client state against integrity policies. A TNC Server on the PDP manages the integrity check handshake, delivering messages to and from the IMVs and combining the IMV's recommendations into a final access recommendation to the NAA.

TNC is an excellent application for the TPM in that it helps establish a link to a decision point where integrity reports may be evaluated. Use of the TPM by TNC is optional, but for platforms with a TPM, the convenient reporting infrastructure enables the TPM reports to be factored into network access control decisions. A system with the TPM can protect sensitive data such as encryption keys and collected measurements. The TPM safely stores those measurements in a protected location until ready for reporting. It can protect the measurements from man-in-the-middle attacks that might occur anytime thereafter. Products based on TNC architecture can operate in today's environments with and without TPMs, but if present, there is greater assurance that TNC integrity reports originated from the expected platform.

Companies currently providing compatible products include Extreme Networks, HP ProCurve, Juniper Networks, Q1 Labs, StillSecure, Wave Systems, General Dynamics and others.

The TNC architecture is differentiated from Cisco Network Admission Control (C-NAC) and Microsoft Network Access Protection (NAP) by the following key attributes and benefits:

• Supports multi-vendor interoperability
• Leverages existing standards
• Empowers enterprises with choice

Also, the TNC architecture provides organizations with a clear future path. Future integration with the TPM - the IF-PTS specification - enables a complete trusted network trail from the client straight through to the network. This level of future roadmap and integration with standards-based hardware security is not available with any other endpoint integrity/network access architecture. Microsoft is a TCG member and previously has announced the alignment of the NAP architecture with TNC and planned interoperability. There are also additional solutions available from other vendors which attempt to address endpoint integrity and access control in different, various ways. TCG welcomes participation and membership by any companies in the TNC effort and believes that interoperable approaches to network access control are in the best interests of customers and users.

Trusted Network Connect architecture uses existing industry standards, such as EAP, TLS, the 802.1x specification and others.

The architecture supports all commonly used enterprise access methods such as VPN-based or dialup remote access; wireless networks; 802.1x infrastructures; and traditional LAN technologies.

TCG is evaluating a compliance program.

This set of IWG specifications can be implemented without the presence of a TPM. The value of these IWG specifications is dramatically increased when the root of trust (of the platform deploying them) is based in hardware.

In the context of the TNC specifications, the Platform Trust Service (PTS) interface specification provides an agent that can be employed (called by) the TNC Client to perform measurements of the components of the TNC Client device, as well as other client components. Furthermore, the set of IWG Integrity Schema specifications provides a standardized format for TNC implementers and vendors to report on the integrity status of a target device (e.g. TNC client). This standardized format promotes greater interoperability across TNC vendors.