Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

How are IKE Phase 1 messages sent in Main Mode?

0

0

Article ID: KB6393 KB Last Updated: 27 Aug 2010Version: 3.0
Summary:
How are IKE Phase 1 messages sent in Main Mode?
Symptoms:
Internet Key Exchange (IKE) Main Mode Phase 1
Solution:

Note: This article applies to ScreenOS 4.0 and higher.

IKE Phase 1 messages are sent in the following manner:

Image of example

Message 1 and Message 2:

Cookies are exchanged to prevent forms of IP spoofing, and to create a Security Association (SA) proposal list. Cookies are pseudo-random numbers 8 bytes in length that are generated by the sending machine, (I=Initiator) and receiving machine (R=Receptor). Every cookie is unique to the machine and to each particular exchange. This guarantees uniqueness and replay protection by hashing the sender's IP address, port, protocol and timestamp, which results in a unique identifier known only to the originator. The receptor will insert its known cookie in message 2 if it accepts the SA proposal. The initiator would see that the cookies from both parties would not match if a man-in-the-middle generated numerous false messages with a false return address. When the initiator receives the 2nd message with a cookie that is not its own, the communication is simply stopped and no further messages are sent.

Message 3 and Message 4:

At this point, values have been worked out via the Phase 1 proposals and now the Diffie-Hellman public keys are exchanged to create a common session key. Nonces, which are essentially random numbers, are also exchanged at this time to be used as seeds for keys generated later. After both sides have exchanged their Diffie-Hellman public keys in Phase 1: messages 3 & 4, a key is created on each side to encrypt the rest of the IKE Phase 1 messages. The session key is a result of the exchanged public keys being sent to each partner.

Message 5 and Message 6:

Identities and hashes containing the preshared key, Diffie-Hellman session key, cookies and nonces are exchanged to verify the identity. The payloads in Phase 1 message 5 & 6 are encrypted with the keys created from the previous message. Messages 5 & 6 are encrypted and authenticated. Now the two devices are running the encryption algorithm and having a secure conversation. This was because the ID hashed was used for the actual authentication.



Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search