4

I need to confirm my understanding of IPSEC phase 1. As per my understanding in the capture below, the first 2 messages are agreeing on the parameters, the next 2 are key exchange the final 2 is authenticating each other?

enter image description here

If you at the packet 77, we see the field "Key Exchange Data". Is is the actual DH key that is being exchanged?

Phase 1 seems to be a bit complicated to me. Can someone explain the phase 1 process by referencing the capture above. This is my configuration for your reference.

Configs:


R1#show running-config | section crypto|isakmp|access-list
crypto isakmp policy 10
 encr aes 192
 hash sha384
 authentication pre-share
 group 5
crypto isakmp key cisco address 12.1.1.2
crypto ipsec transform-set ESP_AES_192_SHA1 esp-aes 192 esp-sha-hmac
 mode tunnel
crypto map MAP1 local-address Loopback1
crypto map MAP1 10 ipsec-isakmp
 set peer 12.1.1.2
 set transform-set ESP_AES_192_SHA1
 match address R1-R2
ip access-list extended R1-R2
 permit ip 15.1.1.0 0.0.0.255 23.1.1.0 0.0.0.255

R2#show running-config | section crypto|isakmp|access-list
crypto isakmp policy 10
 encr aes 192
 hash sha384
 authentication pre-share
 group 5
crypto isakmp key cisco address 1.1.1.1
crypto ipsec transform-set ESP_AES_192_SHA1 esp-aes 192 esp-sha-hmac
 mode tunnel
crypto map MAP1 10 ipsec-isakmp
 set peer 1.1.1.1
 set transform-set ESP_AES_192_SHA1
 match address R2-R1
ip access-list extended R2-R1
 permit ip 23.1.1.0 0.0.0.255 15.1.1.0 0.0.0.255
4
  • Are you aware that there are two versions of the IKE protocol? (Which are quite different). And that IKEv1/ISAKMP can be run in two different modes (Main/Aggressive)? And that there are extensive RFCs that define/explain the protocols (IKEv1: RFC 2408, RFC 2409; IKEv2: RFC 7296)?
    – ecdsa
    Nov 7, 2016 at 17:36
  • Could you upload a copy of the packet capture? I have a feeling I know the answer, but want to confirm something before I take the time to explain it.
    – Eddie
    Nov 7, 2016 at 18:12
  • Wait, nm, I was over complicating it... answer to follow shortly...
    – Eddie
    Nov 7, 2016 at 18:14
  • @Juergen I think your understanding is mostly correct, except that in packets 3&4 you don't exchange the actual key, but the keying material, i.e. the numbers used to calculate the key on both ends. Note that packets 1-4 are not encrypted so transmitting the actual key in the clear would be rather silly :) See e.g. Wikipedia for an explanation of how DH works.
    – hertitu
    Nov 7, 2016 at 18:44

3 Answers 3

1

You posted a capture of an IKEv1 Main Mode negotiation. In this negotiation there are 6 messages, or 3 pairs of back-and-forth exchanges.

The first exchange is the negotiation of the ISAKMP Policy Suite. The second exchange is the negotiation of Diffie-Hellman. The third exchange is validating each peer has the proper authentication data (typically pre-shared-keys, but can also be certificates).

This is all goverened by RFC 2409, which explains a IKEv1 Main Mode exchange with Pre-Shared-Key authentication looks like this:

Initiator                  Responder
----------                 -----------
HDR, SA             -->
                    <--    HDR, SA

HDR, KE, Ni         -->
                    <--    HDR, KE, Nr

HDR*, IDii, HASH_I  -->
                    <--    HDR*, IDir, HASH_R

Exchange 1

In the first exchange, the SA payload is what the peers use to suggest ISAKMP Policies (as the initiator), and to confirm the selected policy (as the responder).

Exchange 2

In the second exchange, there are two payloads: KE and either Ni or Nr (i=initiator, r=responder).

The KE value, which you have highlighted in your picture is the Diffie-Hellman Public key. Each party has their own, and this is where it is shared. In this DH Illustration, this would be Alice and Bob sharing their values of 2 and 9.

This value will be combined with a Private value that each party generated (and never shared). The final result will be the Shared Secret, which is the final goal of the Diffie-Hellman exchange. The Shared Secret will then be used to derive Session Keys -- specifically, a symmetric encryption key and an HMAC key.

Anyone eavesdropping will not be able to put together the final value because they don't have access to either of the private values that both parties generated.

The Ni or Nr values are what is known as a Nonce. This is simply a random number generated by the Initiator and Responder that is used in generating keying material. The term "Nonce" sort-of stands for Number used Once (N+Once = nonce).

Exchange 3

In the final exchange, the IDi and HASH_ values correlate to an Identity Method and an Identity Hash. The r and i at the end of either of these payloads indicates the one sent by the Responder (r) or sent by the Initiator (i).

These values are used to validate each Peer's identity. The way this is done with pre-shared-keys I've explained in another answer, but the crux of it is here:

There are two items that are use to validate to each Peer that they both have the same PSK: the Identity Method and the Identity Hash.

VPN Peers can choose to identify themselves by various methods; most commonly, peers will simply use their source IP address. But they have the option to use a FQDN or Hostname. Each of these, along with the correlating value for the chosen method, are what make up the Identity Method. So for example, if I had the IP 5.5.5.5, and I wanted to use my IP address to identify myself, my ID Method would effectively be [IP Address, 5.5.5.5]. (Note: BOTH values make up the entire ID Method)

The ID Method is then combined (using a PRF) with the Seed value we discussed earlier (SKEYID), and a few other values, to create the Identity Hash. Recall, that what went into creating SKEYID in the first place was the Pre-Shared-Key.

The ID Method and ID Hash are then sent across the wire, and the other party attempts to re-create the ID Hash using the same formula. If the receiver is able to re-create the same ID Hash, it proves to the receiver that the sender must have had the correct pre-shared-key.


TLDR - The value you highlighted is the DH Public Key, which is the public value that will be combined by either party with a Private value (which is never shared) to created a DH Shared Secret (which is never shared).

1

Exchange 1 in the main mode is where the initiator suggests(M 1) the policy and the responder confirms with the selected one (M 2).

So messages 3 and 4 is (This is where I was confused) the exchange of the DH public keys (Highlighted part of my capture). These public keys are derived independently on both ends using the private value (exponent) that has never been shared between the peers. Combining this private value with the public key received at each end, mathematically both peers reach to derive the same shared secret key. The shared secret key is then used to further derive the session keys, that is the encryption and the HMAC key.

Thank you for taking the time to explain this Eddie.

-1

I don't think you need a packet capture to see the negotiation.

From Cisco Support Forums:

To narrow down debugging to one peer conditional debugging should be used.

On IOS this is done by performing:

debug crypto condition peer ipv4 .... Two major component can be debugged

debug crypto isakmp - information specific to ISAKMP exchange. This will contain information about main mode and quick mode negotiation.

debug crypto ipsec - some phase 2 specific information can be found here.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.