Bolting the Back Door with NAC (cont'd) TNC
Part 3: page four
by Lisa Phifer
VP Core Competence, Inc.
[June 22, 2007]
TCG Trusted Network Connect
The Trusted Computing Group (TCG) develops open standards for hardware-enabled trusted computing and security technologies. TNC is TCG-defined open architecture to enable non-proprietary, interoperable endpoint security auditing and policy enforcement in multi-vendor networks.
The TNC architecture is reminiscent of both CNAC and NAP. At left is a host requesting access; at right are servers that make policy decisions. In between lay the APs, switches, firewalls, and VPN gateways that enforce policy. So what makes TNC different?
Unlike CNAC and NAP, every component of the TNC architecture could be sourced from a different vendor. For example, any mixture of TNC Policy Enforcement Points from Nortel, HP, Extreme, Enterasys, Aruba, Trapeze, Colubris, et al could request access through any TNC-compliant Network Access Authority, from Steel-Belted RADIUS to FreeRADIUS. An open source Linux TNC Client could interact with a Juniper IC 4000 TNC Server appliance. And so on.
To achieve multi-vendor interoperability, TNC functionality is carved into discrete Network Access, Integrity Evaluation, and Integrity Measurement layers. Those layers are implemented by components communicating through open standard interfaces:
IF-PEP: RADIUS bindings that enable communication between heterogeneous Policy Enforcement Points (PEPs) and Policy Decision Points (PDPs).
IF-T: Tunneled EAP bindings relay identity and integrity data between multi-vendor Network Access Requestors (NARs) and Network Access Authorities (NAAs), using access methods like 802.1X, IKE, TLS, or PPP.
IF-TNCCS: Protocols that carry integrity measurement handshakes between TNC-compliant Clients and Servers. Two protocols are now specified: the original XML-based IF-TNCCS and the new TLV-based IF-TNCCS-SOH recently adopted from NAP. TNC PDPs can implement one or both protocols.
IF-IMC: An API that all endpoint security programs—called Integrity Measurement Collectors (IMCs)—use to submit integrity data to the TNC Client.
IF-IMV: An API that all security policy servers—called Integrity Measurement Verifiers (IMVs)—use to receive integrity data from the TNC Server. Both APIs define language bindings for Java, UNIX/Linux, and Windows platforms.
IF-M: Vendor-specific IMC-IMV protocols. Today's IMCs and IMVs are matched pairs that exchange proprietary messages. For example, the Wave Embassy Endpoint Enforcer Client talks to the Wave Embassy Endpoint Enforcer Server, and the PatchLink Update Agent talks to the PatchLink Update Server.
Another core feature that differentiates TNC is optional use of a TCG Trusted Platform Module (TPM). TPM is a hardware security component found on many new laptops. It delivers platform trust services like identity and encryption key storage that make it harder for rootkit-infested endpoints to "lie" about their identity or integrity.
Heterogeneity on paper is one thing, but real-world deployments need interoperable products. Colubris, Enterasys, Fujitsu, HP, Juniper Networks, libTNC, PatchLink, Q1 Labs, Symantec, Trapeze Networks, and Wave Systems participated in an interoperability "plugfest" in March 2007. Those companies were joined by Extreme Networks, Fujitsu, FHH, Microsoft, and Nortel at a May 2007 Interop demo. According to TCG, about 75 member companies are developing TNC-compatible products or technology, including open source TNC Clients and Servers like libTNC, FHH@TNC, and OpenSEA.
TCG expects TNC/NAP interoperability to accelerate adoption by simplifying deployment and protecting investment. For example, in 1H08, not only will Microsoft Vista and Server 2008 speak IF-TNCCS-SOH, but so will TNC-based Juniper Networks Unified Access Control (UAC) products. Vendors at the top of the stack can then use either TNC or NAP APIs, knowing that customers will be able to combine NAP clients with TNC servers and vice versa when both speak the same protocol.
