describe EAP-TTLS phase2 start options using the phase2_piggyback parameter

diff --git a/testing/tests/ikev2/rw-eap-ttls-only/description.txt b/testing/tests/ikev2/rw-eap-ttls-only/description.txt
index 702598e..3d4c3ab 100644 (file)
--- a/testing/tests/ikev2/rw-eap-ttls-only/description.txt
+++ b/testing/tests/ikev2/rw-eap-ttls-only/description.txt
@@ -2,5 +2,10 @@ The roadwarriors <b>carol</b> and <b>dave</b> set up a connection each to gatewa
 The strong mutual authentication is based on <b>EAP-TTLS</b> only (without a separate IKEv2
 authentication) with the gateway being authenticated by a server certificate during the
 EAP-TLS tunnel setup (phase1 of EAP-TTLS). This tunnel protects the ensuing weak client
 The strong mutual authentication is based on <b>EAP-TTLS</b> only (without a separate IKEv2
 authentication) with the gateway being authenticated by a server certificate during the
 EAP-TLS tunnel setup (phase1 of EAP-TTLS). This tunnel protects the ensuing weak client

-authentication based on <b>EAP-MD5</b> (phase2 of EAP-TTLS). <b>carol</b> presents the
-correct MD5 password and succeeds whereas <b>dave</b> chooses the wrong password and fails.
+authentication based on <b>EAP-MD5</b> (phase2 of EAP-TTLS).
+<p/> 
+With the default setting <b>charon.plugins.eap-ttls.phase2_piggyback = no</b> the server
+<b>moon</b> passively waits for the clients to initiate phase2 of the EAP-TTLS protocol by
+sending a tunneled orphan EAP Identity response upon the reception of the server's TLS
+Finished message. Client <b>carol</b> presents the correct MD5 password and succeeds
+whereas client <b>dave</b> chooses the wrong password and fails.

diff --git a/testing/tests/ikev2/rw-eap-ttls-phase2-piggyback/description.txt b/testing/tests/ikev2/rw-eap-ttls-phase2-piggyback/description.txt
index 9624fa7..d5f0b26 100644 (file)
--- a/testing/tests/ikev2/rw-eap-ttls-phase2-piggyback/description.txt
+++ b/testing/tests/ikev2/rw-eap-ttls-phase2-piggyback/description.txt
@@ -2,7 +2,9 @@ The roadwarriors <b>carol</b> and <b>dave</b> set up a connection each to gatewa
 The strong mutual authentication is based on <b>EAP-TTLS</b> only (without a separate IKEv2
 authentication) with the gateway being authenticated by a server certificate during the
 EAP-TLS tunnel setup (phase1 of EAP-TTLS). This tunnel protects the ensuing weak client
 The strong mutual authentication is based on <b>EAP-TTLS</b> only (without a separate IKEv2
 authentication) with the gateway being authenticated by a server certificate during the
 EAP-TLS tunnel setup (phase1 of EAP-TTLS). This tunnel protects the ensuing weak client

-authentication based on <b>EAP-MD5</b> (phase2 of EAP-TTLS). The server <b>moon</b>
-piggybacks the tunneled EAP Identity request which starts phase2 of EAP-TTLS right onto
-the TLS Finished message. <b>carol</b> presents the correct MD5 password and succeeds
-whereas <b>dave</b> chooses the wrong password and fails.
+authentication based on <b>EAP-MD5</b> (phase2 of EAP-TTLS).
+<p/>
+With the setting <b>charon.plugins.eap-ttls.phase2_piggyback = yes</b> the server <b>moon</b>
+initiates phase2 of the EAP-TTLS protocol by piggybacking a tunneled EAP Identity request
+right onto the TLS Finished message. Client <b>carol</b> presents the correct MD5 password
+and succeeds whereas client <b>dave</b> chooses the wrong password and fails.