Negotiation modes for phase 1

For IKEv1, the phase 1 negotiation that takes place between two IKE peers happens in one of two modes, Main mode or Aggressive mode.

Main mode is more secure because it encrypts the identities of the two hosts that are contained in the IKE messages, but somewhat slower because more message exchanges are required. Main mode requires a total of six messages, three from the initiator and three from the responder.

Aggressive mode is faster, in that fewer messages are exchanged. Aggressive mode requires only three messages, two from the initiator and one from the responder. However, the identity of the two hosts is not protected in Aggressive mode. An IKE implementation is not required to support Aggressive mode.

The choice of mode depends in part on the security needs of the installation. If it is important that the identities of either host are not to be in clear text on the network, use Main mode. Otherwise, if both hosts support it, you can use Aggressive mode for faster, more efficient key exchange. One limitation of Aggressive mode is that the initiator can specify only a single Diffie-Hellman group because the key exchange data is sent in the first message. If you need to allow the initiator to send multiple offers with different Diffie-Hellman groups, use Main mode.

For IKEv2, there is only one set of network flows defined for phase 1 negotiation. The set requires four messages, two from the initiator and two from the responder. The first two of these four messages flow in the clear on the network; the other two messages are encrypted. The negotiation of the first phase 2 Security Association is accomplished within these four flows; when the fourth message flows, both phase 1 and phase 2 Security Associations are activated. Either the initiator or the responder can subsequently activate additional phase 2 Security Associations using this phase 1 Security Association.

You configure the choice of negotiation mode using the KeyExchangeAction statement and the Diffie-Hellman group using the KeyExchangeOffer statement in an IP security policy configuration file. For more details about the KeyExchangeAction and KeyExchangeOffer statements, see z/OS Communications Server: IP Configuration Reference.