The Internet Key Exchange v1 protocol (RFC 2409) has a vulnerability in the authentication mode with pre-shared keys in the main mode of operation.
I don't think this is really a CVE item. PSK's are not passwords, even if people keep using them like that. RFC 7296 on IKEv2 states this in _three_ different places: https://tools.ietf.org/html/rfc7296 Note that it is a common but typically insecure practice to have a shared key derived solely from a user-chosen password without incorporating another source of randomness. This is typically insecure because user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks and these attacks are not prevented in this authentication method. (Applications using password-based authentication for bootstrapping and IKE SA should use the authentication method in Section 2.16 [tools.ietf.org], which is designed to prevent off-line dictionary attacks.) The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store the value prf(Shared Secret,"Key Pad for IKEv2"), which could not be used as a password equivalent for protocols other than IKEv2. As noted above, deriving the shared secret from a password is not secure. This construction is used because it is anticipated that people will do it anyway. When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social-engineering attacks, among others. Perhaps it is time to sunset PSK's for IKE altogether because people don't seem to be able to do this securely. Note that I'm not convinced the attack works against IKEv2, since the PSK isn't mixed into the KEYMAT generation. There is only the AUTH payload being signed so there is no oracle to confirm PSK guesses on the AUTH payload. I would love to hear from the authors how they believe this is possible in IKEv2
Acknowledgments: Name: CERT
How about: PSK based authentication should only be used when the randomness and confidentially of the shared secret can be guaranteed. PSKs should also not be used as Group Secrets, where the security of the PSK is only as strong as the weakest participant in the group. Public Key or EAP authentication methods should be used whenever possible. If PSK must be used, it is essential to ensure the shared secret has a high degree of randomness and is not derived from a password with low entropy, as specified clearly in the IKEv2 specification in RFC 7296. To use passwords for authentication of IKE/IPsec peers, the IKEv2 protocol supports various methods that are not based on (inherently weak) PSKs and which are not vulnerable to offline dictionary attacks: RFC 5998: EAP-Only Authentication in IKEv2 RFC 6617: Secure Pre-Shared Key (PSK) Authentication for IKE RFC 6631: Password Authenticated Connection Establishment with IKEv2 RFC 6628: Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2
note that the following statement of the advisory is incorrect: For the main mode however, only an online attack against PSK authentication was thought to be feasible. See my notes above on this. Hopefully this can still be corrected by the authors of the CVE.
It's public at https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf
I put an initial write up at https://libreswan.org/wiki/FAQ#Libreswan_is_not_vulnerable_to_CVE-2018-5389_.28.22Practical_Attacks_on_IPsec_IKE.22.29
(In reply to Doran Moppert from comment #12) > Statement: > Perhaps append to the statement: The research paper that describes the problems of using weak PSKs also listed another security issue with respect to RSA keys that has different CVE numbers. Libreswan is not vulnerable to those attacks as it requires IKEv1 using either ("Encryption with RSA" (value 5) or "Revised encryption with RSA" (value 6). Both of these modes are not implemented by libreswan.
Statement: PSK based authentication should only be used when the randomness and confidentially of the shared secret can be guaranteed. PSKs should also not be used as Group Secrets, where the security of the PSK is only as strong as the weakest participant in the group. Public Key or EAP authentication methods should be used whenever possible. If PSK must be used, it is essential to ensure the shared secret has a high degree of randomness and is not derived from a password with low entropy, as specified clearly in the IKEv2 specification in RFC 7296. To use passwords for authentication of IKE/IPsec peers, the IKEv2 protocol supports various methods that are not based on (inherently weak) PSKs and which are not vulnerable to offline dictionary attacks: RFC 5998: EAP-Only Authentication in IKEv2 RFC 6617: Secure Pre-Shared Key (PSK) Authentication for IKE RFC 6631: Password Authenticated Connection Establishment with IKEv2 RFC 6628: Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 As implementations supporting IKE assume the security of provided PSKs, and no mechanism within the protocol allows for password-stretching, we do not anticipate any software fixes becoming available. The research paper that describes the problems of using weak PSKs also listed another security issue with respect to RSA keys that has different CVE numbers. Libreswan is not vulnerable to those attacks as it requires IKEv1 using either ("Encryption with RSA" (value 5) or "Revised encryption with RSA" (value 6). Both of these modes are not implemented by libreswan.
External References: https://www.kb.cert.org/vuls/id/857035