Tuesday, October 23, 2018

The secrets of IKE (Internet Key Exchange) 05 - Digital Signature Aggressive Mode

This is the 5th 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 this post, let's go through the Digital Signature Aggressive Mode. Many items have already been described in the PKI Aggressive Mode and Digital-Sign Main Mode posts. So I won't go through the details of them. Here I will just go through the special characters in Digital-Sign Aggressive Mode.

Same as in PSK Aggressive Mode, in Digital-Sign Aggressive Mode, three packets will be exchanged between the Initiator and Responder.


Packet 1 (Initiator -> Responder):
The Packet 1 contents are very similar to the one in PSK Aggressive Mode. Just the authentication method in SA Proposal here is "RSA signatures".

Packet 2 (Initiator <- Responder):


Before sending the 2nd Packet, the Responder will need to figure out which cert will be used for generating the SIG_R and sent to the Initiator for identity validation. 

In Main Mode, Initiator sends its cert first. So Responder can decide which cert to be used for this IKE session based on either the IKE ID of the Initiator or the Initiator's cert elements (such as Issuer's CN or Subject OU).

But in Aggressive Mode, Responder has to send its cert first. And because it has not receive the Initiator's cert at this point, it can only make the cert decision based on the Initiator's IDii. 

Packet 3 (Initiator -> Responder):

Once the Initiator receives the 2nd packet, it will validate Responder's Identity by checking the SIG_R. If everything is ok, it will send out the Packet 3 including its own cert and SIG_I.

After exchanging these three packets, the Digital-Sign Aggress Mode Phase 1 is completed.

Doesn't like in PSK, in Digital Signature authentication, IDii is no longer limited to IP address. The Main Mode which is consider to be more secure are highly recommended. And the Digital-Sign Aggressive Mode is less preferred. 

The pacp file for a example of Digital-Sign Aggressive Mode can be download from the following link:


In the next post, we will discuss about the Quick Mode which is the Phase 2 in IKE.

Reference:




Sunday, October 21, 2018

The secrets of IKE (Internet Key Exchange) 04 - Digital Signature Main Mode

This is the 4th 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 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):
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".


Packet 2 (Initiator <- Responder):
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.


Packet 5 (Initiator -> Responder):

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:



Saturday, October 20, 2018

The secrets of IKE (Internet Key Exchange) 03 - PSK Aggressive Mode

This is the 3rd 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 went through the Phase 1 of PSK Main Mode. In this post, we will take a look at the PSK Aggressive Mode.

PSK Aggressive Mode:
In Aggressive Mode, only 3 packets will be exchanged between the Initiator and Responder.  It is much simpler then the Main Mode,. However, in Aggressive Mode, some information are exposed in a clear message (not encrypted) and this may cause some security issues. But for some particular scenarios, Aggressive Mode is the only option.

Packet 1 (Initiator -> Responder):

In the 1st packet, the ISAKMP header contains:

CKY-I:  The Initiator's ISAKMP SPI
CKY-R: The Responder's ISAKMP SPI. At this point, this value is all "0s".

In the payload, it contains:

SA Proposal: In Agressive Mode, only one SA proposal is allowed.
g^xi: The generated DH public key from Initiator
Ni_b: Nonce, the random generated number for key creation
IDii: Initiator's ISAKMP ID. In PSK Aggressive Mode, the IDii can be hostname, IKE-ID (any user define string), and IP address
NAT-T Negotiation: NAT enabled sign

Different from Main Mode, the IDii is transmitted in clear text. This make Aggressive mode less secure than Main Mode.


Remember the second question raised in the first post?
Why aggressive mode initiator can only have a single SA proposal?

Only a single SA proposal can be put in the 1st packet from Initiator. The Responder can only accept or decline. Doesn't like in Main Mode, the Responder can select one from the SA proposals provided by the Initiator. The reason is that before sending the 1st packet to Responder, the Initiator will need to use a selected DH (Diffie-Hellman) group method to generate DH private/public key pair and put the public key (g^xi) in the 1st packet. Therefore, the DH group is chosen already. And the Responder doesn't have an option to pick other DH group. 



Packet 2 (Initiator <- Responder):
Before assembling the 2nd packet, the Responder needs to generate the SKEYID (seed key) and other 3 keys:

SKEYID = prf(pre-shared-key, Ni_b | Nr_b)


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)

If you are not familiar with these keys and the elements in the "prf", you can go back to the 2nd post of this IKE series and there are detailed descriptions for them.

When these keys are ready, it can start assembling the packet.This 2nd Packet is also in clear text. 

In the Packet Header, the value of CKY-R is added.

In its payload, it contains the following values:

SA: If Responder accept the Initiator's SA proposal, it will reply with the same SA

g^xr: The generated DH public key from Responder

Nr_b: This is the nonce, the random number

IDir: The ISAKMP ID of the Responder

HASH_R: This value will be used by the Initiator to verify the identity of the Responder. It's calculated by the following formula:
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir)
* SAi_b is the entire body of the SA payload

NAT-T Negotiation: NAT enabled sign

Detected Initiator's IP/port HASH, Responder's IP/port HASH: These two values are used for NAT-T detection. They are calculated from the following:
HASH = HASH(CKY-I | CKY-R | IP | Port)



I think we can answer the 2nd half of question 1 in the first post now:
Why remote VPN peer with dynamic IP can ONLY use aggressive mode to connect to the hub VPN server?

In Aggressive Mode, the Initiator's IDii is sent in the 1st Packet in clear text. Therefore, the Responder can obtain the Initiator's PSK based on its configured IDii-to-PSK mapping and use the Initiator's PSK to generate the SKEYID and other keys.

If the remote VPN peer doesn't have static IP then it cannot use IP address as its IDii, bui it can use Hostname or IKE-ID instead. This only works in the Aggressive Mode.



Packet 3 (Initiator -> Responder):

Similarly, Initiator will generate the SKEYID and other 3 keys. HASH_I value will be calculated based on these keys:

HASH_I: The value used by Responder to verify the Identity of the Initiator.
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii )

Detected Responder's IP/port HASH, Initiator's IP/port HASH: Up to this point, both Initiator and Responder have their own IP/Port Hash and the peer's detected IP/port Hash. They can figure out whether the peer is behind NAT and whether NAT-T is in used. 

Also, please be noted that the 3rd packet is the only encrypted packet in the Aggressive Mode. SKEYID_e and the Encryption method in the SA will be used to encrypt this packet by Initiator.

After exchanging these three packets, the PSK Aggressive Mode IKE phase 1 is completed. A captured pacp file which can demonstrate this process can be download from the link below:


In the next post, we will work out how the Digital Signature Main Mode work. Stay tuned!


Reference:




Thursday, October 18, 2018

The secrets of IKE (Internet Key Exchange) 02 - PSK Main Mode


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 1.1.1.1 (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 )
SAi_b 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. 


Reference:
















Tuesday, October 16, 2018

The secrets of IKE (Internet Key Exchange) 01 - Introduction & IKE structure

IPsec site to site VPN is very popular technology today in the networking world. It helps to join different network segments sitting in different geo-locations together and provide secure communication channels between them. IKE is the key component for building the IPsec site to site VPN.

Thanks for the VPN configuration templates/Wizards provided by Vendors, network engineers can build a site to site VPN tunnel by inputting the required parameters to the edge router/firewalls. All the heavy lifting behind the scene can be completed by those vendor box. However, the reality is that deploying IPsec VPN is never easy especially when connecting to a 3rd party endpoint. So, if you want to deploy VPN solutions smoothly, understanding the secret behind the screen for IKE become necessary.

 In the following of post series, I would like to talk about the how the IKE works in both PSK and Signature authentication mode. But I will only focus on describing how the different elements of IKE work together. The math calculation is not focused here.

Here are the list of all the posts in this series:

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

Before our journey begins, I would like to raise two questions and let's see if we can find the answers from the up coming post.
  1. Why the PSK Main Mode have to use IP address as ISAKMP ID on both ends? Why remote VPN peer with dynamic IP can ONLY use aggressive mode to connect to the hub VPN server?
  2. Why aggressive mode initiator can only have a single SA proposal?
First of all, I put all the IKE elements for building a IPsec tunnel into several charts. It will help you to understand how they work together. You can download the chart from the following link:


And now, let's find out the secrets about the IKE structure. As we know, IKE (Internet Key Exchange) contains two phases.

In IKE phase 1, information such as Authentication method, Encryption method, Integrity check method, DH group will be negotiated between Initiator and responder. Also, DH Group public keys and nonce will be exchanged between these two parties. Then these two parties will verify the identify of the peers and then calculate the keys for encryption and integrity check individually. Once the IKE phase 1 is completed, a IKE SA will be formed. This is the secure channel for IKE phase 2 negotiation and IKE DPD (Dead Peer Detection) check later on.

In IKE phase 2, the IKE payload is encrypted with the key generated in phase 1. Encryption method, Integrity check methods, PFS DH group (optional), Proxy IDs on each ends (source, destination IP/subnets in the SA) will be negotiated in phase 2. when both of the initiator and responder found the acceptable combination of the above items, IPsec SAs will be built. Each pair of source/ destination proxy ID will form two IPsec SAs, one for each direction. The data traffic using these proxy IDs as source/destination will go via these IPsec SAs.

In the next post, I will talk about the message exchanges in PSK Main mode & Aggressive mode in more depth. Stay tuned.








Monday, September 17, 2018

Port Forwarding configuariton: Cisco ASA vs Palo Alto FW

In this post, I would like to talk about the difference in configuring port forwarding policies in Cisco ASA and Palo Alto FW.

Port Forwarding is also known as static IP NAT which is a very common configuration in the edge firewall/ routers to provide internal service access to outside network (exotically Internet).

I am going to use the following as an example. In this example, we are going to configure a port forwarding rule on the edge Firewall to forward 11.11.11.5:TCP 8080 to the internal Web Server 172.16.10.100:TCP 80.
From the following table, we can see in the "NAT Policy", the Dest-Zone in Palo Alto is the "pre NAT Zone" which is the "outside zone".

In the Security Policy, the Dest-Address and Service are both the Pre-NAT ones. 


ASA
Palo Alto
NAT Policy
Static NAT
Static NAT
Source Zone (interface)
outside
outside (or ANY)
Dest Zone (interface)
inside
outside (pre NAT Zone)
Original Source IP
any
any
Original Dest IP
11.11.11.5/32
11.11.11.5/32
Original Service
TCP/Dest-8080
TCP/Dest-8080
Translate Source IP
same as original
Translation Type: None
Translate Dest IP
172.16.10.100/32
172.16.10.100/32
Translate Service
TCP/Dest-80
TCP/Dest-80 (only can be Dest port)
Secuirty Policy


Source Zone (interface)
Assign Secuirty Poliyc to outside Interface
outside
Dest Zone (interface)
n/a
inside
Source Address
any
any
Dest Address
172.16.10.100/32 (post NAT IP)
11.11.11.5/32 (pre NAT IP)
Service
TCP/Dest-80 (post NAT Service)
TCP/Dest-8080 (pre NAT Service)


NSX Load Balancer "Application Rules" Examples:

Load Balancing is one of the features provided by the NSX Edge Services Gateway (ESG). It can provide L7 Load Balancing by utilizing the HA...