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.

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.

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 borrowing part of 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 but communicates with the IMCs and IMVs via 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.