12.4. Trusted Network Connect (TNC)
Trusted Network Connect (TNC) is a Work Group (WG) of the Trusted Computing Group (TCG), a not-for-profit organization established in 2003 with a charter to develop, define, and promote open standards for hardware-enabled trusted computing and security technologies across multiple platforms, peripherals, and devices. TNC is also an eponymous open standard and architecture for NAC and network security. Many members of the TCG actively participate in the definition and specification of the TNC's open NAC standards and architecture.
12.4.1. What is the TNC architecture?
TNC is an open, standards-based set of standards and architecture for device authentication and platform integrity measurement. Initially published in 2004, the TNC architecture serves as a framework for developing open-architected, standards-driven, interoperable NAC solutions. The TNC architecture and standards define open, standard interfaces that enable components from different vendors to securely interoperate to create a standards-based NAC solution that leverages existing installed equipment and operates across heterogeneous networks.
Identity and integrity are the core tenets of the TNC standards and architecture. Constructed on existing industry standards and protocols widely supported by networking equipment vendors (including 802.1X, RADIUS, IPSec, EAP, and TLS/SSL), TNC defines new open standards as needed to enable non-proprietary and interoperable solutions within multivendor environments.
The TGC has built the TNC architecture on top of a standard network access architecture, and TNC leverages many of the components of this architecture. The TNC architecture includes a client-side Access Requestor (AR); a server-side Policy Decision Point (PDP); and an enforcer for access control decisions, a Policy Enforcement Point (PEP). Figure 12-2 shows an example.
Figure 12.2. The Trusted Computing Group's (TCG) Trusted Network Connect (TNC) architecture.
The Access Requestor (AR), as its name suggests, is an element that requests network access. An Access Requestor can be a software client, hardware component, or other entity that initiates a network access request: An 802.1X client or supplicant, a VPN client, or even a Web browser that establishes SSL connectivity can serve as an Access Requestor in a TNC-based NAC solution.
Another component of basic network access architectures is the Policy Decision Point (PDP). The server-side PDP is Decision Control Central for network access. The PDP makes the determination, typically by using information supplied by or from the AR, whether an endpoint device gains admittance to a network. It can also decide the appropriate level of access that the endpoint device receives.
The TNC architecture also includes a Policy Enforcement Point (PEP). A PEP enables or restricts access to a network. It's the bouncer of the network access architecture, enforcing the network access decisions determined by the PDP. A network device or access appliance (such as a switch, wireless access point, firewall, or VPN concentrator) may serve as the PEP.
All three of these entities work and interface seamlessly with one another in the TNC architecture: The AR supplies the data to the PDP to make the access control decision, a decision which the PEP then enforces.
NOTE
The components and interfaces that comprise the TNC architecture aren't physical, like most of the parts of the Cisco NAC and Microsoft NAP frameworks. So, the TNC architecture's parts aren't particular or vendor-specific software, devices, or services. Instead, they're open guidelines and specifications published by the TCG — and it encourages the inclusion and interoperability of vendor-agnostic entities and components.
12.4.2. Integrity and identity
The TNC architecture is extensible. It expands on a standard, identity-based access control architecture by adding additional layers to accommodate endpoint device integrity, as well as posture assessment and checks; extends the reach of access control support deeper into the network by leveraging additional and existing network devices; and broadens the scope of entities that can request access.
Figure 12-3 shows a diagram the TNC architecture.
Figure 12.3. The Trusted Network Connect (TNC) architecture.
In the AR, the TNC architecture adds layers to pre-existing access control architectures:
Integrity Measurement Collectors (IMCs): Software components that measure and capture the state of security, anti-malware, and other applications, products, and services on an AR.
Third parties develop IMCs by using an open, published TNC specification, and IMCs can include collectors for any number of applications, products, and services — such as
Antivirus status
Firewall parameters
Application and/or operating system patch levels
Anti-malware application versions
Third-party applications, services, and other products may preload IMCs on an endpoint device. Multiple IMCs may coexist and interoperate on an AR.
TNC Client (TNCC): An element (software, hardware, or browser-based) that runs on or interfaces with an AR and amasses the state data that IMCs collect, assisting the Network Access Requestor (NAR) in communicating through the PEP to the PDP. The NAR may be
An 802.1X client or supplicant
A VPN client
A Web browser that initiates an SSL connection
The TNCC starts an endpoint integrity check on the endpoint integrity check on the endpoint client or device attempting to access the network.
The PEP remains constant as an access control enforcement point.
Integrity Measurement Verifiers (IMVs): The matched set to the IMCs; IMVs check and validate the integrity and state of the information supplied by the IMCs about the AR or device requesting access against the policies for a specific application, service, or product determined by the organization. An IMV corresponds to each IMC on the client.
Third parties develop IMVs, like IMCs, by using an open, published TNC specification. After the IMV checks integrity and state, it formulates an action recommendation, which it communicates to the TNC Server (TNCS).
TNC Server (TNCS): The conduit that provides the IMVs with the integrity and state data and measurements that the AR communicates. It also delivers and receives messages to and from the IMVs, including their action recommendations. The TNCS combines all the IMV action recommendations it receives into its own recommendation for action (which it bases on the baseline security and access control policies predetermined by an organization) and communicates the recommendation to the Network Access Authority (NAA).
Network Access Authority (NAA): Might be either part of or a complete AAA and/or RADIUS server; but it doesn't need to be. The NAA is the decision-maker with regard to network access; it determines whether the AR receives network access based on the information and recommendations that the TNCS provides it. The NAA works with the TNCS to determine whether the integrity and state measurements supplied by the AR and verified by the IMVs comply with the predefined security and access control policies of an organization. The NAA communicates the final action recommendation — whether it should grant the Access Requestor network access — to the switch, wireless access point, firewall, or other device that serves as the PEP for enforcement.
12.4.3. Open interfaces
The TNC architecture publishes a number of open specifications for communication interfaces between logical components of the TNC architecture. For example, interface specifications can specify standard methods for
Gathering device integrity, posture, and state measurements from IMCs (IF-IMC)
Delivering the gathered measurements to IMVs (IF-IMV)
Prescribing standards for messaging and communications between IMCs and IMVs (IF-M)
These specifications can also describe a standard for information exchange between the TNCC and TNCS (IF-TNCCS), as well as how the exchange should take place through tunneled EAP methods (IF-T). Finally, they can use RADIUS as a communications vehicle between an NAA — which may be a AAA and/or RADIUS server — and a PEP (IF-PEP).