Spelling fixes
* accumulating * acquire * alignment * appropriate * argument * assign * attribute * authenticate * authentication * authenticator * authority * auxiliary * brackets * callback * camellia * can't * cancelability * certificate * choinyambuu * chunk * collector * collision * communicating * compares * compatibility * compressed * confidentiality * configuration * connection * consistency * constraint * construction * constructor * database * decapsulated * declaration * decrypt * derivative * destination * destroyed * details * devised * dynamic * ecapsulation * encoded * encoding * encrypted * enforcing * enumerator * establishment * excluded * exclusively * exited * expecting * expire * extension * filter * firewall * foundation * fulfillment * gateways * hashing * hashtable * heartbeats * identifier * identifiers * identities * identity * implementers * indicating * initialize * initiate * initiation * initiator * inner * instantiate * legitimate * libraries * libstrongswan * logger * malloc * manager * manually * measurement * mechanism * message * network * nonexistent * object * occurrence * optional * outgoing * packages * packets * padding * particular * passphrase * payload * periodically * policies * possible * previously * priority * proposal * protocol * provide * provider * pseudo * pseudonym * public * qualifier * quantum * quintuplets * reached * reading * recommendation to * recommendation * recursive * reestablish * referencing * registered * rekeying * reliable * replacing * representing * represents * request * request * resolver * result * resulting * resynchronization * retriable * revocation * right * rollback * rule * rules * runtime * scenario * scheduled * security * segment * service * setting * signature * specific * specified * speed * started * steffen * strongswan * subjectaltname * supported * threadsafe * traffic * tremendously * treshold * unique * uniqueness * unknown * until * upper * using * validator * verification * version * version * warrior Closes strongswan/strongswan#164.
This commit is contained in:
Josh Soref
committed by
Tobias Brunner
Tobias Brunner
parent
baf29263d5
commit
b3ab7a48cc
@@ -10,7 +10,7 @@
|
||||
# running in the background
|
||||
### END INIT INFO
|
||||
|
||||
# Author: Andreas Steffen <[email protected]>
|
||||
# Author: Andreas Steffen <andreas.steffen@strongswan.org>
|
||||
#
|
||||
# Do NOT "set -e"
|
||||
|
||||
|
||||
@@ -816,7 +816,7 @@ cp ${TEST_KEY} ${TEST_CERT} ${DIR}/hosts/alice/etc/raddb/certs
|
||||
# strongSwan Attribute Authority #
|
||||
################################################################################
|
||||
|
||||
# Generate Attritbute Authority certificate
|
||||
# Generate Attribute Authority certificate
|
||||
TEST="${TEST_DIR}/ikev2/acert-cached"
|
||||
TEST_KEY="${TEST}/hosts/moon/${IPSEC_DIR}/private/aaKey.pem"
|
||||
TEST_CERT="${TEST}/hosts/moon/${IPSEC_DIR}/aacerts/aaCert.pem"
|
||||
@@ -882,7 +882,7 @@ cp ${TEST_CERT} ${TEST}/hosts/moon/${IPSEC_DIR}/aacerts
|
||||
cp ${ACERT_CS} ${TEST}/hosts/carol/${IPSEC_DIR}/acerts
|
||||
cp ${ACERT_DM} ${TEST}/hosts/dave/${IPSEC_DIR}/acerts
|
||||
|
||||
# Generate a short-lived Attritbute Authority certificate
|
||||
# Generate a short-lived Attribute Authority certificate
|
||||
CN="strongSwan Legacy AA"
|
||||
TEST_KEY="${TEST}/hosts/moon/${IPSEC_DIR}/private/aaKey-expired.pem"
|
||||
TEST_CERT="${TEST}/hosts/moon/${IPSEC_DIR}/aacerts/aaCert-expired.pem"
|
||||
|
||||
@@ -2,7 +2,7 @@ The roadwarriors <b>carol</b> and <b>dave</b> set up a connection each
|
||||
to the virtual gateway <b>mars</b> implemented by the two real gateways
|
||||
<b>alice</b> and <b>moon</b> in a <b>High Availability</b> (HA) setup
|
||||
based on <b>ClusterIP</b>. The HA synchronisation link between the two
|
||||
gatways is secured by an IPsec transport connection. At the outset
|
||||
gateways is secured by an IPsec transport connection. At the outset
|
||||
<b>alice</b> is the active and <b>moon</b> is the passive gateway.
|
||||
After <b>alice</b> gets killed <b>moon</b> automatically takes over
|
||||
all existing IKE_SAs and CHILD_SAs.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
The roadwarrior <b>alice</b> is sitting behind the NAT router <b>moon</b> but
|
||||
at the outset of the scenariou is also directly connected to the 192.168.0.0/24 network
|
||||
at the outset of the scenario is also directly connected to the 192.168.0.0/24 network
|
||||
via an additional <b>eth1</b> interface. <b>alice</b> builds up a tunnel to gateway <b>sun</b>
|
||||
in order to reach <b>bob</b> in the subnet behind. When the <b>eth1</b> interface
|
||||
goes away, <b>alice</b> switches to <b>eth0</b> and signals the IP address change
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
The roadwarrior <b>alice</b> is sitting behind the router <b>moon</b> but
|
||||
at the outset of the scenariou is also directly connected to the 192.168.0.0/24 network
|
||||
at the outset of the scenario is also directly connected to the 192.168.0.0/24 network
|
||||
via an additional <b>eth1</b> interface. <b>alice</b> builds up a tunnel to gateway <b>sun</b>
|
||||
in order to reach <b>bob</b> in the subnet behind. When the <b>eth1</b> interface
|
||||
goes away, <b>alice</b> switches to <b>eth0</b> and signals the IP address change
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
The roadwarrior <b>alice</b> is sitting behind the router <b>moon</b> but
|
||||
at the outset of the scenariou is also directly connected to the 192.168.0.0/24 network
|
||||
at the outset of the scenario is also directly connected to the 192.168.0.0/24 network
|
||||
via an additional <b>eth1</b> interface. <b>alice</b> builds up a tunnel to gateway <b>sun</b>
|
||||
in order to reach <b>bob</b> in the subnet behind. When the <b>eth1</b> interface
|
||||
goes away, <b>alice</b> switches to <b>eth0</b> and signals the IP address change
|
||||
|
||||
@@ -11,7 +11,7 @@ contain any URIs. Therefore a strict CRL policy is <b>not</b> enforced and the
|
||||
connection setup succeeds, although the certificate status is unknown.
|
||||
</p>
|
||||
<p>
|
||||
The roadwarrrior <b>dave</b> has a certificate from the Sales CA which contains
|
||||
The roadwarrior <b>dave</b> has a certificate from the Sales CA which contains
|
||||
a single OCSP URI but which is not resolvable. Thus because of the known URI
|
||||
a strict CRL policy is enforced and the unknown certificate status causes the
|
||||
connection setup to fail.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
This scenario tests <b>repeated authentication</b> according to RFC 4478.
|
||||
The iniator <b>carol</b> sets a large <b>ikelifetime=20m</b> but the responder
|
||||
The initiator <b>carol</b> sets a large <b>ikelifetime=20m</b> but the responder
|
||||
<b>moon</b> defining a much shorter <b>ikelifetime=30s</b> proposes this
|
||||
value via an AUTH_LIFETIME notification to the initiator. Thus the
|
||||
IKE reauthentication takes places after less than 30s. A ping from
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
This scenario tests <b>repeated authentication</b> according to RFC 4478.
|
||||
The iniator <b>carol</b> sets a short <b>ikelifetime=20m</b> but the responder
|
||||
The initiator <b>carol</b> sets a short <b>ikelifetime=20m</b> but the responder
|
||||
<b>moon</b> defining a much larger <b>ikelifetime=30s</b> proposes this
|
||||
value via an AUTH_LIFETIME notification to the initiator. The initatior
|
||||
value via an AUTH_LIFETIME notification to the initiator. The initiator
|
||||
ignores this notification and schedules the IKE reauthentication within
|
||||
the shorter interval of 30s. A ping from <b>carol</b> to client <b>alice</b>
|
||||
hiding in the subnet behind <b>moon</b> tests if the CHILD_SA has been
|
||||
|
||||
@@ -11,7 +11,7 @@ moon:: cat /var/log/daemon.log::EAP_PEAP phase2 authentication of 'carol@strongs
|
||||
moon:: cat /var/log/daemon.log::authentication of '[email protected]' with EAP successful::YES
|
||||
moon:: cat /var/log/daemon.log::EAP method EAP_PEAP failed for peer [email protected]::YES
|
||||
moon:: ipsec status 2> /dev/null::rw-eap\[1]: ESTABLISHED.*CN=moon.strongswan.org.*[email protected]::YES
|
||||
moon:: ipsec status 2> /dev/null::rw-eap\[2]: ESTABLISHED.*CN=moon.strongswan.org.*[email protected]::NO
|
||||
moon:: ipsec status 2> /dev/null::rw-eap\[2]: ESTABLISHED.*CN=moon.strongswan.org.*dave@strongswan.org::NO
|
||||
carol::ipsec status 2> /dev/null::home.*ESTABLISHED.*[email protected].*CN=moon.strongswan.org::YES
|
||||
dave:: ipsec status 2> /dev/null::home.*ESTABLISHED.*[email protected].*CN=moon.strongswan.org::NO
|
||||
moon:: ipsec status 2> /dev/null::rw-eap[{]1}.*INSTALLED, TUNNEL::YES
|
||||
|
||||
@@ -11,7 +11,7 @@ moon:: cat /var/log/daemon.log::EAP_PEAP phase2 authentication of 'carol@strongs
|
||||
moon:: cat /var/log/daemon.log::authentication of '[email protected]' with EAP successful::YES
|
||||
moon:: cat /var/log/daemon.log::EAP method EAP_PEAP failed for peer [email protected]::YES
|
||||
moon:: ipsec status 2> /dev/null::rw-eap.*ESTABLISHED.*moon.strongswan.org.*[email protected]::YES
|
||||
moon:: ipsec status 2> /dev/null::rw-eap.*ESTABLISHED.*moon.strongswan.org.*[email protected]::NO
|
||||
moon:: ipsec status 2> /dev/null::rw-eap.*ESTABLISHED.*moon.strongswan.org.*dave@strongswan.org::NO
|
||||
carol::ipsec status 2> /dev/null::home.*ESTABLISHED.*[email protected].*moon.strongswan.org::YES
|
||||
dave:: ipsec status 2> /dev/null::home.*ESTABLISHED::NO
|
||||
carol::ping -c 1 PH_IP_ALICE::64 bytes from PH_IP_ALICE: icmp_.eq=1::YES
|
||||
|
||||
@@ -11,7 +11,7 @@ moon:: cat /var/log/daemon.log::EAP_TTLS phase2 authentication of 'carol@strongs
|
||||
moon:: cat /var/log/daemon.log::authentication of '[email protected]' with EAP successful::YES
|
||||
moon:: cat /var/log/daemon.log::EAP method EAP_TTLS failed for peer [email protected]::YES
|
||||
moon:: ipsec status 2> /dev/null::rw-eap.*ESTABLISHED.*[email protected]::YES
|
||||
moon:: ipsec status 2> /dev/null::rw-eap.*ESTABLISHED.*[email protected]::NO
|
||||
moon:: ipsec status 2> /dev/null::rw-eap.*ESTABLISHED.*dave@strongswan.org::NO
|
||||
carol::ipsec status 2> /dev/null::home.*ESTABLISHED::YES
|
||||
dave:: ipsec status 2> /dev/null::home.*ESTABLISHED::NO
|
||||
carol::ping -c 1 PH_IP_ALICE::64 bytes from PH_IP_ALICE: icmp_.eq=1::YES
|
||||
|
||||
@@ -2,6 +2,6 @@ Using <b>[<protocol>/<port>]</b> selectors in the
|
||||
<b>local_ts</b> and <b>remote_ts</b> child parameters, three IPsec tunnels
|
||||
between the roadwarrior <b>carol</b> and the gateway <b>moon</b> are defined.
|
||||
The first CHILD_SA is restricted to ICMP request packets, the second
|
||||
covers ICMP reply pachets and the third TCP-based FTP and SSH connections.
|
||||
covers ICMP reply packets and the third TCP-based FTP and SSH connections.
|
||||
The established tunnels are tested by <b>carol</b> by first pinging <b>alice</b>
|
||||
behind <b>moon</b> and then setting up an SSH session to the same client.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
The roadwarriors <b>carol</b> and <b>dave</b> set up a connection to gateway <b>moon</b>.
|
||||
At the outset the gateway authenticates itself to the clients by sending
|
||||
an IKEv2 <b>RSA signature</b> accompanied by a certificate.
|
||||
The roadwarrios then use the <i>Extensible Authentication Protocol</i>
|
||||
The roadwarriors then use the <i>Extensible Authentication Protocol</i>
|
||||
in association with an <i>MD5</i> challenge and response protocol
|
||||
(<b>EAP-MD5</b>) to authenticate against the gateway <b>moon</b> and includes
|
||||
a <b>Postquantum Preshared Key (PPK)</b> that's also mixed into the
|
||||
|
||||
Reference in New Issue
Block a user