Fix of the mutual TNC measurement use case

If the IKEv2 initiator acting as a TNC server receives invalid TNC measurements
from the IKEv2 responder acting as a TNC clienti, the exchange of PB-TNC batches
is continued until the IKEv2 responder acting as a TNC server has also finished
its TNC measurements.

In the past if these measurements in the other direction were correct
the IKEv2 responder acting as EAP server declared the IKEv2 EAP authentication
successful and the IPsec connection was established even though the TNC
measurement verification on the EAP peer side failed.

The fix adds an "allow" group membership on each endpoint if the corresponding
TNC measurements of the peer are successful. By requiring a "allow" group
membership in the IKEv2 connection definition the IPsec connection succeeds
only if the TNC measurements on both sides are valid.

1 files changed, 3 insertions, 2 deletions

diff --git a/testing/tests/tnc/tnccs-20-mutual-eap/hosts/moon/etc/swanctl/swanctl.conf b/testing/tests/tnc/tnccs-20-mutual-eap/hosts/moon/etc/swanctl/swanctl.conf
index bd9cb3a1c..329005907 100755
--- a/testing/tests/tnc/tnccs-20-mutual-eap/hosts/moon/etc/swanctl/swanctl.conf
+++ b/testing/tests/tnc/tnccs-20-mutual-eap/hosts/moon/etc/swanctl/swanctl.conf
@@ -10,8 +10,9 @@ connections {
          id = moon.strongswan.org
       }
       remote {
-         auth = eap-ttls 
-         id = sun.strongswan.org 
+         auth = eap-ttls
+         id = sun.strongswan.org
+         groups = allow
       }
       children {
          mutual {