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