Project

General

Profile

Feature #2223

Change PSK lookup order for IKEv1 (first configs/identities, then IPs)

Added by Andreas Weigel over 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Category:
ikev1
Target version:
Start date:
16.01.2017
Due date:
Estimated time:
Resolution:
Fixed

Description

I posted this one on the [strongSwan-dev] mailing list, but unfortunately haven't received any reaction, yet.

Please also see the attached patch, which imho solves the issue.

Short Version

charon unnecessarily selects a wrong PSK in some cases:
  • A site-to-site connection using resolvable hostnames (e.g., DynDNS) as identities in /etc/ipsec.secrets and a Roadwarrior connection (using %any as remote peer identity)
  • Multiple site-to-site connections using resolvable hostnames as identities

The reason is that the first lookup is based purely on IP adresses and the method using potentially resolved hostnames is not used if some match is found in that first lookup.

Long Version (as on the mailing list)

  • 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)

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 the S2S1_5 connection is initiated remotely:

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.

The problem does not only exist if an %any identity is configured, but also with multiple hostnames given as identities (and at the same time an IP-address as local ID). In that case, the selected PSK depends on the order the PSKs are enumerated internally.

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 wrongly 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 even open up security problems in some way?

multi_psk_essential.patch (1.95 KB) multi_psk_essential.patch Patch to change order of PSK selection routines Andreas Weigel, 16.01.2017 15:07

Associated revisions

Revision e92d8a56 (diff)
Added by Tobias Brunner about 2 years ago

ikev1: First do PSK lookups based on identities then fallback to IPs

This provides a solution for configs where there is e.g. a catch-all %any
PSK, while more specific PSKs would be found by the identities of configs
that e.g. use FQDNs as local/remote addresses.

Fixes #2223.

History

#1 Updated by Tobias Brunner about 2 years ago

  • Tracker changed from Issue to Feature
  • Subject changed from charon selects wrong PSK (IKEv1) to Change PSK lookup order for IKEv1 (first configs/identities, then IPs)
  • Status changed from New to Feedback
  • Start date set to 16.01.2017

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.

It's definitely a more expensive lookup (DNS resolution required for all configured connections to sort them). Not sure if it has any other side-effects. At least our test suite runs through successfully (but there aren't that many PSK tests).

By the way, your patch changed the behavior as initiator (no lookup based on the IPs anymore). I pushed a fixed commit to the 2223-ikev1-psk-lookup branch.

#2 Updated by Andreas Weigel about 2 years ago

Thanks for your reply, and thanks for fixing the initiator part (which I have yet to understand, it's been some time that I looked into the sources).

With regard to the mentioned expensiveness: Could you elaborate? I thought that if connections are configured using IKEv1 and hostnames as identifiers, indeed at some point there has to be a DNS lookup, to find the correct configuration entry at least. But as far as I remember, the results are stored along with the configuration data, so this is not done for every incoming connection.

#3 Updated by Tobias Brunner about 2 years ago

I thought that if connections are configured using IKEv1 and hostnames as identifiers, indeed at some point there has to be a DNS lookup, to find the correct configuration entry at least.

FQDNs as identities are never resolved by charon, but if FQDNs are used as local/remote addresses these are resolved when peer configs are looked up. But that lookup happens later when the identities are known. With the patch the peer configs are now enumerated twice if PSKs are used.

But as far as I remember, the results are stored along with the configuration data, so this is not done for every incoming connection.

What results are you referring to?

#4 Updated by Andreas Weigel about 2 years ago

but if FQDNs are used as local/remote addresses these are resolved when peer configs are looked up. But that lookup happens later when the identities are known

Given the log from my original message and my memory, I think the peer config is looked up before the PSK is selected (see the log from my original message), i.e., before the identity is known because there is no other way for IKEv1.

What results are you referring to?

I meant the result of the DNS lookup. I agree -- with the patch -- the peer configuration data structure is enumerated twice, but no unnecessary DNS lookups are performed. IMHO, this is much better than selecting the wrong PSK due to not using available information.

Alternatively, one could try to do PSK lookup by IP first, but not accept results that represent a perfect match in that first iteration (meaning BOTH addresses match perfectly), then use peer config lookup and then again lookup by IP, accepting imperfect and %any matches. I remember that I could not come up with a satisfying solution for this, however.

#5 Updated by Tobias Brunner about 2 years ago

but if FQDNs are used as local/remote addresses these are resolved when peer configs are looked up. But that lookup happens later when the identities are known

Given the log from my original message and my memory, I think the peer config is looked up before the PSK is selected (see the log from my original message), i.e., before the identity is known because there is no other way for IKEv1.

No, that's an IKE config that's looked up (the log even says so). The peer config is later looked up when the identities are known.

What results are you referring to?

I meant the result of the DNS lookup. I agree -- with the patch -- the peer configuration data structure is enumerated twice, but no unnecessary DNS lookups are performed. IMHO, this is much better than selecting the wrong PSK due to not using available information.

Well, I suppose that depends on what you consider unnecessary DNS lookups. And it's still possible that the "wrong" PSK is selected. For instance, if the local and remote IPs are used with every secret in ipsec.secrets. To fix that the PSKs would have to be sorted, similar to the peer configs, by how well they match the given identities. But with the patch it's less of a problem as it allows using more specific selectors via identities before that stop-at-first-match behavior.

#6 Updated by Andreas Weigel about 2 years ago

Thanks for the clarification.

#7 Updated by Tobias Brunner about 2 years ago

  • Category changed from libcharon to ikev1
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Target version set to 5.5.2
  • Resolution set to Fixed

Also available in: Atom PDF