Main Mode - Linux - VPN - A Technical Guide to IPSec Virtual Private Networks

Main Mode uses six messages in three exchanges to create an SA. The steps typically start with SA negotiations, followed by Diffie-Hellman and nonce exchanges, and then the authentication of the peer.

Pre-shared Keys/Secret. The use of a pre-shared secret for authentication requires that each system be configured with a password that is associated with the remote system’s IP address being authenticated. The reader can step through each exchange detailed in Exhibit 9-16 to reveal the process.

First Exchange. The first exchange begins with a message from the initiator to the responder that contains an ISAKMP header and an SA header (see Exhibit 9-17). Con-tained within the SA header are the appropriate proposal and transform set payloads that present the security options to the responder. Included in the original message is a cookie from the initiator.

The second message is from the responder and contains an ISAKMP header and an SA header that contains a single proposal and transform set that will define the protec-tion suite to be applied. Included is the responder’s cookie.

At this point, each system has agreed upon the security suite that will be used to protect further communications and has exchanged cookies. The cookies reduce the ability for an attacker to introduce invalid packets into the negotiation of IKE.

Once the first exchange is complete, each system generates the public Diffie-Hellman values to be shared with the peer, based on the group defined in the agreed-upon proposal. After the first exchange, each system contains several pieces of infor-mation (see Exhibit 9-18), that can be used in the remaining exchanges, depending on the authentication type. Understanding the effect of the first exchange can be very Exhibit 9-16. Main Mode with shared secret.

Exhibit 9-17. First exchange.

helpful because all Main Mode first exchanges, regardless of the authentication method, share the same information.

Second Exchange. The next portion of the communication allows the peers to share the Diffie-Hellman public values and a nonce, as shown in Exhibit 9-19. The nonce and cookies provide layers of protection and reassure that the peer in the communica-tions is alive and actively participating, rather than just repeating previously collected messages or making bogus requests.

Once the public Diffie-Hellman values are shared and the second exchange is com-plete, each system processes the Diffie-Hellman value to create a primary key. Each system creates four keys:

1. SKEYID, the secret key upon which all subsequent keys are based. However, if PFS is enabled, this key is not used for the creation of future keys, and a new one is created for the generation of new Phase I and II keys.

2. SKEYID_d, used as keying material to create keys for SAs in Phase II operations (i.e., for IPSec)

3. SKEYID_a, the key used for data authentication and integrity 4. SKEYID_e, the key used to encrypt IKE messages

The root of the keys that are actually used in encryption and authentication are built from a primary key, SKEYID. The attributes used to create SKEYID are dependant on the authentication method being utilized. To build keying material, a pseudo-random function (prf) is employed with a key and various data that is combined to create a fixed value. This process should sound familiar from the cryptography chapter. A prf is a keyed hash function used to generate deterministic values that appear to be random, but are used for data validation. An example of the process is:

Digest = prf (key/seed, data1 | data2 | data3)

This section is detailing pre-shared secret authentication, and SKEYID is defined as:

SKEYID = prf (pre-shared key, Nonce_i | Nonce_r) Exhibit 9-18. What each system knows about the other after the first exchange.

Initiator/Responder 1 – Initiator’s Cookie 2 – Responder’s Cookie 3 – The proposed security suite

(ESP-DES and ESP MD5-HMAC)

Exhibit 9-19. Second exchange.

ISAKMP Header, KE & Nonce

Message #3

Message #4

Initiator Responder

The HMAC function is used with the pre-shared secret as the key and the initiator’s nonce combined with the responder’s nonce to create the primary key. The HMAC is the pseudo-random function, unless a specific one is defined — currently, there are none for IPSec.

Note: The value followed by an _i or _r represents the initiator’s or responder’s value, respectively.

The SKEYID created for the other authentication processes will be introduced here to alleviate confusion, and re-introduced in the section that details the process for that particular key.

For digital signature-based authentication, the key is defined as follows:

SKEYID = prf (Nonce_i | Nonce_r, DH_key)

For the SKEYID for digital signatures, the nonces are combined and used as the key in the message authentication process against the DH_key.

Note: The DH_key is the value derived from the Diffie-Hellman process and the result from sharing Diffie-Hellman public values. This value is not made public and is created independently by each peer using the public value provided by the other.

Next is the process to create the key for public key encryption authentication methods (standard and revised):

SKEYID = prf (HASH(Nonce_i | Nonce_r), Cookie_i | Cookie_r)

To create the primary keying material for public key encryption authentication, the nonces are combined and hashed, then used as the key for the message authentication function against the cookies.

The primary key is used in the creation of the three remaining keys as follows (same for all authentication types):

SKEYID_d = prf (SKEYID, DH_key | Cookie_i | Cookie_r | 0)

Note: The remaining three keys created with the use of the primary SKEYID are produced by the same method detailed, regardless of the authentication method selected or the exchange mode employed. That is, the keys SKEYID_x are created based on the SKEYID that may consist of different attributes, depending on the chosen authentication method.

At the completion of the second exchange, each system has enough information to begin encrypting communications (see Exhibit 9-20). It is necessary to realize that the keys to be used for encryption and authentication have been generated solely based on the peer’s IP address. The Identification Payload provides options for authentication information exchange, such as IP address, mask, or fully qualified domain name. Unfor-tunately, the ID payload was not shared in the first or second exchange, which leaves only the IP address of the peer as a unique identifier. Some information about the peer must be used to align the peer to the shared secret in the database to include in the creation of the SKEYID.

What does this mean? Main Mode Phase I with pre-shared secret as the authentication process provides no identity protection and is completely based on the peer’s IP address.

This is an acknowledged limitation of Main Mode with pre-shared secrets, and for many situations it does not present a problem. However, in scenarios where the IP address is dynamic, the responder cannot maintain pre-shared secrets indexed by an IP address it does not know. Remote access solutions are an example where the initiator’s IP address may be different for each connection. To accommodate these situations, Certificates can be used for remote access authentication. However, most remote access solutions available typically use Aggressive Mode because the ID payload is provided in the first exchange.

Third Exchange. The final exchange, as shown in Exhibit 9-21, consists of an ISAKMP header, ID payload, and a HASH payload to provide data origin authentication.

The final exchange is encrypted with the SKEYID_e key.

The HASH combines several components that are already known by the peers and one that is provided in the fifth and sixth messages, the ID payload. The HASH consists of:

about the other after the second exchange.

Initiator/Responder 1 – Initiator’s cookie 2 – Responder’s cookie

3 – The proposed security suite (ESP-DES and ESP MD5-HMAC)

In document Linux - VPN - A Technical Guide to IPSec Virtual Private Networks (Page 196-200)