Initial exchanges

Activation of an IKE_SA requires completion of two exchanges, IKE_SA_INIT exchange and IKE_AUTH exchange, as illustrated in Figure 1.

Figure 1. IKEv2 initial exchanges

An IKE_SA is established using the IKE_SA_INIT exchange and IKE_AUTH exchange. In this diagram, the initiator server A exchanges four messages with the responder server B. A sends theIKE_SA_INIT request to B including proposed SAs, keying information, and nonce. A receives the IKE_SA_INIT response from B including accepted SAs, keying information, and nonce. A sends the IKE_AUTH request to B including identity and authentication information, CHILD_SA proposals, and traffic selectors. A receives the IKE_AUTH response from B including identity and authentication information, accepted CHILD_SA proposals, and traffic selectors. All the messages must be encrypted.

The first exchange of an IKEv2 activation attempt is the IKE_SA_INIT exchange. The initiator sends a list of security association proposals to the responder in the IKE_SA_INIT request. Each proposal defines a combination of attributes for the IKE SA that is being negotiated. The initiator also includes its nonce and Diffie-Hellman value in the IKE_SA_INIT request. The responder picks a proposal that is acceptable and returns its choice to the initiator in the IKE_SA_INIT response, along with its own nonce and Diffie-Hellman value.

The following attributes of the IKE SA can be negotiated during the IKE_SA_INIT exchange:

Message authentication algorithm (for example, HMAC-MD5-96 or HMAC-SHA1-96)
Pseudo-random function for key generation (for example, HMAC-MD5 or HMAC-SHA1)
Encryption algorithm (for example, DES, 3DES or AES)
Diffie-Hellman group information (for example, group 1, group 2, group 5 or group 14)

Once the IKE_SA_INIT exchange completes successfully, both the responder and initiator can independently generate the identical keying information that supports the IKE SA. This keying information includes the following:

A pair of keys used to authenticate the IKE peers
A pair of keys used to authenticate messages sent under the protection of this IKE SA
A pair of keys used to encrypt messages that are sent under the protection of this IKE SA
Keying material that derives keys that are established for child SAs

Note that, unlike IKEv1, each IKEv2 peer chooses its own authentication method. On a single IKE SA, one peer might choose to be authenticated using a pre-shared key, while the other peer chooses digital signature authentication. If the two peers both choose pre-shared key as the authentication method, the IKEv2 protocol allows their keys to be different, but the z/OS® implementation requires both peers to use the same key. Also, the IKE SA life time and life size are not negotiated between the two IKEv2 peers. Each peer manages its own independent value of life time and life size for each IKE SA.

In some cases, negotiation of these attributes may require more than one IKE_SA_INIT exchange. The initiator makes a guess as to which proposal the responder will choose, and sends a Diffie-Hellman value that corresponds to that guess. If the responder chooses a different proposal, it rejects the IKE_SA_INIT, and includes an indication in the response that identifies its chosen proposal. The initiator learns the correct choice from the IKE_SA_INIT response, and initiates a new IKE_SA_INIT exchange with the responder's chosen proposal and corresponding Diffie-Hellman value.

IKEv2 also provides a mechanism to exchange certificates when signature-based authentication is used. In the IKE_AUTH request the initiator can include the certificate it used to create its signature. In the IKE_AUTH response, the responder can include the certificate it used to create its signature. Inclusion of the certificates is optional. IKEv2 can be configured to send and/or receive new certificate encoding types that are not supported for IKEv1:

Hash and URL of an X.509 certificate
Hash and URL of an X.509 bundle

Because both peers have all the required keying information, all but the headers of all subsequent requests and responses sent on the IKE SA, by either peer, are encrypted and authenticated.

The second exchange is the IKE_AUTH exchange. This exchange completes the activation of the IKE SA, and also sets up an SA for the first (and often only) AH or ESP child SA. Details of first child SA activation are described in First Child SA.

Note: The z/OS IKE daemon uses the Network Security Services (NSS) Certificate service for creating and verifying digital signatures during the IKE_AUTH exchange.

To complete activation of the IKE SA, the initiator transmits an IKE_AUTH request that contains its identity and authentication information. The authentication information varies depending on the initiator's authentication method that was declared in the IKE_SA_INIT request. For pre-shared key authentication, the information takes the form of an encrypted hash. For signature-based authentication, this information takes the form of a digital signature. The initiator may also include the expected identity of the responder in the IKE_AUTH request. This is useful when the machine on which the responder is running is hosting multiple identities at the same IP address. The responder includes its identity and authentication information in the IKE_AUTH response.

When a certificate payload of one of these encoding types is received, the actual certificate is retrieved from an HTTP server using the provided URL, and the retrieved certificate is verified using the provided hash. The hash and URL are typically smaller than the certificate they refer to, so some efficiency is gained by using them. However, there is additional cost to retrieve the certificate from the HTTP server.