Identity information

Multiple identities can be assigned down to the level of individual IP addresses for each IKE negotiation, or for ease of configuration, a single identity can be assigned to represent the IKE daemon for the TCP/IP stack. With either method, the identity that is assigned must be an identity that is known to the remote IKE peer. Similarly, the local server must know the identity of any remote IKE peer with which it is to negotiate.

Guideline: Do not use the same identity on more than one TCP/IP stack or z/OS® system image. IKED assumes that an identity is not used by any other stack, and this assumption can lead to a disruption of IPSec service for other stacks when identities are shared between stacks.

The identity can be one of the following types:

X500dn (the host’s X.500 distinguished name)
IpAddr (an IP address)
Fqdn (a fully qualified domain name)
UserAtFqdn (an email address)
KeyID (EBCDIC, ASCII or hexadecimal string)
Restriction: An identity of KeyID is valid only when using preshared key authentication.

If a digital signature method of peer authentication is used, the local identity must be in an X.509 digital certificate on the IKE daemon's key ring for an IKEv1 negotiation, or on the NSS server's key ring for an IKEv1 or IKEv2 negotiation that uses the NSS certificate service. If the pre-shared key method of peer authentication is used, any of the identity types can be used to identify this IKE peer. Because digital certificates are not used in the pre-shared key method, the only requirement for the use of an identity type is that it be known to both hosts.

Identity information is configured using the LocalSecurityEndpoint and RemoteSecurityEndpoint statements in an IP security policy configuration file. For more details about the LocalSecurityEndpoint and RemoteSecurityEndpoint statements, see z/OS Communications Server: IP Configuration Reference.