11. IKEv2 intro and differences between IKEv2 and IKEv1
So in this lecture we’ll talk about IC version two. First phase consists of four messages that create the IC. Version two SA the IC. Version two uses UDP. Same like IC version one uses UDP 500 or 4500. There are two main phases of IC. Version two. You have the IC SA underscore in it. And basically in this phase the two parties exchange the cryptographic algorithm, crypto negotiation. And then the second phase. So this is the first phase. This phase consists of two messages. And then the next phase is IC off. This is also two messages. And then after the IQ off, the phase one is complete. And then it’s going to move to phase two which is encryption of traffic. The IQ off phase.
What happens in the IC off phase is the IP IC authentication. And then IPsec Security Association is created. And then after this phase is done the encryption of the data begins just to recap. You have the ICSA Initialization which consists of two messages. And then you have the IQ Auth which also consists of two messages. The ICSA initialization phase does the crypto negotiation. The IC authentication phase does the ICC authentication and IPsec Security Association. Let’s go back and talk about the IC SA init phase like we talked about. In IC version one you have the Initiator and the responder. The initiator would send its proposals, the encryption proposal, the hashing. And then it will send the diffi hellman key public key. And then it will send this to the responder.
The responder gets this message. Assuming that it supports that diffihelman public key algorithm that it selected it will select an encryption algorithm and hashing algorithm. And assuming that it supports the diffihama public key it’s going to respond back with its own diffusion public key. And it will respond with its encryption and hashing algorithm that it would like to use. We talked about the diffuseman keys and how they are used to select the shared secret keys. So this is the first message. And this is message two. This is second message. Now when the initiator gets that message now it has all the details for it to be able to generate the secret keys. I’d like to show you the ICSA in it exchange here and see what’s included in it. So I switched my IQ version to IC version two.
And I’m going to initiate a tunnel. So here the ICSA in. It pays. We see here the initiator SPI since the responder hasn’t responded yet. This is zeros. And then you have the version number which is version two. And then you have the Security Association. And we see here in the first packet on the SA in it we have the Security Association. And the next payload is key exchange. So the Security Association which lists the actual proposals that is recommended by the initiator. And here I have the transform Three which is the encryption as CBC. And it’s also saying I can use as CBC, I can use encryption, turbo Des, I can use the HMAC Shaw One function and authentication HMAC Shaw 196. And it’s specifying the defeat and group, which is group two. And then after that there is the actual key exchange.
So the key exchange, this is the diffihama public key that happens in the first message of the connection. The first message of the connection will have the public key exchange. And then there’s the nuns, which is the number used once used in calculating the keying material. And then since I have net translation support, it’s doing net detection and net detection. And the responder here would respond with its selected responder now would have its own SPI in the responder. And then it has the transcript that selected, it selected encryption as CDC hashing Shao one and authentication which is HMAC Shao 196, and the diffusion of a group and the key exchange and the nuns.
If we compare this with version one, I’m going to switch to version one here really quick. Okay, so I change it to version one. I’m going to go ahead and initiate the tunnel again to see the difference just here. This is aggressive mode and we’re going to see a couple of differences here, if you will notice. And the version is different, of course. Security Association Key Exchange so one thing you will notice is there’s not going to be life messages because in IC version two, the lifetime is locally significant and it’s not getting exchanged with the IC version two. Pier in the case of IC version one, we noticed here that there is a difference that we see here. The lifetime is negotiated.
If we go back to IC version two essay in it, if we look at the Security Association exchange proposal, we don’t see any lifetime. Okay? So that’s one difference. If I switch to Arc version two, there is no difference in the way things look. So in the case of other vendors, you can do local authentication, remote authentication. You don’t have this feature in Palo Alto. Maybe it’s going to be available in future releases, but that’s not available. But the big difference here is the lifetime is no longer an issue. Okay. Another difference that we see between IC version one and IC version two is the fact that now we have another negotiated transform that gets negotiated.
In the case of AG version two, we all know from previous discussion, the Sidorandum function, the Cider and the function is used to generate keys. The random function in Ike version one is considered to be the same hashing function, AG version one. In AG version two, there’s distinction between the silver random function and the hashing, which is the integrity function. What is the integrity function? Basically the hashing or the hashing is I send you a message, you run the hash function. The other side received a message. So sender message, hash and then attach the message with the hash. The sender send the message plus the hash the receiver. We get the message and the hash around the same extract the message around the same hash function and compare it to the received hash function that was received from the sender. So basically that validates something called integrity.
Nothing changed in the message when it was sent from the sender and got received by the receiver. In the case of IC version one, the serena function part of the hashing function, it’s using the same function. In the case of IC version two, the sister and function and the integrity function are different. They can be different. In the case of palo alto, unfortunately, you cannot configure a different function. So if I go to the IC crypto settings, I don’t see random function in phase one. But if I compare it with a vendor like cisco, the IC version two policy has a distinction between the integrity and the cider on the function. So you see here, when you create a policy, IC version two policy, you have an integrity and then a cider under function.
They can be different. It’s really not a material difference. But I want you guys to understand. So I’m going to set up the tunnel with the cisco ASA, and I’m going to create the integrity function to be shao. Sha, which is shao one, and then sit around. The function is going to be shot to 56. Okay. And encryption. Yes, because the phase one which negotiate the keys is not used to authenticate. This is kind of part of the phase two of the communication. If I look at the cisco, in the case of cisco SA, you don’t see here authentication as part of the message. So what I’m going to do is I switch my policy here on site c to be using the crypto I version two and use separate cetera function. So short run crypto ID two.
And I see here cetera function shot 56. So I’m going to add an authentication shot to 56. And we’ll see what happens when we negotiate the connection. Site c, we’ll see what happened when the connection gets negotiated between the two. Encryption, we’ll call it we’ll add as 128. In the case of palo alto to palo alto, it’s going to select the first available option between the two because it cannot have a separate setting for cellarin and function. It’s really basically the same as the authentication function or the integrity function. In the case of palo alto to cisco, you can have a separate setter and function. But I want to show you the distinction between the two by looking at the capture and seeing what happens. So I’m going to finish configuring my cisco ASE here showrun.
Crypto AGV two, IV two. IPsec proposal. ESP protocol. ESP encryption, triple des protocol. ESP integrity. Integrity. Shaw one. Okay. IPsec proposal. And what did they call it? Tier. Okay. And then I’m going to remove IC version one group. I’m going to change the APIs attributes here. Local authentication preshirt key cisco. Okay, I’m going to enable IC version two on interface grip to IP two. Enable interface outside. And now I’m going to ping from my I’m going to run the capture first and see if there’s a capture going on here. And let’s see what negotiation we have. Okay, if you see here, this is on the ASA side. So I have a separate PRF function. If I look at the proposals I have here, I have the encryption AAS, the encryption algorithm. I have sitarandum function as sha 256.
I have the transform the integrity which is sha one. Okay, so there’s a difference, right? So the negotiated agreement, if we look at the firewall, if we look at the firewall and see what is the actual joe ppm IPsec IQ sander, it doesn’t look like the connection is going through. I’m going to shut down this ball to firewall here so I don’t have conflict between two. Let me try again. Ikac negotiation failed as responding nonrequey. Let’s verify the settings one more time here. So I’m going to look at the site. The hostname wasn’t sending those names. So if you look at the negotiation here, let’s look at the last successful negotiation for ICSA in it. We see here the icasa in it.
The request was sent by the cisco. ASA firewall has the authentication as sha one. It has the siddarina function as shard 256. The palo alto firewall accepted the siddarnam function as shard 256 and the authentication as shaw one. So but if you have two palo alto firewalls to talking to each other, you cannot make a differentiation between the integrity function and the Cyrena function. So that’s another difference between IC version one and IC version two. The serena function is a separate negotiated item and it was not the case in IC version one.
12. IKEv2 Auth phase, IPsec associations, differences between Ikev1 and Ikev2
So after the IC SA init is done, the algorithm that are negotiated in the security association is going to be the encryption algorithm integrity, which is equivalent to authentication, and then the server random function, which in case of Palo Alto palo Alto is the same. It’s going to be the same. In case of Palo Alto to Cisco, for example, you can have them different. And then the diffie hellman. So when the Diffie hellman exchange happens, both sides would arrive to the same shared secret key. And that shared secret key is going to be used to create the Skeed. So the S key seed this random function run against the nuns of the initiator, concatenated with the nuns responder, and then the shared secret key same is going to be the same on both sides.
And then the two sides will have to generate the Severandum function that would create the keying material for the keys that are needed for the communication between the two endpoint. And there are the skidd, which is for the page two, which in this case is in the case of Bike. Version two is Shawl SA, and then S key authentication or integrity for the initiator, integrity for the responder, the S key encryption for initiator, S key encryption for the responder. And then in order for it to generate those multiple keys, the server on the function is run multiple times. And basically the way it runs is it runs the surrender on a function ski seed, nonce initiator, non responder SPI, which is the security parameter index. It’s the actual packet that was used in the first exchanges.
So it’s using the actual packet itself as an input for the function. The packet that was sent an SA init for the initiator and Icsk in it for the responder. It’s using those two packets as input for the swede and then function. And then because there’s multiple keys that gets generated, this function is run multiple times. Each time it’s using an increment of the values. So it’s running as an increment number. It’s going to go zero x 10 x 20 three. It’s going to run it multiple times. That’s why we have the plus function here and it’s going to produce those keys. This is used for phase two. This is used for authentication or integrity, and this is used for encryption. After this, all communication between the I gateways is going to be authenticated, encrypted and authenticated.
There’s also two additional keys. So this will be used and there’s two additional keys, ski and skpr. This is used for the next phase of the IC negotiation, which is the IC auth. So let’s see how the IC auth works. Just to recap, here you have the shared secret key based on the first two packets negotiated, and then based on the shared secret key, there are multiple keys that gets created by running this random function in iteration mode, going through multiple times. Each time appending a different value until it gets all the key material that needs to be used and then all communication from that point forward is going to be encrypted with the encryption key and it’s going to be hashed with the authentication key. And then there’s two other keys that gets created.
This is for the authentication of the two peers to do the authentication itself and we’re going to talk about using pre shared keys. Basically the initiator creates a signature and this signature is basically running the sudden random function against the S key pi which is used the key for authentication and then it uses the payload of the packet that was sent during the phase one negotiation during the San negotiation. So this is considered the signature. So the signature will be the payload of the initiator message run against the key for the authentication. The signature for the responder is going to be the same but it’s using the SK PR and the payload of the responder message.
So this is a Sydney and then function that runs to create a signature. So basically the initiator and responder they have the shared secret key. What they would do is take the shared secret key and then there is a keypad. It’s basically a filler and it’s known ahead of time 17 Octet and then it runs this through a Sid random function and then it takes the signature and put it here and then run it again within a silver random function. So that’s the authentication message and basically that authentication is sent to the responder and the responder does the same thing. It takes the Sit random function that was created, the signature that was created and run it against a shared secret key and keypad the same keypad and then send it on to the responder to the initiator. So this is the authentication phase.
Okay it’s not recommended to use pre shared keys because technically since phase one since the Ika Sanit is done anyway for any initiator it will basically run around that shared secret key and can potentially be exposed to a fake initiator. So it’s better to use a certificate based authentication. But just on the side basically the two authenticate each other by running the swede and function against the shared secret key and sending it to the other side you can have the shared secret key different between the two sides and that will kind of alleviate this issue a little bit. However the Palo Alto Firewall does not support local and remote authentication.
So you are bound to one shared secret key in the conversation. In the case of Paul Alt so this is Ike off message one and Ike off message two. What’s also included in Ike off message one and message two is what traffic is going to be protected. And there’s a difference between IC version two and IC version one. In the case of Ike version one the proxy IDs had to match exactly in order for them to be able to establish communication. In the case of Ike version two, there is a concept called of traffic selector, meaning that one side can select a subset from the other side. So let’s say, for example, here, this is the responder and this is the initiator.
The initiator asks for protection of 192, dot 168, dot one, dot zero slash 24 to 192, dot 168, dot five, dot zero slash 24. And then in the responder, there’s zero zero. So because the responder, because this network is a subset of zero zero, it will be accepted, the communication will be accepted, and it will only encrypt the traffic that is subset of zero zero, which is 1821-6810 through 1821-6850. And this is a big difference between Ike version one and Ikea version two. And the reason why it makes sense is it fixes a problem that many people face with the Palo Alto firewall.
And the problem is there’s a limit on the number of proxy IDs. And based on the platform, there’s a limit on the number of proxy ideas that you can have.So typically, if you have a hub and spoke, and let’s say you have 500 spokes, and here you have the hub and the hub, you need to configure for proxy IDs for each one of those spokes in case you’re using proxy IDs. If you’re using Alto, Alto is not an issue. But let’s say you are dealing with a multivendor environment where you have people coming in from Cisco ASA, people coming in from other vendors that require proxy IDs. You need to configure proxy IDs for each one of those folks and there is a limitation on number of proxy IDs.
So to alleviate this, if you use IC version two, you basically can specify the proxy IDs to be zero zero for all the spokes and whatever the spokes communicates as far as network will be accepted and will be dealt with as a subset of the traffic that’s allowed here. So you cut down your proxy IDs, maybe from 5000. Let’s say there’s ten proxy IDs for each spoke to 500. So that that fixes an issue with exceeding the number of proxy IDs on platform. The actual Iqoff phase would take care of this, establishing the IPsec essay that will be used to protect the traffic. But oftentimes you don’t have the same proxy triggering from the initiated traffic. So let’s say your first communication was triggered, a proxy 192 and 68. Then later on additional traffic came in and it’s triggering for a different proxy ID, eleven 00:24 to twelve 00:24.
This will trigger another process called create child essay, which will create child essay of the essay that was generated in the Ike auth phase. And we will see this in the capture. So the Shald essay exchange basically uses the keying material. It’s going to be the serum function multiple times, depends on the size of the keys and it’s using the skidd with nons I and noncer. So you can also have PFS, you can also have time out on the phase two or the IPsec essays and it will renegotiate. And you can have perfect for secrecy, same like you had in the case of IC version one. So let’s see this in our example here in details. Let’s go back to our two firewalls here. And I’m going to bring up the Site B firewall. I’m going to shut down this ese and then this one too.
And then I’m going to change on the Hub site IC gateway where side B is using IC version two, the IPsec tunnel here, I am going to specify the proxy ID here to be zero zero, okay? And then on the other side, on this side on spoke site, I have specific proxy IDs here. So I still have let me put the specific proxy IDs. So proxy one, 2024-182-1024 and 182. Proxy two, I just want to show you the two child essays getting created. So I’m going to commit that. And then on site B, I’m going to start initiating the traffic ping 109, 216812 aggressive mode. We need to switch it to ICV two. Let me change the mode to ICV two. ICV two only commit. ICV two does not have the console for aggressive, just SA in it and ikea off for both. So here we see initiator and responder, and we see the traffic getting through.
So let’s see what the I say that was created on the firewall, the IPsec SA that was created on the far. Let’s see the messages, right, so here we have the initiator and responder and we have the Auth message, which basically off message includes the actual Phase two information. Okay? And this is information and messages going back and forth. This is the dead peer detection. So let’s see now if I trigger traffic between the two different proxies, let’s look at the firewall first. The Firewall show VPN IPsec SA We see here the proxy one, right? So even though I don’t have any specific details on it’s, just basically zero, zero, they were still able to establish communication.
Okay, and then now I’m going to negotiate paying for the second proxy ID. 182, 168, eleven one, source one eight, 2168, twelve one. And then it should negotiate child SA. So there’s. Great child SA. Since everything is encrypted and hashed, we won’t be able to see the details, but we see here the messages for create child SA. So that basically would trigger the second child essay because it’s not necessarily the case that all the proxy IDs are going to be triggered in the first negotiation. So additional proxy IDs would result in additional child essays. Let me clear it and then run the debug. Just show you this. Show VPN IPsec SA Clear. VPN IPsec SA. And then we’re going to do it one more. Do the debug here. Debug IC global on debug and then tail follow the log. I manager, so let me ping one more time here.
One, two so if we see here the actual child sake, child SA negotiations succeeded as the initiator. Those are the debt period detection messages. If we look here, we should see it created additional child essay. However, it didn’t renegotiate from scratch because the phrase one is already complete, which is the ICSA in, it is already initialized and the two side authenticated. So when something times out, when the IPsec essay times out, it’s going to be negotiated. So let’s turn on PFS and see what happens when we have PFS enabled. So an IPsec crypto profile we’re going to enable. Well, PFS is enabled, so we should see it. Let’s verify here. These two side B, we have PFS every 180 seconds. So we should see it renegotiating here. It’s going to refresh the PFS. It’s going to do PFS every three minutes.
It’s renegotiated the PFS, rerun the PFS every three minutes. So no differences there. The main difference that we have to be aware of is the proxy IDs is not really an issue anymore. You don’t have to have specific proxy IDs. There is the concept of traffic selector so the two sides don’t have to match and the lifetime doesn’t need to be negotiated as well, which is two main positive things that potentially are paying points in Ike version one. Because in the case of Ike version one, your lifetime had to be negotiated. And if two sides don’t match and they have issues with matching the lifetime, they will basically cause issues. It’s one of the pinpoints. And then also now that you have the proxy IDs don’t need to match match, you don’t need to worry about the proxy. So those are two main positives that should push you to migrate to IC version two.
