Phase 2

The purpose of phase 2 negotiation is to establish a set of parameters that are known as a Security Association, which is used to protect specific types of IP traffic. The phase 2 Security Association contains the keys that are used to encrypt and decrypt IPSec packets on the host, authenticate IPSec packets on the host, or both. The phase 2 Security Association is negotiated for a specific set of data endpoints for a specific type of traffic, and contains the following information:

• The keys that are used to encrypt, if encryption is being used
• The keys that are used to authenticate
• The data endpoints, either a single IP address or range of IP addresses
• The protocol of the traffic to be protected, either a single protocol or all protocols
• The ports of the traffic to be protected, either a single port, a range of ports if the IKEv2 protocol is used to negotiate the phase 2 Security Association, or all ports
• The IPSec protocol that is used to protect the data: AH or ESP, or both if the IKEv1 protocol is used for the negotiation
• The type of authentication algorithm to be used
• The type of encryption algorithm to be used, if encryption is being used
• How to build the IPSec packets (tunnel, transport, UDP-encapsulated tunnel, or UDP-encapsulated transport)
• How often the keys should be refreshed, if the IKEv1 protocol is used for the negotiation
• A security parameter index (SPI) value, used together with the remote security endpoint IP address to uniquely identify the Security Association
• The Diffie-Hellman group for perfect forward secrecy (PFS)

A phase 2 negotiation can begin only after the completion of a corresponding phase 1 Security Association. The encryption methods that are agreed upon during the phase 1 negotiation are used to protect the data that is exchanged during the phase 2 negotiation. For instance, if the KeyExchangeRule between two security endpoints specified SHA1 and 3DES, the IKE data that is exchanged during the phase 2 negotiation is authenticated using HMAC-SHA and encrypted using 3DES encryption. Although both phase 1 and phase 2 Security Associations might use the same authentication and encryption methods, this is not required. For instance, a phase 1 Security Association can specify SHA1 authentication and 3DES encryption, while a phase 2 Security Association might use ESP with HMAC-MD5 authentication and DES encryption.

The keys that are generated during the phase 2 negotiation can be derived from the phase 1 master key to amortize the cost of the phase 1 key generation. As an alternative, you can configure the phase 2 negotiation to use perfect forward secrecy (PFS) for stronger security. Each has its advantage as follows:

• If PFS is used, phase 2 negotiation does not derive its keys from the master key, but instead generates new keying material using the Diffie-Hellman algorithm. Because it is independently derived, the resultant phase 2 key is more secure.
• If PFS is not used, phase 2 negotiation is completed much more quickly, but the resultant phase 2 key is less secure.

In either case, phase 2 does not incur the same degree of processing overhead that is involved in phase 1 negotiation with the remote IKE peer.

For IKEv2, the negotiation of the first phase 2 Security Association on a given phase 1 is a special case because it is performed during activation of the phase 1. In this case, the phase 1 Diffie-Hellman group is used for the phase 2 negotiation, regardless of what was defined on the IpDataOffer statement that corresponds to the phase 2.

When phase 2 negotiation has completed, the Security Association is available for use by the stack. Now, any traffic that is mapped to this Security Association by an IP filter rule is IPSec-protected. Because each phase 2 Security Association corresponds to a single unique phase 1 Security Association, the identity of the remote peer is implicitly authenticated when the phase 2 Security Association is used.

Policy for phase 2 Security Associations is defined by referencing an IpDynVpnAction statement on an IpFilterRule statement. For more details on referencing an IpDynVpnAction statement on an IpFilterRule statement, see z/OS Communications Server: IP Configuration Reference.

You can specify only tunnel or transport mode encapsulation on the IpDataOffer statement. The decision to use UDP-encapsulated transport or tunnel mode is made heuristically by the z/OS® IKE daemon. If a NAT device is detected in the process of creating a phase 1 Security Association, all phase 2 Security Associations negotiated under the protection of that phase 1 Security Association are negotiated using UDP encapsulation. In this case, all IpDataOffer statements that contain ESP refer to UDP-encapsulated tunnel or transport mode, as applicable. Any IpDataOffer statements that are configured to use AH authentication are ignored, because the IPSec protocols do not allow for AH authentication when UDP encapsulation is used.

The phase 2 parameter values supported can differ between IPSec implementations. For example, z/OS provides configuration to negotiate a phase 2 Security Association for specific port and specific protocol values. Many implementations of IPSec support negotiating only a wide Security Association, covering all ports and protocols.