[strongSwan-dev] IKEv1: wrong PSK selected using Hostnames and Roadwarrior(s)

[Andreas Weigel]

First: I'm aware that this setup is probably not very common, but it
pops up in the wild and therefore concerns uns.

Setup:
One or more site-to-site PSK-connections based on hostnames (DynDNS)
A roadwarrior connection also based on PSK (e.g. for a small group)

Example configuration:
ipsec.conf:
conn "S2S1_5"
         ...
         keyexchange="ikev1"
         leftauth="psk"
         rightauth="psk"
         left="%any"
         right="foo.bar.org"
         leftid="172.16.5.55"
         rightid="@foo.bar.org"
         ...

conn "RW1_0"
         ...
         keyexchange="ikev1"
         leftauth="psk"
         rightauth="psk"
         compress="no"
         left="%any"
         ...

ipsec.secrets:
172.16.5.55 @foo.bar.org : PSK "PSK-S2S"
%any : PSK "PSK-RW"

I'm aware that it is not possible with IKEv1 to match the PSK directly
by the FQDN, because only the IP address of the remote peer is available.
However, strongswan is able to find the correct config by resolving the
FQDN to the correct address when remotely initiating the S2S1_5 connection:

277587|7587|2017-01-04T10:19:13.000+01:00|charon||04[CFG] looking for an 
ike config for 172.16.5.55...172.16.5.109
277588|7588|2017-01-04T10:19:13.000+01:00|charon||04[CFG] candidate: 
%any...foo.bar.org, prio 2076
277589|7589|2017-01-04T10:19:13.000+01:00|charon||04[CFG] candidate: 
%any...%any, prio 28
277590|7590|2017-01-04T10:19:13.000+01:00|charon||04[CFG] found matching 
ike config: %any...foo.bar.org with prio 2076

But then shortly afterwards fails to lookup the correct PSK:
277601|7601|2017-01-04T10:19:13.000+01:00|charon||04[CFG] selected 
proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
277602|7602|2017-01-04T10:19:13.000+01:00|charon||04[ENC] generating 
ID_PROT response 0 [ SA V V V ]
277603|7603|2017-01-04T10:19:13.000+01:00|charon||04[ENC] generating 
ID_PROT response 0 [ SA V V V ]
277604|7604|2017-01-04T10:19:13.000+01:00|charon||03[ENC] parsed ID_PROT 
request 0 [ KE No NAT-D NAT-D ]
277605|7605|2017-01-04T10:19:13.000+01:00|charon||03[ENC] parsed ID_PROT 
request 0 [ KE No NAT-D NAT-D ]
277606|7606|2017-01-04T10:19:13.000+01:00|charon||03[ENC] generating 
ID_PROT response 0 [ KE No NAT-D NAT-D ]
277607|7607|2017-01-04T10:19:13.000+01:00|charon||03[ENC] generating 
ID_PROT response 0 [ KE No NAT-D NAT-D ]
277608|7608|2017-01-04T10:19:13.000+01:00|charon||02[ENC] invalid ID_V1 
payload length, decryption failed?
277609|7609|2017-01-04T10:19:13.000+01:00|charon||02[ENC] invalid ID_V1 
payload length, decryption failed?
277610|7610|2017-01-04T10:19:13.000+01:00|charon||02[ENC] could not 
decrypt payloads
277611|7611|2017-01-04T10:19:13.000+01:00|charon||02[ENC] could not 
decrypt payloads
277612|7612|2017-01-04T10:19:13.000+01:00|charon||02[IKE] message 
parsing failed

I delved into the sources and as far as I can see, the problem
results from the order in which different methods to lookup the shared
key are applied in src/libcharon/sa/ikev1/phase1.c in the
lookup_shared_key function.

First, the ID selectors from the ipsec.secrets file are directly
matched against the local and remote IP address. If a match is found,
the key is found and returned. With the setup above, the %any of the
roadwarrior setup is always matched, the "PSK-RW" key is chosen and
consequently the decryption of the third phase-1 message fails at
the responder.

However, in the same function, there is also a lookup implemented using
the rightid of the config identified by resolving the hostname, it is
just not used because charon thinks it has already found the correct PSK.

My suggestion is to change the order of lookup methods to first consider
the rightid derived from a correctly identified config (using the
resolved IP address) and only use the plain IP address matching if no
PSK is found that way. See the attached patch.

With our setups, this solves the problem of charon picking the wrong PSK
for the given setup and as far as I can see should not have any negative
impact (but I probably do not see very far or clear). Are there any
implications I am missing that can harm the operation for
other configurations or open up security problems in any way?

Kind Regards
Andreas Weigel

-- 
Mit freundlichem Gruß / Best regards,

Andreas Weigel
UTM Backend Developer

Securepoint GmbH
Salzstrasse 1
D-21335 Lüneburg

https://www.securepoint.de

Tel.: +49(0)413124010
Fax: +49(0)4131240118

Geschäftsführer: Lutz Hausmann, Claudia Hausmann
Amtsgericht Lüneburg HRB 1776
USt.-ID-Nr.: DE 188 528 597

-------------- next part --------------
A non-text attachment was scrubbed...
Name: psk_lookup.patch
Type: text/x-patch
Size: 2784 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20170109/c27d2a43/attachment.bin>