Bug #8667

VU#857035 - IKE Protocol Vulnerability

Added by Jim Pingle 8 months ago. Updated 7 months ago.

Very High
Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
Affected Architecture:


From CERT. There may not be much we can do here but wait for an update to strongSwan if it's even viable (see conclusion below). If nothing else, we can strengthen the wording of our recommendations for using Pre-Shared Keys as mentioned in but also in the GUI in addition to the documentation.

Assigning to me so I can handle the docs until we hear more from upstream.

CERT/CC has received a report of a vulnerability in the IKEv1 protocol in the authentication mode with pre-shared keys in the main mode of operation. CERT/CC has reserved CVE-2018-5389 for this vulnerability.

Details from the original report have been included below. We have also attached the PoC source code from the researchers. Please note that the researchers plan to publish their work on August 13th. CERT/CC currently plans to also publish at the same time.

Due to the nature of this vulnerability (please see the Conclusion from the researchers), this notification is primarily for awareness. If you do plan on taking action regarding this report, please let us know.

CERT/CC is tracking this report as VU#857035. Please retain VU#857035 in the subject of any email sent to CERT/CC regarding this report.


Vulnerability Analysis Team
CERT Coordination Center /


Internet Key Exchange v1 is specified in RFC 2409 and used to negotiate keys between two parties for an IPsec connection. One of the specified modes of authentication (we believe it to be the most used mode) uses pre-shared keys (PSKs), i.e. passwords.
There are two protocol modes, the "main mode" and the "aggressive mode". It is well known, that the aggressive mode of IKEv1 PSK is vulnerable to offline dictionary or brute force attacks by simply eavesdropping all 3 messages of the IKEv1 PSK handshake. For the main mode however, only an online attack against PSK authentication was thought to be feasible. We found out that this is not the case.
Our attacker model is an active network attacker. The attacker waits for the victim to initiate an IKE handshake with a responder. If victim and responder already have an active connection, the attacker may enforce a new handshake by dropping all packets of the already established connection, which will eventually lead to a new handshake.
The following diagram shows the message flow:
Initiator Responder
---------- -----------
1. HDR, SA --> (plain)
<-- 2. HDR, SA (plain)
3. HDR, KEi, Ni --> (plain)
<-- 4. HDR, KEr, Nr (plain)
5. HDR*, IDii, HASH_I --> (partially encrypted)
<-- 6. HDR*, IDir, HASH_R (partially encrypted)
Now an explenation of the messages:
1. Contains a header and security association set
contains an initiator cookie
additional data (like version, length, etc)
security association:
contains security options, supported by the initator
it also specifies the prefered authentication methods
2. The responder answers with a packet containing an updated header and its security assocication
contains the responder cookie used later
additional data (like version, length, etc)
security association:
contains security options, supported by the responder
it also specifies the prefered authentication methods
3. The initator sends a message that contains his generated Diffie-Hellman public share KEi and his nonce Ni
4. The responder sends a message that contains his generated Diffie-Hellman public share KEr and his nonce Nr
5. The initiator does the following computations:
generates the shared Diffie-Hellman secret
uses his pre-shared key (password), (initiator and responder) nonces and (initiator and responder) cookies in order to generate 4 keys
see below how these keys are generated
the last generated key is used to encrypt the ID of the initator (IDii) and a hash (HASH_I) value
the hash is not relevant for the attack
the encryption is denoted as the * in the diagram (as explained in the RFC)
The attack works as follows:
In order to generate the correct encryption key the attacker needs to know the following values:
1. Both cookies (retrieved from the header of message 2)
2. Both nonces (retrieved from message 3 and 4)
3. Initiator's Diffie-Hellman public share KEi (retrieved from message 3)
4. Responder's Diffie-Hellman private share (generated by attacker since the attacker plays the responder role)
5. Shared Diffie-Hellman secret (computed from KEi and the private Diffie-Hellman share of the responder) 
6. The pre-shared-key (unknown to the attacker)
The keys are generated as follows (Python code):
k = computeKey(psk, initNonce, respNonce)
k_0 = computeKeyK0(k, dhSecret, initCookie, respCookie)
k_1 = computeKeyK1(k, k_0, dhSecret, initCookie, respCookie)
k_2 = computeKeyK2(k, k_1, dhSecret, initCookie, respCookie)
There are also some constant strings needed, but we removed them for clarity
It is clear that the only unknown value is the pre-shared-key psk.
If the pre-shared-key is weak, an attacker may use a dictionary or brute force attack to guess the psk and compute key candidates
These candidates can be used to try a decryption of the encrypted IDii and HASH_I from message 5
The attacker knows to have found the correct psk if the known values of IDii are found in the first bytes of the decrypted message
the IDii looks like the following when using the well-known IPsec implementation strongSWAN
ID_init fields: ID_Type || Protoco_ID || PORT || ID_DATA (IP address)
ID_init values: 01 || 00 || 00 00 || c0 a8 00 64
Note that the Port and IP address are known to the attacker, as well as the IDType and ProtocolID
We tested the attack on strongSwan 5.5.1, Linux 4.9.0-4-amd64
We furthermore used scapy3 and python 3.6
We attached the source code of our proof-of-concept for verification
Vulnerable Implementations (as far as we know):
strongSWAN 5.5.1 PSK main mode
all IKEv1 RFC 2409 compliant implementations which allow the authentication mode PSK and main mode of operation, e.g.
Hardware: Cisco, Huawei, MikroTik, Netgear, Juniper, Checkpoint, Palo Alto Networks, Ubiquiti, TP-Link, AVM Fritzbox, etc.
Software: strongSwan, OpenSwan, LibreSwan, OpenBSD, IBM IPsec, Microsoft IPsec, Apple IPsec, KAME, Unicoi Systems
In our opinion this attack is also possible against IKEv2 although the protocol flow is different
The reason is that an attacker acting as responder would get all required values to mount the dictionary/brute force attack
Due to time constraints we did not implement the attack against IKEv2
This is not an implementation bug and can most probably not be fixed in code without violating the RFC.
A direct countermeasure with existing implementations is to use cryptographically secure PSK values that resist brute force or dictionary attacks.
You may ask, why we are sending such a lenghty report just to say "use good passwords". The problem is that implementations and users dont expect this combination of modes to be weak.
For example, PSK authentication together with the aggressive mode of operation is known to be vulnerable. For that reason StrongSwan requires a configuration flag to be set in order to use this combination: "i_dont_care_about_security_and_use_aggressive_mode_psk = yes" (
Such a flag (or any other precautionary measure) does not exist for the main mode of operation.


#1 Updated by Steve Beaver 8 months ago

  • Status changed from New to This Sprint

#2 Updated by Jim Pingle 8 months ago

I rewrote the IPsec site to site doc and included information on generating a random and strong PSK, which will help here. I haven't seen any movement from upstream or heard back from CERT about what anyone may be doing to address this. Documenting the need for a strong PSK may be all we can do. Barring any news from usptream, the only other action we may need is to add stronger language to the PSK help in the GUI.

#3 Updated by Jim Pingle 8 months ago

  • % Done changed from 0 to 50

#4 Updated by Jim Pingle 8 months ago

  • Status changed from This Sprint to In Progress

#5 Updated by Jim Pingle 8 months ago

  • % Done changed from 50 to 90

PSK button and stronger GUI warning are in now, see d13966146f166536c2b3825cdfd9090f7f6022e7

All that remains is to see if anyone upstream (e.g. strongSwan) takes any action on this, and pull in any changes they make.

#6 Updated by James Dekker 8 months ago

On 2.4.4.a.20180802.1755 (gitsync'd to master), seeing the warning message about the PSK

This key should be long and random to protect the tunnel and its contents. A weak Pre-Shared Key can lead to a tunnel compromise.

Along with a button to generate a new alphanumeric Pre-Shared Key that is fifty-seven characters long.

#7 Updated by Jim Pingle 8 months ago

OK so all that's left here is to wait and see what, if anything, strongSwan may offer in response. Publication deadline for the research is August 13th, so if nothing comes up after that, we can close this.

#9 Updated by Jim Pingle 7 months ago

  • Status changed from In Progress to Resolved
  • Priority changed from Urgent to Very High
  • % Done changed from 90 to 100

Everything I'm reading says it can't be fixed in implementations since it's a protocol flaw. At this point I believe through documentation updates, GUI notes, and the PSK generate button we've done all we can to encourage best practices which mitigate the problem.

If that turns out to be wrong and strongSwan does find something that can be done, we can always pick up a patch later.

Also available in: Atom PDF