1. Home
  2. Cisco Systems
  3. Why use diffie-hellman in IPSec when using a PSK?

Why use diffie-hellman in IPSec when using a PSK?

When setting up a site-to-site vpn, phase 1 of the IKE includes the creation of a public/private key pair by diffie-hellman and then the exchange of public keys with the other end of the vpn tunnel. Once the public keys have been exchanged, a symmetric key is created from your private key and the public key you just received from the device at the end of the vpn tunnel.

My question is this "why is this done?"

Assuming you are using a pre-shared (symmetric) key, why go through all this to create another symmetric key? Why not just use the pre-shared key to encrypt/decrypt everything that goes into or comes out of the tunnel?

I'm sure there is a reason but I've have not been able to find a satisfactory explanation online. If there is a better group for me to post this to please let me know.

TIA

Reply to
bradmbreer
Loading thread data ...

Hi,

Diffie Helman uses a public / private key algorithm to share symmetric keys. Symmetric keying algorithms provide the capability to achieve greater throughput when encrypting & decrypting data than that of asymetric keys. Skimming through the Cisco VPN guide:

1) Peers create their public / private keys 2) Each peer shares it's public key with it's peer 3) Each peer takes it's private key & the peers public key and runs them through the DH algorithm 4) The output on each side = same 5) The symetric key created by 1 x peer is then encrypted using the output from (4) 6) The remote peer decrypts the symmetric key using the same derived key (4) 7) Both sides use this shared secret key to encrypto / decrypt the data

Importnant to remember that this 'shared secret key' is nothing to do with the authentication of the peer that takes place in the closing stages of IKE / ISAKMP Phase 1.

Hope that helps.

Regards

Darren

Reply to
Darren Green

Darren,

I understand the decreased workload on a CPU when using a symmetric key as opposed to a asymmetric key. I also understand the Diffie- Hellman process as you listed above from the Cisco VPN guide. What I don't understand is why IKE does this when it already has a symmetric key, ie. the pre-shared key configured with the Cisco command "pre- shared-key xxxxxxx" while in ipsec configuration mode.

What's the point of configuring a pre-shared key if IKE is simply going to generate a new one for each SA? Maybe I'm confused as to what the pre-shared-key xxxxxxx is used for.

Reply to
bradmbreer

In article , snipped-for-privacy@gmail.com writes: | Darren, | | I understand the decreased workload on a CPU when using a symmetric | key as opposed to a asymmetric key. I also understand the Diffie- | Hellman process as you listed above from the Cisco VPN guide. What I | don't understand is why IKE does this when it already has a symmetric | key, ie. the pre-shared key configured with the Cisco command "pre- | shared-key xxxxxxx" while in ipsec configuration mode.

One reason is to limit the total amount of data sent under a given key, i.e., the total amount of data available to attack that key and also the total amount of data compromised if an attack succeeds. A perhaps more subtle reason is that if you do things right the protection can have the property that even if you record the entire conversation and also subsequently obtain all the static keying material from both ends you still can't decrypt the data.

Dan Lanciani ddl@danlan.*com

Reply to
Dan Lanciani

Thanks Dan! That certainly makes sense.

Reply to
bradmbreer

What I

I believe you are referring here to the preshared key that you are manually entering on each peer. If so, this is for authentication of the peer only, not for encrypting / decrypting data.

In IKE phase 1 (Main Mode) you have 3 x exchanges of 2 x packets.

1st Exchange - ISAKMP transforms compared 2nd Exchange - Diffie Helman 3rd Exchange Peer Authentication - Each peer will use the key you have manually entered to validate each other.

Then IKE / ISAKMP Phase 2 begins (Quick Mode).

Regards

Darren

Reply to
Darren Green

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.