Wave Systems Corp. (fka WAVXQ)

[Foam]

TNC not yet a complete solution according to the following article:
The competition for NAC
Mapping Cisco, Juniper, Microsoft and TCG's access-control schemes.
http://www.networkworld.com/research/2006/040306-nac-overview.html?t5

Microsoft isn't the only vendor with a paucity of products. The TCG, a nonprofit industry-based standards organization comprising interested vendors, has been working on its Trusted Network Connect scheme since mid-2004 and still doesn't have a completed architecture.

The Trusted Network Connect framework includes six separate protocols to build a complete system, but only two of these have been fully defined, making it impossible to have a fully deployed Trusted Network Connect NAC network. TCG has promised the rest of the protocols any day now.

That said, the best starting point for evaluating NAC architecture is with the TCG's Trusted Network Connect, because its specifications are created in an open, vendor-neutral environment and can be used as a good model just to get the terminology straight.

Every proposed NAC strategy can be mapped to the Trusted Network Connect architecture, but that doesn't mean Trusted Network Connect is a superset of other products. Many NAC vendors add features not explicitly discussed by TCG, such as control of personal firewall or continuous rechecking of endpoint security. Other NAC vendors handle cases that are not discussed in the TCG architecture, such as how to provide access controls when the end system is a guest laptop and doesn't have all the necessary software installed.

The Trusted Network Connect architecture divides the NAC problem into three entities: the Access Requestor, the Policy Enforcement Point and the Policy Decision Point (see graphic "Walking through a generic NAC process").

TCG's Access Requestor is a combination of the entity trying to gain access to the network, such as a laptop or desktop computer, and the software and drivers that implement authentication and endpoint-security assessment processes. TCG divides the Access Requestor into three smaller pieces. At the bottom is a Network Access Requestor, software used by the client to connect to the network, request access and provide authentication. For example, an 802.1X supplicant or an IPSec VPN client could handle a network-access request.

Integrity Measurement Collectors, software components responsible for evaluating the security posture of the end system, are on top of the Network Access Requestor, still on the client system and part of the access. If your policy is defined such that everyone has to be running anti-virus software, then your anti-virus vendor would provide a plug-in that serves up status information on its software.

TCG divides this task into two pieces: the Integrity Measurement Collectors and the Trusted Network Connect client that collects information from the Integrity Measurement Collectors and helps package it up for policy evaluation.

The Trusted Network Connect NAC Policy Enforcement Point is exactly as it sounds: the point at which policy is enforced. TCG's NAC doesn't describe what kinds of policy-based enforcement mechanisms are available, probably to remain as vendor neutral as possible, though the architectural documents describe how quarantine and remediation might be part of policy enforcement.

The Trusted Network Connect NAC Policy Decision Point also is divided into three parts. The bottom piece, which is in charge of talking to the authentication server and communicating decisions to the Policy Enforcement Point, is the Network Access Authority. In a typical network, this would likely be an AAA (authentication, authorization and accounting) server.

Behind the Network Access Authority are Integrity Measurement Verifiers. These are the counterparts to the Integrity Measurement Collectors on the client. They receive the reports the Client Integrity Measurement collectors send and provide verification information back to the Network Access Authority. The verifiers and the collectors are a matched set. They can talk to each other through a tunnel provided by all the other pieces of the NAC architecture, using whatever proprietary vendor-specific protocol vendors want.

The Trusted Network Connect architecture layers a thin server piece, called the TNC server, in the Policy Decision Point that is the interface between the Integrity Measurement Verifiers and the Network Access Authority.

The Trusted Network Connect NAC architecture is designed to work within an existing 802.1X authentication and authorization system. If you rename the client-side network Access Requestor to "802.1X supplicant"; the Policy Enforcement Point to "802.1X-compatible switch or access point"; and the Network Access Authority Policy Decision Point to "802.1X RADIUS server", then the Trusted Network Connect NAC plan is bits of software that sit on top of an existing 802.1X deployment to add endpoint security assessment to the mix.

This becomes obvious if you look at the protocols the Trusted Network Connect chose to publish first. There are those that let the vendor-supplied integrity-measurement collectors talk to a vendor-neutral Trusted Network Connect client on the client system and those that let the vendor-supplied Integrity Measurement Verifier talk to the vendor-neutral Trusted Network Connect server on the Policy Decision Point end. As prototype implementations started showing up, Trusted Network Connect relied heavily on existing 802.1X mechanisms such as authentication and tunneling to get the other pieces to work, although none of this is laid out explicitly in the architecture documents.

Focusing on 802.1X does not mean that the Trusted Network Connect architecture won't support other kinds of Policy Enforcement Points, such as firewalls, VPN concentrators or core switches. But it does mean that anyone trying to go from architecture to implementation using the Trusted Network Connect documents will quickly find even more missing pieces, at least at this stage of the architecture. Important parts of the big picture, such as how the Trusted Network Connect client and server talk to the network access requestor and network access authority, aren't called out for future discussion - which means even when the architecture is completed as planned, it won't be fully complete.

While TCG's Trusted Network Connect architecture is a well-constructed way to think about NAC, refer to NAC components and compare NAC solutions, it doesn't yet represent an architecture that's complete enough to be used to begin implementation.