The following actions occur during a phase 1 IKE exchange:
- Peers exchange encoded certificate information in certificate
payloads
- The NSS server provides the IKED with certificate information
to send
- The IKED forwards the encoded certificate information that it
received from the NSS server
IKEv2 defines two new encoding types that require the use of
an HTTP server:
- Hash and URL of a certificate
- Hash and URL of a certificate bundle
The NSS server supports these new encoding types; however, by
default the IKED does not support sending or receiving them.
Use the CertificateURLLookupPreference parameter on the KeyExchangePolicy
and KeyExchangeAction statements in the IP security policy configuration
file to enable the IKED to use the hash and URL encoding types. Code
the appropriate value on the CertificateURLLookupPreference parameter:
- Disallow, which is the default value, indicates that the IKED
will not send the new encoding type and will ignore the new encoding
type when received.
- Tolerate indicates that the IKED will not send the new encoding
type, but it will accept the new encoding type when received.
- Allow indicates that the IKED may send the new encoding type and
it will accept the new encoding type when received.
Rule: You must configure the NSS server
appropriately before the IKED can send the new encoding types.
Enabling this capability might result in smaller messages being
exchanged between the IKED and its remote security endpoint as well
as the IKED and the NSS server; however, it may also result in increased
latency during an IKEv2 negotiation.
For more details about the CertificateURLLookupPreference parameter
on the KeyExchangePolicy and KeyExchangeAction statements, see z/OS Communications Server: IP Configuration
Reference. For more details about configuring the
NSS sever to use the new certificate encoding types, see Using hash and URL certificate encoding types.