ISAKMP Packet Captures – Guide to Capturing ISAKMP Packets

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).