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 posts, we went through the Pre-Share Key IKE phase 1 establishment for Main Mode and Aggressive Mode. In the following posts, we will find out IKE process in Digital Signature Phase 1.
The Digital Signature Main Mode is very similar to the PSK Main Mode. So in this post, I will only focus on the differences between these two modes. For more details about the Main Mode, please refer to the PSK Main Mode post.
Packet 1 (Initiator -> Responder):
Packet 2 (Initiator <- Responder):
Packet 3 (Initiator -> Responder):
Packet 5 (Initiator -> Responder):
Reference:
The Digital Signature Main Mode is very similar to the PSK Main Mode. So in this post, I will only focus on the differences between these two modes. For more details about the Main Mode, please refer to the PSK Main Mode post.
Packet 1 (Initiator -> Responder):
Same as Main Mode, the 1st packet from Initiator contains the CKY-I and CKY-R (all 0s) in the ISAKMP Header. In the Payload, it has the SA proposal(s) and the NAT-T sign.
And of course, the SA proposal Authentication Method is "RSA signatures".
In Packet 2, Responder replies back with its CKY-R value and the chosen SA and NAT-T enable sign.
Packet 3 (Initiator -> Responder):
In Packet 3, the DH public key (g^xi), Nonce (Ni_b) and the NAT-T hashs will be sent from Initiator.
Similar, Responder's DH public key (g^xr), Nonce (Nr_b) and NAT-T hashs are included in Packet 4.
And at this point, SKEYID can be generated. The SKEYID in Dig-Sign Main Mode can be created from the following:
SKEYID = prf(Ni_b | Nr_b, g^xy)
And other 3 keys can be generated from the same methods as PSK Main Mode:
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
Here we can find that one of differences between the PSK Main Mode and Dig-Sign Main Mode is how the SKEYID is generated. As we remember, in PSK Main Mode the SKEYID is:
SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
In Main Mode, IDii and IDir are transmitted in Packet 5 & 6 but the SKEYID needs to be generated before Packet 5. IDii and IDir are used to locate the Pre-Share-key of the peer and Pre-share-key is required in the SKEYID generation. Therefore, both peers need to know each other's IDii and IDir before they are transmitted in Packet 5 & 6. So they can only use the peer's IP address as the IDii and IDir as the IP address information can be obtained in Packet 1-4.
But in Dig-Sign Main Mode, this is not the case any more. The SKEYID in Dig-Sign Main Mode is using g^xy (DH share key) instead of pre-share-key. And because of this, the IDii and IDir information are not required before Packet 5 & 6. We can use other different values such as hostname, ike-id, or information in the digital certificate as the IKE ID in Dig-Sign Main Mode.
We can use Dig-Sign Main Mode for the scenario which the remote peer doesn't have a static public IP.
Also, after the Packet 3 and 4 exchange, the Initiator and Responder will complete the NAT-T detection.
Comparing to the PSK Main Mode, the 5th packet has a very different payload. It contains the Certificate of the Initiator and the SIG_I.
Certificate: It's the cert which is signed by the root CA's private key.
SIG_I: It is signature value generated by the HASH_I and Initiator's private key as follow:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii )
SIG_I = hash (Priv_I, HASH_I)
* SAi_B is the entire body of the SA payload
* Priv_I is the Initiator's private key.
Once the Responder receives the Packet 5, the following happen:
a. The Responder validate the Initiator's cert with its root CA public key
b. Obtain the public key from the Initiator's cert and use it to decode the SIG_I and obtain the HASH_I.
c. The Responder will compute the HASH_I value by itself and compare it with the HASH_I from Packet 5.
d. If the two HASH_I values are the same, the Initiator Identity is validated.
Packet 6 (Initiator <- Responder):
Similarly, IDir, Cert of Responder and SIG_R are included in the Packet 6 from Responder to Initiator.
And Responder's Identity will be validated in the same way as in Packet 5.
Question, how could the Responder know which Cert to be sent in Packet 6?
Since the Responder may have multiple certs. For different remote peers, it may use different certs.
The IDii received in Packet 5 can be used to map a particular Responder's cert. Elements such as Issuer's CN, Subject OU in the received Cert in Packet 5 can also be used to map a particular cert.
In Cisco ASA, "crypto ca certificate map" & "tunnel-group-map" are used to do this cert element to tunnel group (trust-point cert) mapping.
However, in the Dig-Sign Aggressive Mode, we cannot use the elements in Initiator's cert to map the Responder's cert. Why? We will figure this out in the next post.
|
At this point, the Phase 1 of Digital-Signature Main Mode is completed. A capture pacp file for the Digital-Signature Main Mode can be download in the following link:
In the next post, we will discuss the process in the Digital-Signature Aggressive Mode. Stay tuned!
Reference:
No comments:
Post a Comment