07-21-2014 08:02 PM
Hello,
Is pre-shared-key only used for authenticating the peer or used in computation of shared secret too? Is there any documentation that explains the entire process.
Solved! Go to Solution.
07-22-2014 09:13 PM
hi,
as per my VPN notes, both are used to build a bidirectional VPN tunnel. IKEv1 is used for legacy IPsec site-to-site VPNs:
IKEv1 Main mode (Phase 1) uses three pairs of messages (making six in total) between peers:
* Pair 1 consists of the IKEv1 security policies configured on the device: One peer (initiator) begins by sending one or more IKEv1 policies, and the receiving peer responds (responder) with its choice from the policies.
* Pair 2 includes DH public key exchange: DH creates shared secret keys using the agreed upon DH group/algorithm exchanged in pair 1 and encrypts nonces (a randomly generated number) that begin life by first being exchanged between peers. They are then encrypted by the receiving peer and send back to the sender and decrypted using the generated keys.
* Pair 3 is used for ISAKMP authentication: Each peer is authenticated and their identity validated by the other using pre-shared keys or digital certificates. These packets and all others exchanged from now on during the negotiations are encrypted and authenticated using the policies exchanged and agreed upon in pair 2.
07-22-2014 01:01 AM
Hi Zafar,
Could you please explain your question bit more in detail? what do you see as a difference in pre-shared and shared-secret?
Regards
Karthik
07-22-2014 07:52 AM
Hi Karthik,
My understanding is that diffie helman algo (http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) is used to get the shared/common secret at end of phase 1 but not sure where the pre-shared-key (defined with pre-shared-key command) is used in this scenario.
07-22-2014 10:57 AM
The pre shared key is used by the VPN peers to authenticate with each other at the beginning of the connection. After they have successfully authenticated then they begin the negotiation that will result in the shared/common secret used in the security association.
HTH
Rick
07-23-2014 02:24 AM
Hi Zafar,
See for example you define your Phase 1 parameters like this...
crypto ikev1 policy 100
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
and you are defining the pre-shared key in your tunnel-group configuration like this
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
ikev1 pre-shared-key *****
And more over phase 1 will encrypt the phase 2 negotiations and phase 2 will encrypt the actual data between two sites / LAN's.
With respect to DH.... whatever you have defined as group 2 is a DH value which is modulus of 1024 bit....
A Diffie-Hellman (DH) exchange allows participants to produce a shared secret value. The strength of the technique is that it allows participants to create the secret value over an unsecured medium without passing the secret value through the wire. There are five DH groups.
Group 1 is depreciated in most of the platforms.
Useful Document:
https://supportforums.cisco.com/document/105381/basic-l2l-configuration-platform-independent-approach
Regards
Karthik
07-22-2014 09:13 PM
hi,
as per my VPN notes, both are used to build a bidirectional VPN tunnel. IKEv1 is used for legacy IPsec site-to-site VPNs:
IKEv1 Main mode (Phase 1) uses three pairs of messages (making six in total) between peers:
* Pair 1 consists of the IKEv1 security policies configured on the device: One peer (initiator) begins by sending one or more IKEv1 policies, and the receiving peer responds (responder) with its choice from the policies.
* Pair 2 includes DH public key exchange: DH creates shared secret keys using the agreed upon DH group/algorithm exchanged in pair 1 and encrypts nonces (a randomly generated number) that begin life by first being exchanged between peers. They are then encrypted by the receiving peer and send back to the sender and decrypted using the generated keys.
* Pair 3 is used for ISAKMP authentication: Each peer is authenticated and their identity validated by the other using pre-shared keys or digital certificates. These packets and all others exchanged from now on during the negotiations are encrypted and authenticated using the policies exchanged and agreed upon in pair 2.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide