cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2583
Views
5
Helpful
3
Replies

IPSec Authentication using X509 Certificates

charlie722
Level 1
Level 1

When setting up IPSec VPNs to use Digital Certificates instead of Pre-Shared Keys for authentication, I'm concerned that there doesn't seem to be the same level of unique assurance that the remote endpoint is genuine. I can parse the Subject Name, Common Name etc from the Certificate and apply certain rules, but this relies on being sure that the Certificate has not been obtained maliciously or from a rogue CA.

 

When using a unique Pre-Shared Key which has been exchanged by telephone call for instance, it's highly unlikely the key has been stolen or compromised. I don't seem to have the same level of assurance when I just set up rules to check that the Common Name on the Certificate matches the hostname on the IKE Peer device, for instance.

 

Am I missing something in the way I'm thinking this is set up?

 

When using Digital Certificates, what other methods of authentication or filtering do I need to put in place to give me absolute assurance that this sort of Man In The Middle attack can't be carried out?

 

Thanks in advance

Charlie R.

1 Accepted Solution

Accepted Solutions

There are many things to consider:

1) Strength of the VPN:

Especially when PSKs are negotiated by phone, they are often short and not very complex. That can weaken the crypto. Given that the VPN-device doesn't have bugs in the random-number-generator, VPNs based on certificates don't have this problem. If you use really long and complex pre-shared keys (and all your crypto-settings are good), both the PSK- and the certificate-based VPNs will be probably the strongest link in your whole security-chain.

 

2) Security of the certificate/PSK:

You have to make sure that your device is not compromised. If someone unauthorized can access the VPN-device, there is the possibility that the PSK or private key can be stolen. PSK-Encryption will give a a strong countermeasure and on routers make sure that your keys are non-exportable. All-in-all, PSKs can give you here a little more security.

 

3) Manageability of the Authentication:

A PSK should only be used for one VPN-connection. If you have many of them, managing them could become a nightmare and it leads many admins to use wildcard-PSKs which is considered a really bad practice.

The CA will play a very important role. Usually private PKIs are used for IPsec-VPNs. But the PKI has to be hardened, secured and managed in a secure way. If you can guarantee that, it will give you good security and the possibility to easily revoke certificates for devices that shouldn't have any more access.

For certificates you can manage an automatic or manual re-enrollment to change the certificate and optionally the private key. A PSK is unlikely to be changed after the PSK gets established.

 

4) Administrative domain of the VPN-peer:

If you configure a VPN between devices of different administrative domains (e.g. to a partner-organization), you often have no choice and have to use PSKs. The other party will unlikely trust your CA and you should not trust their CA. Sometimes you have the option to authenticate with certificates by importing the remote certificate, but that needs to be evaluated if supported on both ends.

If the devices are all under your administration, both choices are valid and you should consider wisely what you choose.

 

Conclusion?

I completely disagree with the often stated "certificates are more secure that PSKs". But if implemented in the right way, they can increase the security of your overall solution dramatically. At least compared to the very often seen inadequate usage of PSK.

View solution in original post

3 Replies 3

Hi @charlie722

 I desagree from you on the statement that certificate is more vulnerable then pre-shared keys.

 Security based on certificates usually are the most secure. It gives you the possibility to use SCEP server which is able to validade de trustpoint when issuing the certificate. You can't have this with psk.

 Man-in-midle attack for IPSec tunnel I don't think is possible.

 

 

 

-If I helped you somehow, please, rate it as useful.-

There are many things to consider:

1) Strength of the VPN:

Especially when PSKs are negotiated by phone, they are often short and not very complex. That can weaken the crypto. Given that the VPN-device doesn't have bugs in the random-number-generator, VPNs based on certificates don't have this problem. If you use really long and complex pre-shared keys (and all your crypto-settings are good), both the PSK- and the certificate-based VPNs will be probably the strongest link in your whole security-chain.

 

2) Security of the certificate/PSK:

You have to make sure that your device is not compromised. If someone unauthorized can access the VPN-device, there is the possibility that the PSK or private key can be stolen. PSK-Encryption will give a a strong countermeasure and on routers make sure that your keys are non-exportable. All-in-all, PSKs can give you here a little more security.

 

3) Manageability of the Authentication:

A PSK should only be used for one VPN-connection. If you have many of them, managing them could become a nightmare and it leads many admins to use wildcard-PSKs which is considered a really bad practice.

The CA will play a very important role. Usually private PKIs are used for IPsec-VPNs. But the PKI has to be hardened, secured and managed in a secure way. If you can guarantee that, it will give you good security and the possibility to easily revoke certificates for devices that shouldn't have any more access.

For certificates you can manage an automatic or manual re-enrollment to change the certificate and optionally the private key. A PSK is unlikely to be changed after the PSK gets established.

 

4) Administrative domain of the VPN-peer:

If you configure a VPN between devices of different administrative domains (e.g. to a partner-organization), you often have no choice and have to use PSKs. The other party will unlikely trust your CA and you should not trust their CA. Sometimes you have the option to authenticate with certificates by importing the remote certificate, but that needs to be evaluated if supported on both ends.

If the devices are all under your administration, both choices are valid and you should consider wisely what you choose.

 

Conclusion?

I completely disagree with the often stated "certificates are more secure that PSKs". But if implemented in the right way, they can increase the security of your overall solution dramatically. At least compared to the very often seen inadequate usage of PSK.

Thanks Karsten, this has confirmed my thoughts about the Pros and Cons of using PKI in this role. As with a lot of crypto, the devil is in the implementation detail - but your point about being able to renew remote certificates and keys more easily with PKI than swapping PSKs out, is a good one. 

 

Thanks all for your replies - 

Charlie

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: