[strongSwan] PSK IKEv2 Client -> BlackBerry Z-10 [Gateway certificate w/PSK for client auth] fails
Karl Denninger
karl at denninger.net
Sat Apr 27 21:30:58 CEST 2013
Perusing the lists I see that this has come up before with the Playbook
and was never resolved. Perhaps I can obtain enough understanding to
fix this for everyone, or point someone to where the problem resides.
The configuration is StrongSwan 5.0.3 with the following in ipsec.conf:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
# Add connections here.
# Sample VPN connections
conn %default
keyingtries=1
keyexchange=ikev2
conn remote
left=%any
leftsubnet=0.0.0.0/0
right=%any
rightsourceip=192.168.2.0/24
rightid=karl at denninger.net
rightauth=psk
leftauth=pubkey
leftcert=genesis.pem
leftid=@genesis.denninger.net
auto=add
Ipsec.secrets contains:
#
# Our certificate for the gateway
: RSA genesis.pem
#
# Passwords
#
%any : PSK "TheSecret"
(Actually, no, it's not "TheSecret", but you get the idea.)
With ipsec.conf authenticating with "leftauth=psk" and BOTH gateway and
remote using the login of an email address (which can be anything) and
the PSK, /*it works*/.
When I try to use a machine certificate to authenticate the server after
loading my private CA into the Z10 and then connecting using that for
server identity (and a PSK for the client) _*instead*_ of a PSK for
both, it fails with this:
Apr 27 14:15:27 NewFS charon: 07[NET] received packet: from
208.54.70.231[26100] to 70.169.168.7[500] (400 bytes)
Apr 27 14:15:27 NewFS charon: 07[ENC] parsed IKE_SA_INIT request 0 [ SA
KE No N(NATD_S_IP) N(NATD_D_IP) ]
Apr 27 14:15:27 NewFS charon: 07[IKE] 208.54.70.231 is initiating an IKE_SA
Apr 27 14:15:27 NewFS charon: 07[IKE] remote host is behind NAT
Apr 27 14:15:27 NewFS charon: 07[IKE] sending cert request for "C=US,
ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA,
E=customer-service at cudasystems.net"
Apr 27 14:15:27 NewFS charon: 07[ENC] generating IKE_SA_INIT response 0
[ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
Apr 27 14:15:27 NewFS charon: 07[NET] sending packet: from
70.169.168.7[500] to 208.54.70.231[26100] (337 bytes)
Apr 27 14:15:28 NewFS charon: 14[NET] received packet: from
208.54.70.231[51135] to 70.169.168.7[4500] (332 bytes)
Apr 27 14:15:28 NewFS charon: 14[ENC] parsed IKE_AUTH request 1 [ IDi
CERTREQ AUTH CP(ADDR MASK DNS DNS NBNS NBNS VER) N(INIT_CONTACT)
N(MOBIKE_SUP) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
Apr 27 14:15:28 NewFS charon: 14[CFG] looking for peer configs matching
70.169.168.7[%any]...208.54.70.231[karl at denninger.net]
Apr 27 14:15:28 NewFS charon: 14[CFG] selected peer config 'remote'
*Apr 27 14:15:28 NewFS charon: 14[IKE] tried 1 shared key for '%any' -
'karl at denninger.net', but MAC mismatched [0 1]*
Apr 27 14:15:28 NewFS charon: 14[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Apr 27 14:15:28 NewFS charon: 14[IKE] peer supports MOBIKE
Apr 27 14:15:28 NewFS charon: 14[ENC] generating IKE_AUTH response 1 [
N(AUTH_FAILED) ]
Apr 27 14:15:28 NewFS charon: 14[NET] sending packet: from
70.169.168.7[4500] to 208.54.70.231[51135] (76 bytes)
I added the two additional debugging flags in the line highlighted to
get a handle on what was failing in the tests up above. The reason the
failure occurs is that that this test fails in psk_authenticator.c @ ~136:
if (auth_data.len && chunk_equals(auth_data, recv_auth_data))
{
DBG1(DBG_IKE, "authentication of '%Y' with %N
successful
",
other_id, auth_method_names, AUTH_PSK);
authenticated = TRUE;
}
key_chunk++;
The above test looking for the key match succeeds (otherwise the other
value would be incremented, and it is not.)
Inserting further debugging code shows that while the length of both of
those structures (auth_data and recv_auth_data) are identical (20 bytes)
the contents are indeed not identical, nor is there any part of them
that are identical.
If we're matching against %any for the PSK, however,/*why do we care
what the MAC address is*/ (assuming the error message is correct --
what's actually in that "auth_data" and "recv_auth_data" structure at
that point?)/**/
Again note that if I authenticate against a PSK for both left and right
it works -- that's all I changed on both client and server and I get this:
Apr 27 14:27:09 NewFS charon: 12[NET] received packet: from
208.54.70.231[26100] to 70.169.168.7[500] (400 bytes)
Apr 27 14:27:09 NewFS charon: 12[ENC] parsed IKE_SA_INIT request 0 [ SA
KE No N(NATD_S_IP) N(NATD_D_IP) ]
Apr 27 14:27:09 NewFS charon: 12[IKE] 208.54.70.231 is initiating an IKE_SA
Apr 27 14:27:09 NewFS charon: 12[IKE] remote host is behind NAT
Apr 27 14:27:09 NewFS charon: 12[IKE] sending cert request for "C=US,
ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA,
E=customer-service at cudasystems.net"
Apr 27 14:27:09 NewFS charon: 12[ENC] generating IKE_SA_INIT response 0
[ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
Apr 27 14:27:09 NewFS charon: 12[NET] sending packet: from
70.169.168.7[500] to 208.54.70.231[26100] (337 bytes)
Apr 27 14:27:10 NewFS charon: 14[NET] received packet: from
208.54.70.231[47985] to 70.169.168.7[4500] (332 bytes)
Apr 27 14:27:10 NewFS charon: 14[ENC] parsed IKE_AUTH request 1 [ IDi
AUTH CP(ADDR MASK DNS DNS NBNS NBNS VER) N(INIT_CONTACT) N(MOBIKE_SUP)
N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
Apr 27 14:27:10 NewFS charon: 14[CFG] looking for peer configs matching
70.169.168.7[%any]...208.54.70.231[karl at denninger.net]
Apr 27 14:27:10 NewFS charon: 14[CFG] selected peer config 'BB10'
Apr 27 14:27:10 NewFS charon: 14[IKE] authentication of
'karl at denninger.net' with pre-shared key successful
Apr 27 14:27:10 NewFS charon: 14[IKE] Auth_data: [20 {random string}]
recv_auth_data: [20 {same random string}]
Apr 27 14:27:10 NewFS charon: 14[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Apr 27 14:27:10 NewFS charon: 14[IKE] peer supports MOBIKE
Apr 27 14:27:10 NewFS charon: 14[CFG] no IDr configured, fall back on IP
address
Apr 27 14:27:10 NewFS charon: 14[IKE] authentication of '70.169.168.7'
(myself) with pre-shared key
Apr 27 14:27:10 NewFS charon: 14[IKE] IKE_SA BB10[1] established between
70.169.168.7[70.169.168.7]...208.54.70.231[karl at denninger.net]
Apr 27 14:27:10 NewFS charon: 14[IKE] scheduling reauthentication in 10178s
Apr 27 14:27:10 NewFS charon: 14[IKE] maximum IKE_SA lifetime 10718s
Apr 27 14:27:10 NewFS charon: 14[IKE] peer requested virtual IP %any
Apr 27 14:27:10 NewFS charon: 14[CFG] assigning new lease to
'karl at denninger.net'
Apr 27 14:27:10 NewFS charon: 14[IKE] assigning virtual IP 192.168.2.1
to peer 'karl at denninger.net'
Apr 27 14:27:10 NewFS charon: 14[IKE] CHILD_SA BB10{1} established with
SPIs cb36c83d_i 39abf852_o and TS 0.0.0.0/0 === 192.168.2.1/32
Apr 27 14:27:10 NewFS charon: 14[ENC] generating IKE_AUTH response 1 [
IDr AUTH CP(ADDR DNS) N(ESP_TFC_PAD_N) SA TSi TSr N(AUTH_LFT)
N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Apr 27 14:27:10 NewFS charon: 14[NET] sending packet: from
70.169.168.7[4500] to 208.54.70.231[47985] (284 bytes)
Ideas?
--
-- Karl Denninger
/The Market Ticker ®/ <http://market-ticker.org>
Cuda Systems LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130427/72e0e683/attachment.html>
More information about the Users
mailing list