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.
решение1
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, которого нет у многих клиентов (хотя strongSwan его поддерживает).