[strongSwan] PSK IKEv2 Client -> BlackBerry Z-10 [Gateway certificate w/PSK for client auth] fails
Karl Denninger
karl at denninger.net
Sun Apr 28 04:14:28 CEST 2013
I found the problem -- it's on the Z-10's end. Disregard please; this
has to go up the chain with BB.
On 4/27/2013 2:30 PM, Karl Denninger wrote:
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
--
-- 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/ebc29cf2/attachment.html>
More information about the Users
mailing list