KeyExchangePolicy statement

Use the KeyExchangePolicy statement to define a key exchange policy. The Key exchange policy is consulted when creating a phase 1 security association for a dynamic VPN. The KeyExchangePolicy statement can contain a combination of references to global KeyExchangeGroup statements, references to global KeyExchangeRule statements, and inline KeyExchangeRule statements.

When acting as the responder of an IKE version 1 main mode or an IKE version 2 phase 1 exchange, the IKE daemon continues negotiation without knowing the identity of the remote endpoint, as long as the suggested algorithms are supported by the IKE daemon.

Any SA agreed to before the identity of both parties are known is verified when the identity of both parties become known. If the SA is not consistent with the defined key exchange policy, the phase 1 negotiation fails. If the SA is consistent with the defined key exchange policy, the phase 1 negotiation continues.

The KeyExchangePolicy statement can appear in the common IPSec policy file, a stack-specific IPSec policy file, or both. If it appears in both, Policy Agent only uses the statement contained in the stack-specific IPSec policy file. It should appear at most only once in each file. If it appears multiple times in a file, the last one encountered is used.

Requirement: The KeyExchangePolicy statement is required to define key exchange policies to the Policy Agent.

Result: If the KeyExchangePolicy statement is deleted, then all KeyExchange policies are deleted from the IKE daemon for the corresponding stack.

Parameters

AllowNat

Indicates whether negotiations that use NAT traversal techniques are allowed when the AllowNat parameter is omitted from a KeyExchangeAction statement. The value Yes indicates that negotiations that use NAT traversal techniques are allowed when the AllowNat parameter is omitted from a KeyExchangeAction statement. The value No indicates that negotiations that use NAT traversal techniques are not allowed when the AllowNat parameter is omitted from a KeyExchangeAction statement. The default value is No.

Rule: If you change the AllowNat setting, the change is effective immediately for any new phase 1 security associations (SAs) that are negotiated. For existing phase 1 SAs, the change takes effect when the phase 1 SA is refreshed.

Tip: Setting the AllowNat to No prevents the IKE daemon from sending NAT payloads or processing received NAT payloads as part of the tunnel negotiation. In some cases. tunnels traversing one or more NATs can still be activated even when AllowNat is set to No. However, such tunnels are normally unusable because of the known incompatibilities between IPsec and NAT documented in RFC 3715.

NatKeepAliveInterval

When the IKE server is behind a NAT device it might need to send NAT keepalive messages to remote security endpoints. These keepalive messages must be sent to a remote security endpoint when all of the following conditions are true:

• IKE is behind a NAT device that dynamically maps IKE's IP address to a public IP address.
• A phase 1 SA exists with that remote security endpoint.
• No other packets have been sent to that remote security endpoint within a configured inactivity interval.

The purpose of a NAT keepalive message is to prevent a NAT device from expiring dynamic NAT mappings. NAT keep alive messages are not required when no NAT device is in front of the IKE server or when the NAT device in front of the IKE server statically maps the IKE servers IP address to a public IP address.

interval

The configured inactivity interval in seconds. Valid values are 0 or within the range 20-999. A value of 0 indicates that NAT keepalive messages should never be sent. A value in the range 20 - 999 indicates the number of seconds of inactivity that triggers the sending of a NAT keepalive message. The default is 20 seconds.

Rule: A change to the NatKeepAliveInterval interval is effective immediately for any new timer started. For existing timers a change takes effect when the timer expires. It is rescheduled with the new interval value.

Tip: The following should be considered in defining the interval value for the NatKeepAliveInterval parameter:

• The KeepAlive timer runs only if there is a NAT device in front of z/OS®.
• If a static NAT device is in front of z/OS, then a value of 0 should be defined for the interval.
• If a dynamic NAT device is in front of z/OS, then a value less than the mapping expiration of the NAT device should be defined.

LivenessInterval

When IKE negotiates a security association using IKE version 2 (IKEv2), IKE can perform periodic liveness checks as prescribed in RFC 5996 to test whether the peer remains active. When traffic was sent but not received on an IKE SA or any of its associated dynamic tunnels, IKE initiates a liveness check after the liveness interval period is exceeded. IKE does this by sending the peer a request to which the peer is expected to respond. If, after the normal series of IKE retransmissions, the peer has not responded, the IKE SA and associated dynamic tunnels are considered non-responsive and are deleted. See the IkeInitWait parameter and the IkeRetries parameter for more information.

The purpose of the liveness check is to verify whether an IKEv2 peer is still active. This allows IKE to detect cases such as when a peer has rebooted or when dynamic tunnels are non-responsive. This allows IKE to re-establish communications with the peer in a timely manner.

Restriction: This parameter is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

interval

The configured liveness interval in seconds. Valid values are 0 - 20999. A value of 0 indicates that liveness checks should never be performed. A value in the range 1 - 20999 indicates the number of seconds of inactivity that triggers the sending of liveness check request. The default is 30 seconds.

Rule: A change to the LivenessInterval is effective immediately for any new timer started. For existing timers a change takes effect when the timer expires. It is rescheduled with the new interval value.

Results:

1. LivenessInterval is used only for IKE version 2 security associations. This value is ignored for IKE version 1 security associations.
2. Liveness checks are performed only when data has been sent over the IKE SA or dynamic tunnels but not received. If no data is being either sent or received, then no liveness checks are performed.

HowToInitiate

The negotiation mode to use when initiating a KeyExchangeAction statement does not contain a HowToInitiate parameter. The default is Main.

Restriction: This parameter is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

Main

Indicates that IKE version 1 with identity protection is used when key negotiations are initiated by this system.

Aggressive

Indicates that IKE version 1 without identity protection is used when key negotiations are initiated by this system.

IKEv2

Indicates that IKE version 2 is used when key negotiations are initiated by this system.

DoNot

Indicates that the local system cannot initiate a key exchange negotiation.

KeyExchangeRule

An inline specification of a KeyExchangeRule statement to be included in the policy.

KeyExchangeRuleRef

The name of a globally defined KeyExchangeRule statement to be included in the policy.

KeyExchangeGroupRef

The name of a globally defined KeyExchangeGroup statement to be included in the policy.

BypassIpValidation

Indicates whether a check should be made to verify that the remote peer's identity matches the peer's remote IP address. A value of Yes indicates the check should be bypassed. A value of No indicates the check should be enforced. The default is No,

Restriction:The BypassIpValidation keyword is ignored when the identity of the peer is not an IPv4 or IPv6 address.

Restriction: This parameter is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

Tip: If the remote security endpoint is expected to be behind a NAT, specify a value of Yes.

CertificateURLLookupPreference

Indicates hash and URL encoding preference in certificate payloads and certificate request payloads sent and received.

Allow

IKED provides the remote security endpoint with an indication that it prefers to receive certificate payloads encoded in a hash and URL format. IKED processes certificate payloads encoded using a hash and URL format when they are received. IKED attempts to send certificate payloads using a hash and URL format encoding when the remote security endpoint indicates a preference to receive certificate payloads encoded in a hash and URL format.

Tolerate

IKED does not provide the remote security endpoint with an indication that it prefers to receive certificate payloads encoded in a hash and URL format. IKED processes certificate payloads encoded using a hash and URL format when they are received. IKED attempts to send certificate payloads using a hash and URL format encoding when the remote security endpoint indicates a preference to receive certificate payloads encoded in a hash and URL format. This is the default value.

Disallow

IKED does not provide the remote security endpoint with an indication that it prefers to receive certificate payloads encoded in a hash and URL format. IKED ignores certificate payloads encoded using a hash and URL format when they are received. IKED does not send certificate payloads using a hash and URL format.

Restriction: This keyword is ignored when IKE version 1 IKE SAs are negotiated since IKE version 1 does not support hash and URL encoding of certificate data.

Restriction: This parameter is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

RevocationChecking

Indicates the level of revocation checking to be performed on a remote security endpoint's certificate and its corresponding certificate authority certificates. The default is Loose.

None

No revocation checking is performed.

Loose

Revocation information is checked if available.

Strict

Revocation information must be available for all certificates and is checked for all certificates

Rules:

• Revocation checking is only applicable to digital signature authentication methods.
• When the mode is Loose and revocation information for a certificate is unavailable, then that certificate is considered valid.
• When the mode is Strict and revocation information for a certificate is unavailable, then that certificate is considered invalid.
• When the mode is Strict or Loose and a source of revocation information checked indicates that a certificate is revoked then the certificate is considered invalid.
• If a CRL can be obtained using the CRLDistributionPoints extension and a certificate bundle file, the CRL obtained from the CRLDistributionPoints extension is used and the CRL in the certificate bundle or certificate payload is ignored.
• When IKED is configured to use the native IKE daemon certificate service the RevocationChecking parameter is ignored.

Rule: A CRL received in a certificate payload is ignored.

Restrictions:

• This parameter is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details.
• Certificate revocation lists (CRL) are the only source of revocation information consulted. The CRL must be identified in the CRLDistributionPoints extension of the certificate being checked or contained in a certificate bundle file identified by the remote security endpoint.
• When the CRLDistributionPoints extension is used to retrieve a CRL at least one distribution point must contain an HTTP URL.
• IKED will only consult a CRL that contain entries for all revocation reasons.
• The native IKE daemon certificate service does not consult certificate revocation information when authenticating a digital signature. If certificate revocation information is consulted then IKED must be configured as a network security client.