Trusted Network Connect (TNC) HOWTO¶

The Trusted Computing Group (TCG) has defined and released an open architecture and a growing set of standards for endpoint integrity called Trusted Network Connect.

• Table of contents
• Trusted Network Connect (TNC) HOWTO
  • Architecture
  • Configuration
  • Deployment
  • Presentations

Architecture¶

strongSwan supports both the older XML-based IF-TNCCS 1.1 "TNC Client-Server Interface" and the latest IF-TNCCS-2.0 "TLV Bindings" but currently not the IF-TNCCS SoH 1.0 "State of Health Protocol Bindings" used by Microsoft's Network Access Protection (NAP) framework.

The TCG IF-TNCCS 2.0 protocol is equivalent to the IETF "Posture Broker (PB) Protocol Compatible with Trusted Network Connect" (PB-TNC) defined by RFC 5793 which is part of the IETF's "Network Endpoint Assessment" (NEA) framework defined by RFC 5209.

As a transport protocol to exchange IF-TNCCS 1.1 or IF-TNCCS 2.0 messages between TNC Client and TNC Server, strongSwan uses the EAP-TNC method defined by IF-T "Protocol Bindings for Tunneled EAP Methods 1.1". EAP-TNC as an inner non-secure protocol is then encapsulated in an outer encrypted and authenticated IKEv2-EAP-TTLS tunnel.

Configuration¶

By activating the appropriate plugins, a strongSwan VPN Client can act as a TNC Client and a strongSwan VPN Gateway can take on either the role of a "Policy Enforcement Point" (PEP) only which forwards all EAP-TTLS packets via EAP-RADIUS to an external AAA-Server or alternatively can additionally act as a TNC Server.

• Configuration as a TNC Client

• Configuration as a TNC Server

• Configuration as a PEP with EAP-RADIUS Interface

strongSwan can dynamically load any number of Integrity Measurement Collectors (IMCs) and Integrity Measurement Verifiers (IMVs) that adhere to the IF-IMC 1.2 and IF-IMV 1.2 interface specifications, respectively. These interfaces are implemented by the tnc-imc and tnc-imv plugins, respectively.

Deployment¶

• IF-TNCCS 1.1 support was first introduced in October 2010 with the strongSwan 4.5.0 release. The tnccs-11 charon plugin originally used Mike McCauley's libtnc library but the code was refactored with the strongSwan 4.5.1 release to use the tnc-imc and tnc-imv plugins and now implements the IF-TNCCS 1.1 protocol directly by including Mike McCauley's libxml statements.
  A strongSwan VPN Gateway configured as a PEP can connect to a FreeRADIUS server running the TNC@FHH plugin.

  - Example 1a: TNC Client - TNC Server with password-based EAP-MD5 client authentication
  - Example 1b: TNC Client - PEP - FreeRADIUS

• IF-TNCCS 2.0 support was introduced in February 2011 with the strongSwan 4.5.1 release. The tnccs-20 charon plugin was implemented by HSR master student Sansar Choinyambuu and does not make use of the libtnc library at all. Communication with IMCs and IMVs is handled by the tnc-imc or tnc-imv plugin, respectively.

  - Example 2a: TNC Client - TNC Server with password-based EAP-MD5 client authentication
  - Example 2b: TNC Client - TNC Server with certificate-based EAP-TLS client authentication

• Using the tnccs-dynamic plugin, a strongSwan VPN gateway can act as a TNC Server handling both the IF-TNCCS 1.1 and IF-TNCCS 2.0 protocols by dynamically detecting the protocol version chosen by the TNC Client.

  - Example 3: TNC Client - TNC Server with dynamic IF-TNCCS 1.1/2.0 protocol detection.

Presentations¶

• TCG Members Meeting June 2011 Munich: The strongSwan IPsec Solution with TNC Support.