TNC Client

Installation

In order to run a TNC client 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-imc

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
    }
    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.

Restriction of TLS Cipher Suites

It is possible to restrict the TLS cipher suites proposed by the client 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 Server >

Integrity Measurement Collectors

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

#IMC-Configuration

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

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

--enable-imc-os --enable-imc-scanner

When the charon daemon starts up, the IMCs are loaded. IMC 1 OS and IMC 2 Scanner 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] loading IMCs 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[IMC] IMC 1 "OS" initialized
00[IMC] processing "/etc/os-release" file
00[IMC] operating system type is 'Ubuntu'
00[IMC] operating system name is 'Ubuntu'
00[IMC] operating system version is '20.04 x86_64'
00[TNC] IMC 1 supports 1 message type: 'IETF/Operating System' 0x000000/0x00000001
00[TNC] IMC 1 "OS" loaded from '/usr/lib/ipsec/imcvs/imc-os.so'
00[IMC] IMC 2 "Scanner" initialized
00[TNC] IMC 2 supports 1 message type: 'IETF/Firewall' 0x000000/0x00000005
00[TNC] IMC 2 "Scanner" loaded from '/usr/lib/ipsec/imcvs/imc-scanner.so'

TNC Server >

TNC-Enabled VPN Client Configuration

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

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-imc 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=client.strongswan.org'
09[CFG] loaded certificate 'C=CH, O=Cyber, CN=Cyber Root CA'
11[CFG] loaded ECDSA private key
01[CFG] loaded EAP shared key with id 'eap-hacker' for: 'hacker'
00[DMN] creds: loaded certificate from '/etc/swanctl/x509/clientCert.pem'
00[DMN] creds: loaded certificate from '/etc/swanctl/x509ca/caCert.pem'
00[DMN] creds: loaded ECDSA key from '/etc/swanctl/ecdsa/clientKey.pem'
00[DMN] creds: loaded eap secret 'eap-hacker'

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

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

connections {
  tnc {
    remote_addrs = 192.168.0.2
    vips = 0.0.0.0

    local {
      auth = eap-ttls
      # used with certificate-based EAP-TLS client authenticaton
      eap_id = client.strongswan.org
      # used with password-based EAP-MD5 client authentication
      # eap_id = hacker
    }
    remote {
      auth = eap-ttls
      id = server.strongswan.org
    }
    children {
      tnc {
        remote_ts = 10.1.0.0/16,192.168.0.2
        esp_proposals = aes256gcm128-x25519
      }
    }
    version = 2
    proposals = aes256-sha256-x25519
    send_certreq = no
  }
}

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

Two configuration variants are possible. The first that is currently enabled uses certificate-based EAP client authentication whereas the second alternative that is currently commented out is based on a preshared EAP secret. In the following we are going to discuss both variants.

TNC Server >

Certificate-Based EAP Client Authentication

The client authentication is based on an EAP Identity defined by

eap_id = client.strongswan.org

as enabled in the configuration above, matched by an X.509 client certificate that is going to be used in the initial TLS handshake of the EAP-TTLS method.

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

# swanctl --list-conns
tnc: IKEv2, no reauthentication, rekeying every 14400s
  local:  %any
  remote: 192.168.0.2
  local EAP_TTLS authentication:
    eap_id: client.strongswan.org
  remote EAP_TTLS authentication:
    id: server.strongswan.org
  tnc: TUNNEL, rekeying every 3600s
    local:  dynamic
    remote: 10.1.0.0/16 192.168.0.2/32

IKEv2 Connection Setup

The IPsec connection is started as usual with the swanctl --initiate command

# swanctl --initiate --child tnc > /dev/null
07[CFG] vici initiate CHILD_SA 'tnc'
08[IKE] initiating IKE_SA tnc[1] to 192.168.0.2
08[ENC] generating 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) ]
08[NET] sending packet: from 192.168.0.3[500] to 192.168.0.2[500] (240 bytes)

Since no IKE client identity has been explicitly defined, the client’s IP address 192.168.0.3 is used by default. By sending the EAP_ONLY notify, the client is signalling to the server that it is willing to accept EAP-only authentication according to RFC5998

09[NET] received packet: from 192.168.0.2[500] to 192.168.0.3[500] (248 bytes)
09[ENC] parsed 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) ]
09[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
09[CFG] no IDi configured, fall back on IP address
09[IKE] establishing CHILD_SA tnc{1}
09[ENC] generating 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) ]
09[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (272 bytes)

Since the VPN client didn’t include an AUTH payload in its IKE_AUTH request, the VPN server switches to EAP-based authentication and at the outset requests an EAP Identity. The client replies with its EAP Identity client.strongswan.org. Due to the EAP-only mode, the server doesn’t include an AUTH payload in its first IKE_AUTH response, either.

06[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (112 bytes)
06[ENC] parsed IKE_AUTH response 1 [ IDr EAP/REQ/ID ]
06[IKE] server requested EAP_IDENTITY (id 0x00), sending 'client.strongswan.org'
06[IKE] allow mutual EAP-only authentication
06[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
06[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (96 bytes)

TNC Server >

EAP-TTLS Tunnel Setup

Next the server requests EAP-TTLS which triggers the client to start a TLS handshake

09[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
09[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/TTLS ]
09[IKE] server requested EAP_TTLS authentication (id 0x45)
09[TLS] EAP_TTLS version is v0
09[ENC] generating IKE_AUTH request 3 [ EAP/RES/TTLS ]
09[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (272 bytes)

The negotiated TLS 1.2 cipher suite is TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. The server sends its TLS server certificate and the client responds by sending its TLS client certificate

10[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (928 bytes)
10[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/TTLS ]
10[TLS] negotiated TLS 1.2 using suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
10[TLS] received TLS server certificate 'C=CH, O=Cyber, CN=server.strongswan.org'
10[CFG]   using certificate "C=CH, O=Cyber, CN=server.strongswan.org"
10[CFG]   using trusted ca certificate "C=CH, O=Cyber, CN=Cyber Root CA"
10[CFG]   reached self-signed root ca with a path length of 0
10[TLS] sending TLS client certificate 'C=CH, O=Cyber, CN=client.strongswan.org'
10[ENC] generating IKE_AUTH request 4 [ EAP/RES/TTLS ]
10[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (880 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

09[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (176 bytes)
09[ENC] parsed IKE_AUTH response 4 [ EAP/REQ/TTLS ]
09[IKE] received tunneled EAP-TTLS AVP [EAP/REQ/ID]
09[IKE] server requested EAP_IDENTITY authentication (id 0x00)
09[IKE] sending tunneled EAP-TTLS AVP [EAP/RES/ID]
09[ENC] generating IKE_AUTH request 5 [ EAP/RES/TTLS ]
09[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (144 bytes)

TNC Server >

PB-TNC Connection 1

Now within the EAP-TTLS tunnel the PT-EAP transport protocol is started and the PB-TNC (TCG TNC IF-TNCCS 2.0) Connection ID 1 is assigned to the connection by the TNC client and a new state is created for both the OS IMC and the Scanner IMC

16[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (128 bytes)
16[ENC] parsed IKE_AUTH response 5 [ EAP/REQ/TTLS ]
16[IKE] received tunneled EAP-TTLS AVP [EAP/REQ/PT]
16[IKE] server requested EAP_PT_EAP authentication (id 0xCC)
16[TLS] EAP_PT_EAP version is v1
16[TNC] TNC client is handling outbound connection
16[TNC] assigned TNCCS Connection ID 1
16[IMC] IMC 1 "OS" created a state for IF-TNCCS 2.0 Connection ID 1: +long +excl -soh
16[IMC]   over IF-T for Tunneled EAP 2.0 with maximum PA-TNC message size of 32722 bytes
16[IMC] IMC 2 "Scanner" created a state for IF-TNCCS 2.0 Connection ID 1: +long +excl -soh
16[IMC]   over IF-T for Tunneled EAP 2.0 with maximum PA-TNC message size of 32722 bytes
16[IMC] IMC 1 "OS" changed state of Connection ID 1 to 'Handshake'
16[IMC] IMC 2 "Scanner" changed state of Connection ID 1 to 'Handshake'

TNC Server >

TNC Measurements

The OS IMC gathers information on the operating system and creates seven PA-TNC attributes and puts them in a PA-TNC message of the standard subtype Operating System

16[IMC] operating system numeric version is 20.4
16[IMC] last boot: Mar 28 07:42:58 UTC 2022, 39621 s ago
16[IMC] IPv4 forwarding is enabled
16[IMC] factory default password is disabled
16[IMC] device ID is a488651e36664792b306cf8be72dd630
16[TNC] creating PA-TNC message with ID 0x0f74f43f
16[TNC] creating PA-TNC attribute type 'IETF/Product Information' 0x000000/0x00000002
16[TNC] creating PA-TNC attribute type 'IETF/String Version' 0x000000/0x00000004
16[TNC] creating PA-TNC attribute type 'IETF/Numeric Version' 0x000000/0x00000003
16[TNC] creating PA-TNC attribute type 'IETF/Operational Status' 0x000000/0x00000005
16[TNC] creating PA-TNC attribute type 'IETF/Forwarding Enabled' 0x000000/0x0000000b
16[TNC] creating PA-TNC attribute type 'IETF/Factory Default Password Enabled' 0x000000/0x0000000c
16[TNC] creating PA-TNC attribute type 'ITA-HSR/Device ID' 0x00902a/0x00000008
16[TNC] creating PB-PA message type 'IETF/Operating System' 0x000000/0x00000001

The Scanner IMC determines all open listening ports using netstat and puts the port list into a PA-TNC attribute which in turn is embedded in a PA-TNC message of standard subtype Firewall

16[IMC] Active Internet connections (only servers)
16[IMC] Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
16[IMC] tcp        0      0 127.0.0.11:41963        0.0.0.0:*               LISTEN      -
16[IMC] udp        0      0 0.0.0.0:4500            0.0.0.0:*                           17/./charon
16[IMC] udp        0      0 127.0.0.11:47753        0.0.0.0:*                           -
16[IMC] udp        0      0 0.0.0.0:500             0.0.0.0:*                           17/./charon
16[IMC] udp6       0      0 :::4500                 :::*                                17/./charon
16[IMC] udp6       0      0 :::500                  :::*                                17/./charon
16[TNC] creating PA-TNC message with ID 0x0dc7be19
16[TNC] creating PA-TNC attribute type 'IETF/Port Filter' 0x000000/0x00000006
16[TNC] creating PB-PA message type 'IETF/Firewall' 0x000000/0x00000005

Both PA-TNC messages are put into a PB-TNC Client Data batch and are sent to the TNC server

16[TNC] PB-TNC state transition from 'Init' to 'Server Working'
16[TNC] creating PB-TNC CDATA batch
16[TNC] adding IETF/PB-Language-Preference message
16[TNC] adding IETF/PB-PA message
16[TNC] adding IETF/PB-PA message
16[TNC] sending PB-TNC CDATA batch (321 bytes) for Connection ID 1
16[IKE] sending tunneled EAP-TTLS AVP [EAP/RES/PT]
16[ENC] generating IKE_AUTH request 6 [ EAP/RES/TTLS ]
16[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (448 bytes)

A PB-TNC Server Data batch containing two PA-TNC messages is received by the TNC client.

05[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (640 bytes)
05[ENC] parsed IKE_AUTH response 6 [ EAP/REQ/TTLS ]
05[IKE] received tunneled EAP-TTLS AVP [EAP/REQ/PT]
05[TNC] received TNCCS batch (512 bytes)
05[TNC] TNC client is handling inbound connection
05[TNC] processing PB-TNC SDATA batch for Connection ID 1
05[TNC] PB-TNC state transition from 'Server Working' to 'Client Working'
05[TNC] processing IETF/PB-PA message (72 bytes)
05[TNC] processing IETF/PB-PA message (432 bytes)

The first PA-TNC message is of standard subtype Operating System and contains 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), plus a second PA-TNC attribute of the standard type Attribute Request which requests a PA-TNC attribute of standard type Installed Packages

05[TNC] handling PB-PA message type 'IETF/Operating System' 0x000000/0x00000001
05[IMC] IMC 1 "OS" received message for Connection ID 1 from IMV 1
05[TNC] processing PA-TNC message with ID 0xc084b149
05[TNC] processing PA-TNC attribute type 'TCG/Segmentation Contract Request' 0x005597/0x00000021
05[TNC] processing PA-TNC attribute type 'IETF/Attribute Request' 0x000000/0x00000001
05[TNC]   0x000000/0x00000007 'IETF/Installed Packages'
05[IMC] IMC 1 received a segmentation contract request from IMV 1 for PA message type 'IETF/Operating System' 0x000000/0x00000001
05[IMC]   no message size limit, maximum segment size of 32698 bytes

The OS IMC compiles a list of all installed Ubuntu packages for the Installed Packages PA-TNC attribute and puts it into a PA-TNC message of standard subtype Operating System together with the Segmentation Contract Response PA-TNC attribute defined in the TCG namespace

05[IMC] package 'adduser' (3.118ubuntu2)
05[IMC] package 'apt' (2.0.4)
05[IMC] package 'base-files' (11ubuntu5.3)
05[IMC] package 'base-passwd' (3.5.47)
        ...
05[IMC] package 'tar' (1.30+dfsg-7ubuntu0.20.04.1)
05[IMC] package 'ubuntu-keyring' (2020.02.11.2)
05[IMC] package 'util-linux' (2.34-0.1ubuntu9.1)
05[IMC] package 'zlib1g' (1:1.2.11.dfsg-2ubuntu1.2)
05[TNC] creating PA-TNC message with ID 0x6e31e351
05[TNC] creating PA-TNC attribute type 'TCG/Segmentation Contract Response' 0x005597/0x00000022
05[TNC] creating PA-TNC attribute type 'IETF/Installed Packages' 0x000000/0x00000007
05[TNC] creating PB-PA message type 'IETF/Operating System' 0x000000/0x00000001

The Scanner IMC processes the second PA-TNC message of standard subtype Firewall which contains the standard PA-TNC attributes Assessment Result and Remediation Instructions which contain the result non-compliant minor and the remediation to close the TCP server port 41963

05[TNC] handling PB-PA message type 'IETF/Firewall' 0x000000/0x00000005
05[IMC] IMC 2 "Scanner" received message for Connection ID 1 from IMV 2
05[TNC] processing PA-TNC message with ID 0x26d87477
05[TNC] processing PA-TNC attribute type 'IETF/Assessment Result' 0x000000/0x00000009
05[TNC] processing PA-TNC attribute type 'IETF/Remediation Instructions' 0x000000/0x0000000a
05[IMC] ***** assessment of IMC 2 "Scanner" from IMV 2 *****
05[IMC] assessment result is 'non-compliant minor'
05[IMC] remediation string: [en]
05[IMC] <?xml version="1.0" encoding="UTF-8"?>
05[IMC] <remediationinstructions>
05[IMC]   <instruction>
05[IMC]     <title>Open Server Ports</title>
05[IMC]     <description>Open Internet ports have been detected</description>
05[IMC]     <itemsheader>Please close the following server ports:</itemsheader>
05[IMC]     <items>
05[IMC]       <item>tcp/41963</item>
05[IMC]     </items>
05[IMC]   </instruction>
05[IMC] </remediationinstructions>
05[IMC] ***** end of assessment *****

The PA-TNC message containing the Installed Packages standard attribute is sent in a PB-TNC Client Data batch to the TNC server. Since the batch with a size of 2845 bytes is quite large, it is broken up into three EAP-TTLS segments

05[TNC] TNC client is handling outbound connection
05[TNC] PB-TNC state transition from 'Client Working' to 'Server Working'
05[TNC] creating PB-TNC CDATA batch
05[TNC] adding IETF/PB-PA message
05[TNC] sending PB-TNC CDATA batch (2845 bytes) for Connection ID 1
05[IKE] sending tunneled EAP-TTLS AVP [EAP/RES/PT]
05[ENC] generating IKE_AUTH request 7 [ EAP/RES/TTLS ]
05[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (1104 bytes)
06[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
06[ENC] parsed IKE_AUTH response 7 [ EAP/REQ/TTLS ]
06[ENC] generating IKE_AUTH request 8 [ EAP/RES/TTLS ]
06[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (1104 bytes)
05[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
05[ENC] parsed IKE_AUTH response 8 [ EAP/REQ/TTLS ]
05[ENC] generating IKE_AUTH request 9 [ EAP/RES/TTLS ]
05[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (944 bytes)

A PB-TNC Result batch is received by the TNC client. It contains a PA-TNC message of standard subtype Operating System directed to the OS IMC and carries a standard Assessment Result PA-TNC attribute with the value compliant.

Additionally the PB-TNC Result batch contains 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.

Finally the TNC client sends a PB-TNC Close batch to the TNC server, closing down the PA-TNC Connection with ID 1

06[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (272 bytes)
06[ENC] parsed IKE_AUTH response 9 [ EAP/REQ/TTLS ]
06[IKE] received tunneled EAP-TTLS AVP [EAP/REQ/PT]
06[TNC] received TNCCS batch (138 bytes)
06[TNC] TNC client is handling inbound connection
06[TNC] processing PB-TNC RESULT batch for Connection ID 1
06[TNC] PB-TNC state transition from 'Server Working' to 'Decided'
06[TNC] processing IETF/PB-PA message (48 bytes)
06[TNC] processing IETF/PB-Assessment-Result message (16 bytes)
06[TNC] processing IETF/PB-Access-Recommendation message (16 bytes)
06[TNC] processing IETF/PB-Reason-String message (50 bytes)
06[TNC] handling PB-PA message type 'IETF/Operating System' 0x000000/0x00000001
06[IMC] IMC 1 "OS" received message for Connection ID 1 from IMV 1
06[TNC] processing PA-TNC message with ID 0x8341ae40
06[TNC] processing PA-TNC attribute type 'IETF/Assessment Result' 0x000000/0x00000009
06[IMC] ***** assessment of IMC 1 "OS" from IMV 1 *****
06[IMC] assessment result is 'compliant'
06[IMC] ***** end of assessment *****
06[TNC] PB-TNC assessment result is 'non-compliant minor'
06[TNC] PB-TNC access recommendation is 'Access Denied'
06[IMC] IMC 1 "OS" changed state of Connection ID 1 to 'None'
06[IMC] IMC 2 "Scanner" changed state of Connection ID 1 to 'None'
06[TNC] reason string is 'Open server ports were detected' [en]
06[TNC] TNC client is handling outbound connection
06[TNC] PB-TNC state transition from 'Decided' to 'End'
06[TNC] creating PB-TNC CLOSE batch
06[TNC] sending PB-TNC CLOSE batch (8 bytes) for Connection ID 1
06[IKE] sending tunneled EAP-TTLS AVP [EAP/RES/PT]
06[ENC] generating IKE_AUTH request 10 [ EAP/RES/TTLS ]
06[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (144 bytes)

The VPN server and subsequently the VPN client close the EAP-TTLS tunnel over IKEv2 EAP since it is not needed anymore for TNC measurements

10[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (112 bytes)
10[ENC] parsed IKE_AUTH response 10 [ EAP/REQ/TTLS ]
10[TLS] received TLS close notify
10[TLS] sending TLS close notify
10[ENC] generating IKE_AUTH request 11 [ EAP/RES/TTLS ]
10[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (112 bytes)

TNC Server >

IKEv2 Authentication Failure

Since the overall PB-TNC PB-Assessment-Recommendation was Access Denied due to the open TCP server port, the IKEv2 negotiation aborts as well. The PB-TNC Connection 1 is removed and the states of the OS IMC and Scanner IMC are deleted

09[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
09[ENC] parsed IKE_AUTH response 11 [ EAP/FAIL ]
09[IKE] received EAP_FAILURE, EAP authentication failed
09[ENC] generating INFORMATIONAL request 12 [ N(AUTH_FAILED) ]
09[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (80 bytes)
09[IMC] IMC 1 "OS" deleted the state of Connection ID 1
09[IMC] IMC 2 "Scanner" deleted the state of Connection ID 1
09[TNC] removed TNCCS Connection ID 1
initiate failed: establishing CHILD_SA 'tnc' failed

TNC Server >

PSK-Based EAP Client Authentication

Alternatively a preshared EAP secret could be used with EAP-MD5 or EAP-MSCHAPv2 within EAP-TTLS by enabling the EAP Identity

eap_id = hacker

in the configuration file swanctl.conf defined above and then reloading the edited configuration with the swanctl --load-conns command. The swanctl --list-conns then shows the reloaded VPN connection definition

swanctl --list-conns
tnc: IKEv2, no reauthentication, rekeying every 14400s
  local:  %any
  remote: 192.168.0.2
  local EAP_TTLS authentication:
    eap_id: hacker
  remote EAP_TTLS authentication:
    id: server.strongswan.org
  tnc: TUNNEL, rekeying every 3600s
    local:  dynamic
    remote: 10.1.0.0/16 192.168.0.2/32

IKEv2 Connection Setup

The IPsec connection is again started with the swanctl --initiate command

# swanctl --initiate --child tnc > /dev/null
10[CFG] vici initiate CHILD_SA 'tnc'
01[IKE] initiating IKE_SA tnc[2] to 192.168.0.2
01[ENC] generating 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) ]
01[NET] sending packet: from 192.168.0.3[500] to 192.168.0.2[500] (240 bytes)

Since no IKE client identity has been explicitly defined, the client’s IP address 192.168.0.3 is used by default. By sending the EAP_ONLY notify the client is signalling to the server that it is willing to accept EAP-only authentication according to RFC5998

14[NET] received packet: from 192.168.0.2[500] to 192.168.0.3[500] (248 bytes)
14[ENC] parsed 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) ]
14[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
14[CFG] no IDi configured, fall back on IP address
14[IKE] establishing CHILD_SA tnc{2}
14[ENC] generating 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[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (272 bytes)

Since the VPN client didn’t include an AUTH payload in its IKE_AUTH request, the VPN server switches to EAP-based authentication and at the outset requests an EAP Identity. The client replies with its EAP Identity hacker. Due to the EAP-only mode, the server doesn’t include an AUTH payload in its first IKE_AUTH response, either.

13[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (112 bytes)
13[ENC] parsed IKE_AUTH response 1 [ IDr EAP/REQ/ID ]
13[IKE] server requested EAP_IDENTITY (id 0x00), sending 'hacker'
13[IKE] allow mutual EAP-only authentication
13[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
13[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (80 bytes)

EAP-TTLS Tunnel Setup

Next the server requests EAP-TTLS which triggers the client to start a TLS handshake

14[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
14[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/TTLS ]
14[IKE] server requested EAP_TTLS authentication (id 0x86)
14[TLS] EAP_TTLS version is v0
14[ENC] generating IKE_AUTH request 3 [ EAP/RES/TTLS ]
14[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (272 bytes)

The negotiated TLS 1.2 cipher suite is TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. The server sends its TLS server certificate

06[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (896 bytes)
06[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/TTLS ]
06[TLS] negotiated TLS 1.2 using suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
06[TLS] received TLS server certificate 'C=CH, O=Cyber, CN=server.strongswan.org'
06[CFG]   using certificate "C=CH, O=Cyber, CN=server.strongswan.org"
06[CFG]   using trusted ca certificate "C=CH, O=Cyber, CN=Cyber Root CA"
06[CFG]   reached self-signed root ca with a path length of 0
06[ENC] generating IKE_AUTH request 4 [ EAP/RES/TTLS ]
06[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (240 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

05[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (176 bytes)
05[ENC] parsed IKE_AUTH response 4 [ EAP/REQ/TTLS ]
05[IKE] received tunneled EAP-TTLS AVP [EAP/REQ/ID]
05[IKE] server requested EAP_IDENTITY authentication (id 0x00)
05[IKE] sending tunneled EAP-TTLS AVP [EAP/RES/ID]
05[ENC] generating IKE_AUTH request 5 [ EAP/RES/TTLS ]
05[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (128 bytes)

Within the EAP-TTLS tunnel the EAP-MD5 authentication based on the EAP preshared secret is done

13[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (144 bytes)
13[ENC] parsed IKE_AUTH response 5 [ EAP/REQ/TTLS ]
13[IKE] received tunneled EAP-TTLS AVP [EAP/REQ/MD5]
13[IKE] server requested EAP_MD5 authentication (id 0xD4)
13[IKE] sending tunneled EAP-TTLS AVP [EAP/RES/MD5]
13[ENC] generating IKE_AUTH request 6 [ EAP/RES/TTLS ]
13[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (144 bytes)

PB-TNC Connection 2

Again the PT-EAP transport protocol is started within the EAP-TTLS tunnel and the PB-TNC (TCG IF-TNCCS) Connection ID 2 is assigned to the connection by the TNC client and a fresh state is created for both the OS IMC and the Scanner IMC

08[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (128 bytes)
08[ENC] parsed IKE_AUTH response 6 [ EAP/REQ/TTLS ]
08[IKE] received tunneled EAP-TTLS AVP [EAP/REQ/PT]
08[IKE] server requested EAP_PT_EAP authentication (id 0x09)
08[TLS] EAP_PT_EAP version is v1
08[TNC] TNC client is handling outbound connection
08[TNC] assigned TNCCS Connection ID 2
08[IMC] IMC 1 "OS" created a state for IF-TNCCS 2.0 Connection ID 2: +long +excl -soh
08[IMC]   over IF-T for Tunneled EAP 2.0 with maximum PA-TNC message size of 32722 bytes
08[IMC] IMC 2 "Scanner" created a state for IF-TNCCS 2.0 Connection ID 2: +long +excl -soh
08[IMC]   over IF-T for Tunneled EAP 2.0 with maximum PA-TNC message size of 32722 bytes
08[IMC] IMC 1 "OS" changed state of Connection ID 2 to 'Handshake'
08[IMC] IMC 2 "Scanner" changed state of Connection ID 2 to 'Handshake'

TNC Measurements

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

IKEv2 Authentication Failure

Since the overall PB-TNC PB-Assessment-Recommendation was Access Denied due to the open TCP server port, the IKEv2 negotiation aborts as well. The PB-TNC Connection 2 is removed and the states of the OS IMC and Scanner IMC are deleted

09[NET] received packet: from 192.168.0.2[4500] to 192.168.0.3[4500] (80 bytes)
09[ENC] parsed IKE_AUTH response 9 [ EAP/FAIL ]
09[IKE] received EAP_FAILURE, EAP authentication failed
09[ENC] generating INFORMATIONAL request 10 [ N(AUTH_FAILED) ]
09[NET] sending packet: from 192.168.0.3[4500] to 192.168.0.2[4500] (80 bytes)
09[IMC] IMC 1 "OS" deleted the state of Connection ID 2
09[IMC] IMC 2 "Scanner" deleted the state of Connection ID 2
09[TNC] removed TNCCS Connection ID 2
initiate failed: establishing CHILD_SA 'tnc' failed

TNC Server >