- Trusted Network Connect (TNC) HOWTO
- TNC Configuration
- TNC Integrity Measurement Collectors and Verifiers
- TNC Deployment
- Android BYOD Security based on the TNC framework
- Endpoint Compliance Profile
- Hardcopy Device Health Assessment
- Mutual Attestation of IoT Devices
- Software Inventory Message and Attributes for PA-TNC (SWIMA)
Trusted Network Connect (TNC) HOWTO¶
strongSwan supports both the older XML-based IF-TNCCS 1.1 "TNC Client-Server Interface" and the latest IF-TNCCS 2.0 "TLV Binding" but currently not the IF-TNCCS SoH 1.0 "State of Health Protocol Bindings" used by Microsoft's Network Access Protection (NAP) framework. The new strongSwan "Test" and "Scanner" IMC/IMV pairs support the IF-M 1.0 "TLV Binding" standard.
The TCG IF-M 1.0 protocol is equivalent to the IETF "Posture Attribute (PA) Protocol Compatible with Trusted Network Connect" (PA-TNC) defined by RFC 5792 and 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. Both RFCs are 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.
TNC Integrity Measurement Collectors and Verifiers¶
strongSwan can dynamically load any number of Integrity Measurement Collectors (IMCs) and Integrity Measurement Verifiers (IMVs) that already comply with the draft IF-IMC 1.3 and IF-IMV 1.3 interface specifications, respectively. These interfaces are implemented by the tnc-imc and tnc-imv plugins, respectively.
- Scanner IMC / IMV : Does a remote port scan and reports the results
- Test IMC / IMV : Tests the IF-TNCCS / IF-M protocols
The strongSwan IMC/IMV dynamic libraries can be used by any third party TNC Client/Server implementation possessing a standard IF-IMC/IMV interface and running under a Linux, Android, FreeBSD or Mac OS X operating system. The following HOWTO shows how to build the IMC/IMV libraries only, without the strongSwan IKE daemon.
- 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.
- 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.
- 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.
- IF-M 1.0 support was introduced in August 2011 with the strongSwan 4.5.3 release. The strongSwan "Test" and "Scanner" IMC/IMV pairs which communicate with each other via the IF-M TLV-based protocol can be used either in conjunction with a strongSwan TNC Client or TNC Server, respectively, or as stand-alone dynamic libraries imc-test.so, imc-scanner.so, imc-attestation.so, imv-test.so, imv-scanner.so, and imv-attestation.so with any third party TNC Client or TNC Server product having an IF-IMC or IF-IMV interface, respectively.
- IF-MAP 2.0 prototype support was introduced in November 2011 with the strongSwan 4.6.0 release. Using the tnc-ifmap plugin strongSwan acts as a MAP Client sending IPsec authentication metadata to a MAP Server via an Apache Axis2/C SOAP interface. For details see our TNC IF-MAP HOWTO.
- Support of the TCG Attestation PTS Protocol: Binding to IF-M was introduced in February 2012 with the strongSwan 4.6.2 release and was developed by HSR master student Sansar Choinyambuu. Using the Attestation PTS-IMC / Attestation PTS-IMV pair, file and TPM-based functional component measurements can be executed remotely.
- Example 4: TNC Client with PTS-IMC - TNC Server with PTS-IMV.
The IF-IMC interface of the strongSwan 4.5.2 TNC Client (TNCC) and the IF-IMV interface of the strongSwan 4.5.2 TNC Server (TNCS) were successfully certified by the Trusted Computing Group (TCG). We also participated in the May 2011 Plugfest in Chantilly, Virginia, USA, where we tested IF-PEP interoperability.
Android BYOD Security based on the TNC framework¶
The following link gives an overview of the BYOD security features of our Android VPN client.
Endpoint Compliance Profile¶
- The following scenario shows SWID tag requests via the PT-TLS transport protocol.
- An alternative scenario shows SWID tag requests via the PT-EAP transport protocol.
- The strongSwan SWID IMC uses the open source swidGenerator python script to generate ISO/IEC 19770-2:2014 Software Identification Tags für all software packages managed by dpkg (which used e.g. by the Debian and Ubuntu Linux distributions) or yum (which is used by the RedHat and Fedora Linux distributions). A detailed HOWTO explaining the installation and use of the swid_generator function can be found here.
Hardcopy Device Health Assessment¶
- HCD-IMC - Hardcopy Device Integrity Measurement Collector
- HCD-IMV - Hardcopy Device Integrity Measurement Verifier
- HCD-EAP scenario
Mutual Attestation of IoT Devices¶
If the mutual attestation via PT-EAP over IKEv2 is successful, an IPsec transport mode connection is set up between the two Raspberry Pi 2 IoT devices. Both Raspberry Pi platforms are equipped with an Infineon TPM 1.2 I2C daughterboard.
Mutual attestation demo at CeBIT 2016 using Raspberry Pi 2 hardware.
Details of the Raspberry Pi 2 hardware mounted on the back of the 7" touch screen.
Software Inventory Message and Attributes for PA-TNC (SWIMA)¶
- Based on draft-ietf-sacm-nea-swima-patnc
- SWIMA via PT-TLS transport
- Connect Security World September 2016 Marseille: Mutual Attestation of IoT Devices
- TCG Members Meeting June 2016 Vienna: Mutual Attestation of IoT Devices and TPM 2.0 Support.
- CeBIT 2016 Hannover: Mutual Attestation of IoT Devices via strongSwan VPN.
- TCG Members Meeting June 2015 Edinburgh: Mutual Attestation of IoT Devices.
- TCG Demo at RSA Conference 2015 San Francisco: Securing IoT with Trusted Computing
- TCG Members Meeting June 2014 Barcelona: TNC Endpoint Compliance and Network Access Control Profiles.
- Trusted Computing Conference September 2013 Orlando: Android BYOD Security using Trusted Network Control Protocol Suite.
- TCG Members Meeting June 2013 Dublin: strongSwan TNC Activities Update.
- Linux Security Summit August 30 2012 San Diego: The Linux Integrity Subsystem and TPM-based Network Endpoint Assessment.
- TCG Members Meeting June 2011 Munich: The strongSwan IPsec Solution with TNC Support.