[An Interesting discussion on relative merits here.]
A router that is responding to an incoming VPN connection needs to authenticate that connection to ensure is from a legitimate source, and not from a hacker. The IPsec protocol uses either a PSK or a certificate for authentication. You have to choose one or the other if you want the excellent overall usability and security offered by IPsec. But which should you choose?
PSK vs Cert
NCSC state that certificates are to be preferred for IPsec authentication. This is all very well, but implementing a proper PKI with auto-enrolment and revocation is a major undertaking. We are trying to keep things simple without compromising security. Fortunately, the NSCS acknowledge this and provide guidance for those organisations that wish to continue using PSKs. We will look at implementing both PSK and Certs for your IPsec VPN as simply and securely as possible.
Pre-shared keys
Pre-shared keys (PSKs) are ‘something you know’ from an authentication standpoint. They are easy to use and are very secure if used properly. If they are long and strong (20 random characters), kept secret (not stored anywhere that anyone else can see them) and IT staff roll out the VPNs to users’ devices then the PSK is safe from being learned by cyber-criminals. Users cannot see them or even find them if they look. However, if PSKs are not kept secret they can be given away to a cyber-criminal who can then start to mount an attack. PSKs can also be difficult to change once implemented.
Certificates
Certificates are ‘something you have’. They are created by an IT admin and distributed to users’ devices (eg their laptop). The device needs the certificate to connect; without it the connection will fail. Certs do away with PSKs and even usernames/passwords altogether which reduces the risk of credentials being copied or phished. This is why the NCSC prefer them. However, they are complicated to deploy properly (although some routers offer a simple internal PKI that helps).
Note on IPsec authentication
IPsec uses either PSK or Certs for authentication.
- S2S VPNs use one or the other. Each tunnel can have its own unique key or cert
- Dial in VPNs use one or the other but can sometimes be combined with a username/password.
Which to choose?
We believe that simple, well-implemented solutions can be at least as good as, if not better than, more complex ones. We have chosen solutions that maximise supportability while not compromising security.
For dial-up, if you want to use IKEv2 then combine a username/password with a self-signed Root cert. Both the username/password and the cert are needed to connect.
- Use a self-signed Root CA on the router
- Use EAP/MS-CHAPv2 for authentication, which keeps a username/password element
- Do not let users know their password
- Disable the user account on the router to prevent connection
- No need to export the private key – less risk of it being duplicated.
If you want to use L2TP/IPsec then combine a username/password with a PSK. Both the username/password and PSK are needed to connect.
- Use a long, strong (20 random character) PSK
- Use MS-CHAPv2 for authentication, which keeps a username/password element
- Do not let users know their password or the PSK
- Disable the user account on the router to prevent connection
- Keep the PSK secret
For S2S tunnels you can use IKEv1 or IKEv2, each with certs or PSK. If using PSK,
References
NCSC recommend 128-bit entropy for PSKs. Assuming random characters, this translates to a 20-byte PSK:
