TNC Server

Installation

In order to run a TNC server communicating via PT-EAP, in addition to the standard strongSwan VPN configuration the following ./configure options have to be enabled

--enable-eap-identity --enable-eap-ttls --enable-eap-tnc --enable-tnccs-20 --enable-tnc-imv --enable-sqlite

If client authentication is based on passwords instead of X.509 certificates, additionally either the EAP-MD5 or EAP-MSCHAPv2 methods have to be enabled with --enable-eap-md5 or --enable-eap-mschapv2, respectively.

Configuration

In the strongswan.conf configuration file a couple of important parameters have to been set:

charon {
  plugins {
    eap-ttls {
      max_message_count = 0
      # enable for certificate-based client authentication
      request_peer_auth = yes
      phase2_piggyback = yes
      phase2_method = md5
      phase2_tnc = yes
    }
    eap-tnc {
      max_message_count = 0
    }
    tnccs-20 {
      max_batch_size   = 32754
      max_message_size = 32722
    }
  }
}

Message Size Restrictions

Since often quite a lot of messages are exchanged via the PT-EAP transport protocol protected by EAP-TTLS, the default upper limit set by the max_message_count parameter of the eap-tnc and eap-ttls plugins have to be disabled in order not to disrupt the communication.

It is also recommended to set the maximum PB-TNC batch size and the maximum PA-TNC message size possible with PT-EAP transport to the optimum values defined above.

Choice of EAP Authentication Method

If the EAP authentication is going to be based on X.509 client certificates then

request_peer_auth = yes

must be set in the eap-ttls plugin subsection. Otherwise a PSK-based authentication takes place within the established EAP-TTLS tunnel with the EAP method defined by

phase2_method = md5

or alternatively

phase2_method = mschapv2

TNC measurements transported via PT-EAP protected by the EAP-TTLS tunnel are activated by

phase2_tnc = yes

Initialization of TNC Database

In order for TNC measurements to be initiated and the ensuing TNC measurements to be stored, the location of the TNC database and the path to the IMV policy manager have to be configured in the libimcv section of strongswan.conf

libimcv {
  database = sqlite:///etc/pts/config.db
  policy_script = /usr/libexec/ipsec/imv_policy_manager
}

The TNC database is inititated with a strongSwan template in the following way

$ sudo -s
# mkdir /etc/pts
# cd /usr/share/strongswan/templates/database/imv
# cat tables.sql data.sql | sqlite3 /etc/pts/config.db

This means that the sqlite3 command must be available on the TNC server platform.

Restriction of TLS Cipher Suites

It is possible to restrict the TLS cipher suites accepted by the server in a libtls section of strongswan.conf

libtls
{
  suites = TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
}

TNC Client >

Integrity Measurement Verifiers

Any number of Integrity Measurement Verifiers (IMVs) can be attached to a TNC Server. An IMV is a dynamic library which communicates with the TNC Server via the TNC IF-IMV API defined in the form of a C header file. The /etc/tnc_config file tells the TNC Server which IMVs are to be loaded:

#IMV-Configuration

IMV "OS"             /usr/lib/ipsec/imcvs/imv-os.so
IMV "Scanner"        /usr/lib/ipsec/imcvs/imv-scanner.so
# IMV "SWIMA"        /usr/lib/ipsec/imcvs/imv-swima.so
# IMV "Attestation"  /usr/lib/ipsec/imcvs/imv-attestation.so

In the configuration file above, the OS IMV and the Scanner IMV are enabled, so that these Integrity Measurement Verifiers have to be built beforehand with the ./configure options

--enable-imv-os --enable-imv-scanner

When the charon daemon starts up, the IMVs are loaded. In our example the IMV 1 OS and IMV 2 Scanner are enabled which subcribe to the standard PA-TNC message subtypes Operating System and Firewall defined in the IETF namespace, respectively.

00[DMN] Starting IKE charon daemon (strongSwan 5.9.7, Linux 5.13.0-35-generic, x86_64)
00[TNC] TNC recommendation policy is 'default'
00[TNC] loading IMVs from '/etc/tnc_config'
00[TNC] added IETF attributes
00[TNC] added ITA-HSR attributes
00[TNC] added PWG attributes
00[TNC] added TCG attributes
00[LIB] libimcv initialized
00[IMV] IMV 1 "OS" initialized
00[TNC] IMV 1 supports 1 message type: 'IETF/Operating System' 0x000000/0x00000001
00[TNC] IMV 1 "OS" loaded from '/usr/lib/ipsec/imcvs/imv-os.so'
00[IMV] IMV 2 "Scanner" initialized
00[TNC] IMV 2 supports 1 message type: 'IETF/Firewall' 0x000000/0x00000005
00[TNC] IMV 2 "Scanner" loaded from '/usr/lib/ipsec/imcvs/imv-scanner.so'

TNC Client >

TNC-Enabled VPN Server Configuration

After charon has loaded all its plugins and spawned 16 worker threads, the swanctl start scripts load the credentials, the connection configurations and the pool definitions.

00[LIB] loaded plugins: charon random nonce x509 constraints pubkey pem openssl sqlite kernel-netlink resolve socket-default vici updown eap-identity eap-md5 eap-ttls eap-tnc tnc-imv tnc-tnccs tnccs-20
00[JOB] spawning 16 worker threads

00[DMN] executing start script 'creds' (swanctl --load-creds)
01[CFG] loaded certificate 'C=CH, O=Cyber, CN=server.strongswan.org'
08[CFG] loaded certificate 'C=CH, O=Cyber, CN=Cyber Root CA'
12[CFG] loaded ECDSA private key
16[CFG] loaded EAP shared key with id 'eap-jane' for: 'jane'
09[CFG] loaded EAP shared key with id 'eap-hacker' for: 'hacker'
00[DMN] creds: loaded certificate from '/etc/swanctl/x509/serverCert.pem'
00[DMN] creds: loaded certificate from '/etc/swanctl/x509ca/caCert.pem'
00[DMN] creds: loaded ECDSA key from '/etc/swanctl/ecdsa/serverKey.pem'
00[DMN] creds: loaded eap secret 'eap-jane'
00[DMN] creds: loaded eap secret 'eap-hacker'

00[DMN] executing start script 'conns' (swanctl --load-conns)
07[CFG] added vici connection: tnc
00[DMN] conns: loaded connection 'tnc'
00[DMN] conns: successfully loaded 1 connections, 0 unloaded

00[DMN] executing start script 'pools' (swanctl --load-pools)
08[CFG] added vici pool rw_pool: 10.3.0.0, 254 entries
00[DMN] pools: loaded pool 'rw_pool'
00[DMN] pools: successfully loaded 1 pools, 0 unloaded

The TNC-enabled VPN server configuration is based on the following swanctl.conf file

connections {
  tnc {
    pools = rw_pool

    local {
      auth = eap-ttls
      certs = serverCert.pem
      id = server.strongswan.org
    }
    remote {
      auth = eap-ttls
      eap_id = %any
    }
    children {
      tnc {
        local_ts = 10.1.0.0/24,192.168.0.2
        esp_proposals = aes256gcm128-chacha20poly1305-x25519
       }
    }
    version = 2
    proposals = aes256-sha256-x25519
    send_certreq = no
  }
}

pools {
  rw_pool {
    addrs = 10.3.0.0/24
  }
}

secrets {
  eap-jane {
    id = jane
    secret = 3s9RFGdWE5EW
  }
  eap-hacker {
    id = hacker
    secret = K8FW9/N0VIAJ
  }
}

The swanctl --list-conns shows the loaded VPN connection definition

swanctl --list-conns
tnc: IKEv2, no reauthentication, rekeying every 14400s
  local:  %any
  remote: %any
  local EAP_TTLS authentication:
    id: server.strongswan.org
    certs: C=CH, O=Cyber, CN=server.strongswan.org
  remote EAP_TTLS authentication:
    eap_id: %any
  tnc: TUNNEL, rekeying every 3600s
    local:  10.1.0.0/24 192.168.0.2/32
    remote: dynamic

TNC Client >

Certificate-Based EAP Client Authentication

Before the VPN server was started, the option

charon.plugins.eap-ttls.request_peer_auth = yes

was set in strongswan.conf.

IKEv2 Connection Setup

The VPN server receives an IKE_SA_INIT request from the VPN client with IP address 192.168.0.3 and answers with an IKE_SA_INIT response

12[NET] received packet: from 192.168.0.3[500] to 192.168.0.2[500] (240 bytes)
12[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
12[IKE] 192.168.0.3 is initiating an IKE_SA
12[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
12[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
12[NET] sending packet: from 192.168.0.2[500] to 192.168.0.3[500] (248 bytes)

The VPN server receives the IKE_AUTH request without an AUTH payload from the VPN client. Therefore the VPN server switches to EAP-based authentication and at the outset requests an EAP Identity from the client. Due to the EAP-only mode (proposed by the VPN client via the EAP_ONLY notify), the server doesn’t include an AUTH payload in its first IKE_AUTH response, either.

14[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (272 bytes)
14[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
14[CFG] looking for peer configs matching 192.168.0.2[server.strongswan.org]...192.168.0.3[192.168.0.3]
14[CFG] selected peer config 'tnc'
14[IKE] initiating EAP_IDENTITY method (id 0x00)
14[IKE] peer supports MOBIKE
14[ENC] generating IKE_AUTH response 1 [ IDr EAP/REQ/ID ]
14[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (112 bytes)

The VPN server receives the VPN client’s EAP Identity client.strongswan.org and then requests the initiation of the EAP-TTLS method

16[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (96 bytes)
16[ENC] parsed IKE_AUTH request 2 [ EAP/RES/ID ]
16[IKE] received EAP identity 'client.strongswan.org'
16[IKE] initiating EAP_TTLS method (id 0x45)
16[ENC] generating IKE_AUTH response 2 [ EAP/REQ/TTLS ]
16[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)

TNC Client >

EAP-TTLS Tunnel Setup

The VPN server receives the first EAP-TTLS response which contains a Client Hello message starting the TLS handshake. The negotiated TLS 1.2 cipher suite is TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. The server then sends its TLS server certificate and client certificate request

05[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (272 bytes)
05[ENC] parsed IKE_AUTH request 3 [ EAP/RES/TTLS ]
05[TLS] using key of type ECDSA
05[TLS] negotiated TLS 1.2 using suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
05[TLS] sending TLS server certificate 'C=CH, O=Cyber, CN=server.strongswan.org'
05[ENC] generating IKE_AUTH response 3 [ EAP/REQ/TTLS ]
05[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (928 bytes)

The TLS server receives the TLS client certificate. The EAP-TTLS tunnel on top of IKEv2 EAP has been successfully established. Within the tunnel the client’s EAP Identity is requested again

01[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (880 bytes)
01[ENC] parsed IKE_AUTH request 4 [ EAP/RES/TTLS ]
01[TLS] received TLS peer certificate 'C=CH, O=Cyber, CN=client.strongswan.org'
01[CFG]   using certificate "C=CH, O=Cyber, CN=client.strongswan.org"
01[CFG]   using trusted ca certificate "C=CH, O=Cyber, CN=Cyber Root CA"
01[CFG]   reached self-signed root ca with a path length of 0
01[IKE] sending tunneled EAP-TTLS AVP [EAP/REQ/ID]
01[ENC] generating IKE_AUTH response 4 [ EAP/REQ/TTLS ]
01[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (176 bytes)

The VPN server receives again the client’s EAP Identity client.strongswan.org and then starts the PT-EAP transport protocol within the EAP-TTLS tunnel

06[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (144 bytes)
06[ENC] parsed IKE_AUTH request 5 [ EAP/RES/TTLS ]
06[IKE] received tunneled EAP-TTLS AVP [EAP/RES/ID]
06[IKE] received EAP identity 'client.strongswan.org'
06[IKE] phase2 method EAP_PT_EAP selected
06[IKE] sending tunneled EAP-TTLS AVP [EAP/REQ/PT]
06[ENC] generating IKE_AUTH response 5 [ EAP/REQ/TTLS ]
06[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (128 bytes)

TNC Client >

PB-TNC Connection 1

The TNC server receives the first PB-TNC Client Data batch and assigns the PB-TNC (TCG TNC IF-TNCCS) Connection ID 1 to the connection and also creates a new state for both the OS IMV and the Scanner IMV. The OS IMV gets the Access requestor’s identities client.strongswan.org and 192.168.0.3 from the TNC server via the TNC IF-IMV API.

09[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (448 bytes)
09[ENC] parsed IKE_AUTH request 6 [ EAP/RES/TTLS ]
09[IKE] received tunneled EAP-TTLS AVP [EAP/RES/PT]
09[TNC] assigned TNCCS Connection ID 1
09[IMV] IMV 1 "OS" created a state for IF-TNCCS 2.0 Connection ID 1: +long +excl -soh
09[IMV]   over IF-T for Tunneled EAP 2.0 with maximum PA-TNC message size of 32722 bytes
09[IMV]   user AR identity 'client.strongswan.org' of type username authenticated by certificate
09[IMV]   machine AR identity '192.168.0.3' of type IPv4 address authenticated by unknown method
09[IMV] IMV 2 "Scanner" created a state for IF-TNCCS 2.0 Connection ID 1: +long +excl -soh
09[IMV]   over IF-T for Tunneled EAP 2.0 with maximum PA-TNC message size of 32722 bytes
09[IMV] IMV 1 "OS" changed state of Connection ID 1 to 'Handshake'
09[IMV] IMV 2 "Scanner" changed state of Connection ID 1 to 'Handshake'

TNC Client >

TNC Measurements

The TNC server receives a PB-TNC Client Data batch containing a standard PB-Language-Preference message which sets the preferred language to English [en] and two PA-TNC messages

09[TNC] received TNCCS batch (321 bytes)
09[TNC] TNC server is handling inbound connection
09[TNC] processing PB-TNC CDATA batch for Connection ID 1
09[TNC] PB-TNC state transition from 'Init' to 'Server Working'
09[TNC] processing IETF/PB-Language-Preference message (31 bytes)
09[TNC] processing IETF/PB-PA message (222 bytes)
09[TNC] processing IETF/PB-PA message (60 bytes)
09[TNC] setting language preference to 'en'

The first PA-TNC message is of standard subtype Operating System containing seven PA-TNC attributes is processed by the OS IMV. The most important attribute is the Device ID defined in the ITA-HSR namespace, since it uniquely identfies the endpoint to be measured

09[TNC] handling PB-PA message type 'IETF/Operating System' 0x000000/0x00000001
09[IMV] IMV 1 "OS" received message for Connection ID 1 from IMC 1
09[TNC] processing PA-TNC message with ID 0x0f74f43f
09[TNC] processing PA-TNC attribute type 'IETF/Product Information' 0x000000/0x00000002
09[TNC] processing PA-TNC attribute type 'IETF/String Version' 0x000000/0x00000004
09[TNC] processing PA-TNC attribute type 'IETF/Numeric Version' 0x000000/0x00000003
09[TNC] processing PA-TNC attribute type 'IETF/Operational Status' 0x000000/0x00000005
09[TNC] processing PA-TNC attribute type 'IETF/Forwarding Enabled' 0x000000/0x0000000b
09[TNC] processing PA-TNC attribute type 'IETF/Factory Default Password Enabled' 0x000000/0x0000000c
09[TNC] processing PA-TNC attribute type 'ITA-HSR/Device ID' 0x00902a/0x00000008
09[IMV] operating system name is 'Ubuntu' from vendor Canonical
09[IMV] operating system version is '20.04 x86_64'
09[IMV] operating system numeric version is 20.4
09[IMV] operational status: operational, result: successful
09[IMV] last boot: Mar 28 07:42:58 UTC 2022
09[IMV] IPv4 forwarding is enabled
09[IMV] factory default password is disabled
09[IMV] device ID is a488651e36664792b306cf8be72dd630

The second PA-TNC message is of standard subtype Firewall and contains the standard PA-TNC attribute Port Filter which will be analyzed later on

09[TNC] handling PB-PA message type 'IETF/Firewall' 0x000000/0x00000005
09[IMV] IMV 2 "Scanner" received message for Connection ID 1 from IMC 2
09[TNC] processing PA-TNC message with ID 0x0dc7be19
09[TNC] processing PA-TNC attribute type 'IETF/Port Filter' 0x000000/0x00000006

The TNC server creates a PA-TNC attribute of type Segmentation Contract Request defined in the TCG namespace which proposes to split up huge PA-TNC messages into segments with a maximum size of 32'698 bytes each (see PA-TNC message segmentation)

09[IMV] IMV 1 requests a segmentation contract for PA message type 'IETF/Operating System' 0x000000/0x00000001
09[IMV]   no message size limit, maximum segment size of 32698 bytes

The imc_policy_manager program is executed which connects to the TNC database and assigns the session number 1 to the current connection 1. The following measurement workitems are configured in the database:

  • PGKCS - Installed Packages

  • TCPOP - Open TCP Ports

  • UDPOP - Open UDP Ports

09[IMV] assigned session ID 1 to Connection ID 1
09[IMV] policy: imv_policy_manager start successful
09[IMV] PCKGS workitem 1
09[IMV] TCPOP workitem 2
09[IMV] UDPOP workitem 3

The PKCGS workitem is handled by the OS IMV which adds a request for a standard Installed Packages PA-TNC attribute to a standard PA-TNC Attribute Request attribute. Together with the Segmentation Contract Request mentioned above, the Attribute Request is inserted into a PA-TNC message of standard subtype Operating System

09[TNC]   0x000000/0x00000007 'IETF/Installed Packages'
09[IMV] IMV 1 handles PCKGS workitem 1
09[TNC] creating PA-TNC message with ID 0xc084b149
09[TNC] creating PA-TNC attribute type 'TCG/Segmentation Contract Request' 0x005597/0x00000021
09[TNC] creating PA-TNC attribute type 'IETF/Attribute Request' 0x000000/0x00000001
09[TNC] creating PB-PA message type 'IETF/Operating System' 0x000000/0x00000001

The TCPOP and UDPOP workitems are handled by the Scanner IMV which compares the list of open TCP and UDP ports contained in the received Port Filter attribute with the allowed ports configured in the TNC policy database . Since TCP port 38953 is not allowed to be open, the value non-compliant minor is assigned to the standard PA-TNC attribute Assessment Result and the recommendation on behalf of the TNC server is set to Access Denied.

09[IMV] IMV 2 handles TCPOP workitem 2
09[IMV] IMV 2 handles UDPOP workitem 3
09[IMV] list of tcp ports that are allowed to be open:
09[IMV] tcp port 38953 open: fatal
09[IMV] IMV 2 handled TCPOP workitem 2: no access - violating tcp ports: 38953
09[IMV] list of udp ports that are allowed to be open:
09[IMV]   500 -   500
09[IMV]  4500 -  4500
09[IMV] 10000 - 65000
09[IMV] udp port  4500 open: ok
09[IMV] udp port 47753 open: ok
09[IMV] udp port   500 open: ok
09[IMV] IMV 2 handled UDPOP workitem 3: allow - no violating udp ports
09[TNC] creating PA-TNC message with ID 0x26d87477
09[TNC] creating PA-TNC attribute type 'IETF/Assessment Result' 0x000000/0x00000009
09[TNC] creating PA-TNC attribute type 'IETF/Remediation Instructions' 0x000000/0x0000000a
09[TNC] creating PB-PA message type 'IETF/Firewall' 0x000000/0x00000005
09[TNC] IMV 2 is setting reason string to 'Open server ports were detected'
09[TNC] IMV 2 is setting reason language to 'en'
09[TNC] IMV 2 provides recommendation 'no access' and evaluation 'non-compliant minor'

The TNC server is sending the two PA-TNC messages in a PB-TNC Server Data batch to the TNC client.

09[TNC] TNC server is handling outbound connection
09[TNC] PB-TNC state transition from 'Server Working' to 'Client Working'
09[TNC] creating PB-TNC SDATA batch
09[TNC] adding IETF/PB-PA message
09[TNC] adding IETF/PB-PA message
09[TNC] sending PB-TNC SDATA batch (512 bytes) for Connection ID 1
09[IKE] sending tunneled EAP-TTLS AVP [EAP/REQ/PT]
09[ENC] generating IKE_AUTH response 6 [ EAP/REQ/TTLS ]
09[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (640 bytes)

The next PB-TNC Client Data batch sent by the TNC client has a large size of 2845 bytes and is therefore split into three consecutive EAP-TTLS segments

07[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (1104 bytes)
07[ENC] parsed IKE_AUTH request 7 [ EAP/RES/TTLS ]
07[ENC] generating IKE_AUTH response 7 [ EAP/REQ/TTLS ]
07[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
08[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (1104 bytes)
08[ENC] parsed IKE_AUTH request 8 [ EAP/RES/TTLS ]
08[ENC] generating IKE_AUTH response 8 [ EAP/REQ/TTLS ]
08[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
10[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (944 bytes)
10[ENC] parsed IKE_AUTH request 9 [ EAP/RES/TTLS ]
10[IKE] received tunneled EAP-TTLS AVP [EAP/RES/PT]
10[TNC] received TNCCS batch (2845 bytes)
10[TNC] TNC server is handling inbound connection
10[TNC] processing PB-TNC CDATA batch for Connection ID 1
10[TNC] PB-TNC state transition from 'Client Working' to 'Server Working'

The PB-TNC Client Data batch carries a PA-TNC message of standard subtype Operating System containing the PA-TNC attribute Segmentation Contract Response defined in the TCG namespace and the standard PA-TNC attribute Installed Packages both of which are handled by the OS IMC

10[TNC] processing IETF/PB-PA message (2837 bytes)
10[TNC] handling PB-PA message type 'IETF/Operating System' 0x000000/0x00000001
10[IMV] IMV 1 "OS" received message for Connection ID 1 from IMC 1 to IMV 1
10[TNC] processing PA-TNC message with ID 0x6e31e351
10[TNC] processing PA-TNC attribute type 'TCG/Segmentation Contract Response' 0x005597/0x00000022
10[TNC] processing PA-TNC attribute type 'IETF/Installed Packages' 0x000000/0x00000007
10[IMV] IMV 1 received a segmentation contract response from IMC 1 for PA message type 'IETF/Operating System' 0x000000/0x00000001
10[IMV]   no message size limit, maximum segment size of 32698 bytes

The Installed Packages attribute contains a list of the 112 Ubuntu software packages installed on the TNC client

10[IMV] processing installed 'Ubuntu 20.04 x86_64' packages
10[IMV] package 'adduser' (3.118ubuntu2) not found
10[IMV] package 'apt' (2.0.4) not found
10[IMV] package 'base-files' (11ubuntu5.3) not found
10[IMV] package 'base-passwd' (3.5.47) not found
        ...
10[IMV] package 'tar' (1.30+dfsg-7ubuntu0.20.04.1) not found
10[IMV] package 'ubuntu-keyring' (2020.02.11.2) not found
10[IMV] package 'util-linux' (2.34-0.1ubuntu9.1) not found
10[IMV] package 'zlib1g' (1:1.2.11.dfsg-2ubuntu1.2) not found
10[IMV] IMV 1 handled PCKGS workitem 1: allow - processed 112 packages: 0 vulnerable, 0 blacklisted, 0 ok, 112 unknown

Since no information on none of these software packages is found in the TNC databse, the versions cannot be checked for security vulnerabilities and the standard PA-TNC attribute Assessment Result is set to compliant and the recommendation on behalf of the TNC server is set to allow. The PA-TNC attribute is inserted into a PA-TNC message of standard subtype Operating Systems

10[TNC] creating PA-TNC message with ID 0x8341ae40
10[TNC] creating PA-TNC attribute type 'IETF/Assessment Result' 0x000000/0x00000009
10[TNC] creating PB-PA message type 'IETF/Operating System' 0x000000/0x00000001
10[TNC] IMV 1 provides recommendation 'allow' and evaluation 'compliant'

The TNC server combines the two recommendations received from the Scanner IMV and the OS IMV and derives the overall recommendation no access which results in the three standard PB-TNC messages of standard types PB-Assessment-Result, PB-Access-Recommendation, and PB-Reason-String with the values non-compliant minor, Access Denied and Open server ports were detected, respectively. These PB-TNC messages together with the PA-TNC message generated above, are put in a PB-TNC Result batch and sent to the TNC client

10[TNC] TNC server is handling outbound connection
10[IMV] policy: recommendation for access requestor 192.168.0.3 is no access
10[IMV] policy: imv_policy_manager stop successful
10[IMV] IMV 1 "OS" changed state of Connection ID 1 to 'None'
10[IMV] IMV 2 "Scanner" changed state of Connection ID 1 to 'None'
10[TNC] PB-TNC state transition from 'Server Working' to 'Decided'
10[TNC] creating PB-TNC RESULT batch
10[TNC] adding IETF/PB-PA message
10[TNC] adding IETF/PB-Assessment-Result message
10[TNC] adding IETF/PB-Access-Recommendation message
10[TNC] adding IETF/PB-Reason-String message
10[TNC] sending PB-TNC RESULT batch (138 bytes) for Connection ID 1
10[IKE] sending tunneled EAP-TTLS AVP [EAP/REQ/PT]
10[ENC] generating IKE_AUTH response 9 [ EAP/REQ/TTLS ]
10[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (272 bytes)

The TNC server receives a PB-TNC Close batch from the TNC client which ends the TNC measurements.

13[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (144 bytes)
13[ENC] parsed IKE_AUTH request 10 [ EAP/RES/TTLS ]
13[IKE] received tunneled EAP-TTLS AVP [EAP/RES/PT]
13[TNC] received TNCCS batch (8 bytes)
13[TNC] TNC server is handling inbound connection
13[TNC] processing PB-TNC CLOSE batch for Connection ID 1
13[TNC] PB-TNC state transition from 'Decided' to 'End'
13[TNC] final recommendation is 'no access' and evaluation is 'non-compliant minor'
13[TNC] policy enforced on peer '192.168.0.3' is 'no access'
13[IKE] EAP_PT_EAP method failed
13[TLS] sending TLS close notify
13[ENC] generating IKE_AUTH response 10 [ EAP/REQ/TTLS ]
13[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (112 bytes)

TNC Client >

IKEv2 Authentication Failure

The IKEv2 EAP authentication failed due to the open TCP port. The PB-TNC Connection 1 is removed and the states of the OS IMV and Scanner IMV are deleted

11[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (112 bytes)
11[ENC] parsed IKE_AUTH request 11 [ EAP/RES/TTLS ]
11[IKE] EAP method EAP_TTLS failed for peer 192.168.0.3
11[ENC] generating IKE_AUTH response 11 [ EAP/FAIL ]
11[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
11[IMV] IMV 1 "OS" deleted the state of Connection ID 1
11[IMV] IMV 2 "Scanner" deleted the state of Connection ID 1
11[TNC] removed TNCCS Connection ID 1

TNC Client >

PSK-Based EAP Client Authentication

The following change is made in strongswan.conf

charon.plugins.eap-ttls.request_peer_auth = no

disabling the requirement for a TLS client certificate. In order to activate the change, the edited strongswan.conf file has to be reloaded by the charon daemon via the swanctl --reload-settings command.

IKEv2 Connection Setup

The VPN server receives an IKE_SA_INIT request from the VPN client with IP address 192.168.0.3 and answers with an IKE_SA_INIT response

12[NET] received packet: from 192.168.0.3[500] to 192.168.0.2[500] (240 bytes)
12[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
12[IKE] 192.168.0.3 is initiating an IKE_SA
12[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
12[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
12[NET] sending packet: from 192.168.0.2[500] to 192.168.0.3[500] (248 bytes)

The VPN server receives the IKE_AUTH request without an AUTH payload from the VPN client. Therefore the VPN server switches to EAP-based authentication and at the outset requests an EAP Identity from the client. Due to the EAP-only mode (proposed by the VPN client via the EAP_ONLY notify), the server doesn’t include an AUTH payload in its first IKE_AUTH response, either.

11[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (272 bytes)
11[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
11[CFG] looking for peer configs matching 192.168.0.2[server.strongswan.org]...192.168.0.3[192.168.0.3]
11[CFG] selected peer config 'tnc'
11[IKE] initiating EAP_IDENTITY method (id 0x00)
11[IKE] peer supports MOBIKE
11[ENC] generating IKE_AUTH response 1 [ IDr EAP/REQ/ID ]
11[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (112 bytes)

The VPN server receives the VPN client’s EAP Identity hacker and then requests the initiation of the EAP-TTLS method

01[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (80 bytes)
01[ENC] parsed IKE_AUTH request 2 [ EAP/RES/ID ]
01[IKE] received EAP identity 'hacker'
01[IKE] initiating EAP_TTLS method (id 0x86)
01[ENC] generating IKE_AUTH response 2 [ EAP/REQ/TTLS ]
01[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)

TNC Client >

EAP-TTLS Tunnel Setup

The VPN server receives the first EAP-TTLS response which contains a Client Hello message starting the TLS handshake. The negotiated TLS 1.2 cipher suite is TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. The server then sends its TLS server certificate and client certificate request

06[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (272 bytes)
06[ENC] parsed IKE_AUTH request 3 [ EAP/RES/TTLS ]
06[TLS] using key of type ECDSA
06[TLS] negotiated TLS 1.2 using suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
06[TLS] sending TLS server certificate 'C=CH, O=Cyber, CN=server.strongswan.org'
06[ENC] generating IKE_AUTH response 3 [ EAP/REQ/TTLS ]
06[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (896 bytes)

The EAP-TTLS tunnel on top of IKEv2 EAP has been successfully established. Within the tunnel the client’s EAP Identity is requested again

15[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (240 bytes)
15[ENC] parsed IKE_AUTH request 4 [ EAP/RES/TTLS ]
15[IKE] sending tunneled EAP-TTLS AVP [EAP/REQ/ID]
15[ENC] generating IKE_AUTH response 4 [ EAP/REQ/TTLS ]
15[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (176 bytes)

The VPN server receives again the client’s EAP Identity hacker and then starts the PT-EAP transport protocol within the EAP-TTLS tunnel

05[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (128 bytes)
05[ENC] parsed IKE_AUTH request 5 [ EAP/RES/TTLS ]
05[IKE] received tunneled EAP-TTLS AVP [EAP/RES/ID]
05[IKE] received EAP identity 'hacker'
05[IKE] phase2 method EAP_MD5 selected
05[IKE] sending tunneled EAP-TTLS AVP [EAP/REQ/MD5]
05[ENC] generating IKE_AUTH response 5 [ EAP/REQ/TTLS ]
05[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (144 bytes)

The EAP-MD5 authentication of the client over EAP-TTLS has been successful, so the PT-EAP transport protocol protected by the EAP-TTLS tunnel can be started

09[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (144 bytes)
09[ENC] parsed IKE_AUTH request 6 [ EAP/RES/TTLS ]
09[IKE] received tunneled EAP-TTLS AVP [EAP/RES/MD5]
09[IKE] EAP_TTLS phase2 authentication of 'hacker' with EAP_MD5 successful
09[IKE] phase2 method EAP_PT_EAP selected
09[IKE] sending tunneled EAP-TTLS AVP [EAP/REQ/PT]
09[ENC] generating IKE_AUTH response 6 [ EAP/REQ/TTLS ]
09[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (128 bytes)

TNC Client >

PB-TNC Connection 2

The TNC server receives the first PB-TNC Client Data batch and assigns the PB-TNC (TCG TNC IF-TNCCS) Connection ID 2 to the connection and also creates a new state for both the OS IMV and the Scanner IMV. The OS IMV gets the Access requestor’s identities hacker and 192.168.0.3 from the TNC server via the TNC IF-IMV API.

08[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (448 bytes)
08[ENC] parsed IKE_AUTH request 7 [ EAP/RES/TTLS ]
08[IKE] received tunneled EAP-TTLS AVP [EAP/RES/PT]
08[TNC] assigned TNCCS Connection ID 2
08[IMV] IMV 1 "OS" created a state for IF-TNCCS 2.0 Connection ID 2: +long +excl -soh
08[IMV]   over IF-T for Tunneled EAP 2.0 with maximum PA-TNC message size of 32722 bytes
08[IMV]   user AR identity 'hacker' of type username authenticated by password
08[IMV]   machine AR identity '192.168.0.3' of type IPv4 address authenticated by unknown method
08[IMV] IMV 2 "Scanner" created a state for IF-TNCCS 2.0 Connection ID 2: +long +excl -soh
08[IMV]   over IF-T for Tunneled EAP 2.0 with maximum PA-TNC message size of 32722 bytes
08[IMV] IMV 1 "OS" changed state of Connection ID 2 to 'Handshake'
08[IMV] IMV 2 "Scanner" changed state of Connection ID 2 to 'Handshake'

TNC Client >

TNC Measurements

The TNC measurements are the same as in the previous PB-TNC connection.

IKEv2 Authentication Failure

The IKEv2 EAP authentication failed due to the open TCP port. The PB-TNC Connection 2 is removed and the states of the OS IMV and Scanner IMV are deleted

10[NET] received packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (112 bytes)
10[ENC] parsed IKE_AUTH request 9 [ EAP/RES/TTLS ]
10[IKE] EAP method EAP_TTLS failed for peer 192.168.0.3
10[ENC] generating IKE_AUTH response 9 [ EAP/FAIL ]
10[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
10[IMV] IMV 1 "OS" deleted the state of Connection ID 2
10[IMV] IMV 2 "Scanner" deleted the state of Connection ID 2
10[TNC] removed TNCCS Connection ID 2

TNC Client >

TNC Database Statistics

Using the legacy attest command, all sessions and device identities that are permanently stored in the TNC database can be viewed

# /usr/libexec/ipsec/attest --sessions
   2: Mar 29 09:15:29 2022  2 Ubuntu 20.04 x86_64  a488651e36664792b306 hacker - no access
   1: Mar 29 06:30:45 2022  1 Ubuntu 20.04 x86_64  a488651e36664792b306 client.strongswan.org - no access
# /usr/libexec/ipsec/attest --devices
   1: - a488651e36664792b306cf8be72dd630 - Ubuntu 20.04 x86_64 -
   2:   Mar 29 09:15:29 2022 hacker - no access
   1:   Mar 29 06:30:45 2022 client.strongswan.org - no access
1 device found

In a next step we are going to used the much more powerful strongTNC framework to manage TNC policies and store the TNC measurement results.