This is the 2nd post in this IKE series. You can find the other posts of this series from the following:
01 - Introduction & IKE structure
02 - PSK Main Mode
03 - PSK Aggressive Mode
04 - Digital Signature Main Mode
05 - Digital Signature Aggressive Mode
06 - IKE Phase 2 Quick Mode
In the previous post, we knew that there are two phases in IKE. Phase 1 is for building the secure communication channel for phase 2 and phase 2 is for building the secure channels for data transmission. Now we will look at what magic is applied on PSK (Pre-Share Key) Main Mode.
PSK Main Mode:
In every IKE main mode, there are 6 messages transmit back and forward between the Initiator and Responder in phase 1.
Packet 1 (Initiator -> Responder):
The 1st packet is sent from Initiator to Responder. Its ISAKMP header contains the IKE SPI (CKY-I) of the Initiator and the IKE SPI (CKY-R) of the Responder is blank (all "0s"). The IKE proposals are included in the payload of this packet. Also a payload of "Negotiation of NAT-Traversal in the IKE" as a NAT-T enabled indicator.
|Click to Expend|
Packet 2 (Initiator <- Responder):
In the 2nd packet, Responder will add its ISAKMP SPI (CKY-R) in the ISAKMP header. Its payload will include a chosen IKE policy set and a "NAT-T Negotiation" sign.
After exchanging the first two packets, the Initiator and Responder will a have a common IKE policy with Authentication method, Encryption method, Integrity check method and DH group set. And, they will have agreement on whether NAT-T is enabled or not.
Packet 3 (Initiator -> Responder):
From now on, all the ISAKMP message headers in the same ISAKMP SA will contain the same CKY-I and CKY-R.
In this step, the Initiator use the selected DH group ( from IKE policy negotiation) to generate a DH private key and public key (g^xi). Also a nonce (Ni_b) which is a randomly generated number used in key generation will be created.
Initiator will also generate two hash values, one is from the Initiator's IP/port. The other one is from detected responders IP/port. These two hash values are for the NAT-T detection purpose. These HASHs are calculated by:
HASH = HASH(CKY-I | CKY-R | IP | Port)
All of the above values will be sent to the Responder in the packet payload.
Packet 4 (Initiator <- Responder):
Same happens to Responder. DH public key (g^xr), private key are generated via the selected DH group. A random number (Nr_b) is also generated.
Hash of detected Initiator's IP/port and Responder's IP/port will be calculated.
And these values will be sent to the Initiator.
Up to this point, a common DH shared key (g^xy) can be calculated by both parties. The way how the shared key is generated is shown in the following diagram:
|Click to Expend|
Also, they finished the NAT-T detection at this point. For example, of the Initiator knows it's own IP is 192.168.1.10 but the "detected Initiator's IP" received in Packet 4 show its IP is 220.127.116.11 (public IP), then it knows it is behind NAT and port UDP 4500 will be used for IPsec SAs. Otherwise, if the local IP and the remote detected IP are the same, then ESP will be used for IPsec SAs.
After exchanging the first 4 packets, both parties will have the following:
- CKY-I, CKY-R
- selected IKE policy set
- g^xi, g^xr, g^xy
- Ni_b, Nr_b
- NAT-T detection
And before sending the 5th packet, both parties need to do some math calculations.
First, a SKEYID (seed key) needs to be generated. And different authentication methods have different method to generate this SKEYID. For IKE SA which using PSK authentication method, the SKEYID is generated by this formula:
SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
* "prf" is the keyed psedudo-random function
And based on this SKEYID, 3 different keys are generated:
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_d (Derivative Key) is NOT used by ISAKMP, and is handed to IPsec for generating IPsec Secret key in the "Quick Mode" later on.
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_a (Authentication Key) is used to Integrity check (Authentiction) check in ISAKMP phase2.
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_e (Encryption Key) is used by the Encryption algorithm such as AES to encrypt data in ISAKMP phase 1 msg 5,6 and phase 2.
UP to this point, both Initiator and Responder share the above 4 keys and they can use these keys for the remaining phase 1 and phase 2.
Packet 5 (Initiator -> Responder):
The 5th packet includes IDii
which is the ISAKMP ID of the Initiator. HASH_I
is an ID hash from the Initiator. It's calculated from the following:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii )
is the entire body of the SA payload.
The Payload of packet 5 is encrypted by the chosen Encryption method (such as AES) and the the key (SKEYID_e). So the Responder decrypt this packet with SKEYID_e and obtain the HASH_I. And then, it compare this obtained HASH_I to its computed HASH_I and validate the identity of the Initiator.
Do you still remember the questions raised in the previous post? At this point, we can answer the first part of question 1 which is "Why the PSK Main Mode have to use IP address as ISAKMP ID on both ends? "
In Packet 5, we can see the Responder receives IDii (Initiator's ISAKMP ID) from Initiator. In the VPN configuration, PSK is tied to particular ISAKMP ID. It means, if we don't use the IP address as ISAKMP ID, the Responder will NOT know Initiator's PSK before Packet 5. However, after the first 4 packet exchange, we will need to use the PSK to generate the SKEYID and other 3 keys. HASH_I and payload encryption key of Packet 5 are built based on those keys. So the Responder has to know about the IDii before Packet 5. It cannot wait for the IDii which is transmitted in packet 5. Therefore, the default ISAKMP ID which is the peer IP address has to be used in PSK Main Mode.
Packet 6 (Initiator <- Responder):
Similarly, Responder will send the IDir which is its ISAKMP ID and the generated HASH_R to the Initiator.
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir)
And the payload is encrypted by the chosen Encryption method and SKEYID_e.
The Initiator will also validate the identity of the Responder by comparing the obtained HASH_R to its own computed HASH_R.
After exchanging the above 6 packets, the PSK Main Mode IKE phase 1 is completed. Here I have a captured pacp file which contains the PSK Main Mode packets. It will show you the details of these packets.
In the next post, let's find out what's the difference in PSK Aggressive mode.