IKE, is the initial negotiation phase, in which two VPN endpoints agree on methods which will be used to provide security for IP traffic. IKE helps in managing connections, with the help of Security Associations,
The other important part is IP data in transfer, using encryption and authentication methods agreed during IKE negotiation. This can be with help of protocols like IPsec protocols ESP, AH, or combination of both.
The flow of events is mentioned below:
IKE negotiates how IKE should be protected
IKE negotiates how IPsec should be protected
IPsec moves data in the VPN
IKE,Internet Key Exchange:
The two things which are required are encryption and authentication algorithms, and the corresponding keys. The Internet Key Exchange protocol, IKE, is used as a method to distribute "session keys", and providing a way for the VPN endpoints to decide how to protect data.
IKE has three main tasks:
Provide a means for the endpoints to authenticate each other
Establish new IPsec connections (create SA pairs)
Manage existing connections
The flow of events are mentioned below:
Negotiate how IKE should be protected
Negotiate how IPsec should be protected
Derive some fresh keying material from the key exchange in phase-1, to provide session keys to be used in the encryption and authentication of the VPN data flow
IKE Phase-1 - IKE Security Negotiation
An IKE negotiation is performed in two phases. The first phase, phase-1, is used to authenticate the two VPN gateways or VPN Clients to each other, by confirming that the remote gateway has a matching Pre-Shared Key.
As you do not want to publish negotiation in plaintext, we first agree upon a way of protecting the rest of the IKE negotiation. This process is carried by the initiator sending a proposal-list to the responder. When this has been done, and the responder accepted one of the proposals, we try to authenticate the other end of the VPN to make sure it is who we think it is, as well as proving to the remote gateway that we are who we are.
Authentication can be accomplished through Pre-Shared Keys, certificates or public key encryption. Pre-Shared Keys is the most common authentication method today.
The Internet Security Association and Key Management Protocol (ISAKMP) Phase 1 configurations do not match on the PIX/ASA Firewall peers.
To resolve this issue, check the isakmp policy command statements on both peers.
This is a sample output:
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 1
isakmp policy 10 lifetime 86400
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
The PIX Firewall can have multiple Phase I policies, as shown in this example with policies 10 and 20.
The PIX Firewall goes through the list until the policy matches what is configured on the peer.
If no match is found, you will see debug errors about Phase 1 attributes mismatch.