I'd like to configure an IKEv2 VPN gateway for multiple remote users to access a private network.

I have a test setup where the responder authenticates itself with a self-signed certificate. The initiator authenticates with a username and password.

A couple issues:

  • The certificate is overcomplicated. I'll not be setting up a proper PKI, so a self-signed certificate that must be distributed to each client and configured to be trusted amounts to a pre-shared key (PSK) while being substantially harder to generate and administer.
  • The initiator is authenticated only by a username and password, and so an outside attacker can easily attempt to guess weak or compromised passwords.

Short of deploying a proper PKI, I'd prefer to perform mutual authentication of the initiator and responder hosts through a PSK. This key would be securely distributed to all users. Outside attackers would not have the PSK and so a weak or compromised password is insufficient for access. The username & password authentication allows identification and authorization of a specific user against an existing directory system, without the need for generating and distributing unique keys for each user.

Is such a thing possible with IKEv2? As far as I can tell, it was possible through Xauth in IKEv1. But for IKEv2 I'm not so sure: on a cursory read of RFC 5996, section 2.16, it seems this may not be the case. Username & password authentication would happen through some EAP method, and:

An initiator indicates a desire to use EAP by leaving out the AUTH payload from the first message in the IKE_AUTH exchange. (Note that the AUTH payload is required for non-EAP authentication, and is thus not marked as optional in the rest of this document.)

That seems to suggest the initiator can use only one of EAP (username & password) or PSK.

Although the question is about the IKEv2 protocol, I intend to implement the responder end with strongswan, so any additional expertise there would be appreciated.

  • Maybe with EAP-TTLS + MD5 client auth? – Andrew Domaszek Mar 16 '18 at 14:18
  • strongswan ref page: strongswan.org/testing/testresults/ikev2/rw-eap-ttls-only – Andrew Domaszek Mar 16 '18 at 14:21
  • hmm, that says "strong mutual authentication", but isn't the client authenticated only by a password (albeit, protected within TLS?) – Phil Frost Mar 16 '18 at 16:12
  • The "PSK" in that case would be a shared private RSA key and cert. The server would have its own key and cert. It doesn't require PKI because it's only one cert shared among all clients. Then the clients individually authenticate with a user/password. – Andrew Domaszek Mar 17 '18 at 14:44

Client and server authentication in IKEV2 are unrelated. So in theory, you can authenticate the server with a PSK and the client with EAP. However, the RFC states the following regarding EAP authentication:

In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 3748 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public-key-signature-based authentication of the responder to the initiator.

So combining PSK server authentication with EAP client authentication is not compliant with the RFC. However, it is possible to configure it with strongSwan. But note that most clients won't allow this combination.

Many roadwarrior clients actually don't support PSK authentication at all as it is a potential security risk in such scenarios if the same PSK is used with multiple clients, because all clients that know the PSK are in theory able to impersonate the server.

I have a test setup where the responder authenticates itself with a self-signed certificate.

Why not use Let's Encrypt?

The initiator is authenticated only by a username and password, and so an outside attacker can easily attempt to guess weak or compromised passwords.

Using a PSK to authenticate the server won't change that. You'd need to add a second factor to the client authentication to do anything about this (i.e. use a certificate or PSK first and then do EAP). However, this requires support for RFC 4739, which many clients lack (strongSwan supports it, though).

  • Let's encrypt is a good idea for the server, though it still leaves me with the issue of the clients. Sounds like if I want to limit myself to things with broad, native client support, it's either passwords with something like EAP-MSCHAPv2 (which will be compromised the moment I have a user with "password123") or issuing certificates to users. Is that accurate? – Phil Frost Mar 17 '18 at 1:55
  • Yes, correct. Depending on the client distributing certificates can relatively easily be accomplished. For instance, iOS/macOS and strongSwan's Android client support configuration profiles with encrypted PKCS#12 containers embedded. Only Windows requires manual installation (or perhaps a PowerShell script). – ecdsa Mar 19 '18 at 9:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.