IPIC connection security

IPIC connection security provides the ability to control which remote systems can connect to a CICS® region, based on the supplied connection parameters. This process can be controlled either by using the installation process of the IPCONN resource or by using TLS client and server authentication.

Connections between CICS systems usually have two inbound sockets in each direction, making a total of four sockets per IPIC connection: two inbound and two outbound in each direction.

Connections between CICS and a client, such as z/OS® Connect, use one-way IPIC connections. These one-way connections have only inbound sockets. Either one or two of these sockets are used depending on how many were initiated by the client.

For each socket, connection security can be implemented at any of the following stages:

When the socket is established (TCP/IP 3-way handshake)

A 3-way handshake is used by the TCP/IP stack to open the socket connection between the local CICS region and the remote CICS region. This handshake uses the remote host and port information from the local IPCONN resource definition. If the local system is an IPIC client, such as z/OS Connect or CICS Transaction Gateway, then the equivalent values are used from the client configuration file. It is a three-step process that requires both the client and server to exchange synchronization (SYN) and acknowledgment (ACK) packets before the real data communication process starts.

You can control the ability to create a TCP/IP socket connection between two IP addresses in a z/OS sysplex by using SAF SERVAUTH class. This class prevents unauthorized user access to TCP/IP resources, including TCP/IP stacks, ports, and networks. Additionally, external network security devices, such as firewalls, can be used to allow or block incoming and outgoing network traffic.

When the TLS session is established (TLS handshake)

After the TCP/IP socket is established, a TLS handshake is performed if TLS support is specified in the CICS TCPIPSERVICE definition. The TLS handshake negotiates the cipher suite, validates the client and server certificates, and then creates an encrypted session for the exchange of further requests. Figure 1 shows a TLS handshake without client authentication at TLS 1.2 or earlier.

TLS can be used to control if a client and server system can connect to each other, and provides similar function to that provided by CICS MRO and APPC bind time security (see Intercommunication security). This control is based on public key cryptography. Authentication is performed by an exchange of X.509 certificates. The X.509 certificates are issued and digitally signed by an external authority, which is known as a certificate authority (CA). Certificates are used to authenticate clients to servers and servers to clients. The mechanism that is used is essentially the same in both cases. However, the server certificate is mandatory: that is, the server must send its certificate to the client, but the client certificate is optional, and servers decide whether to require client authentication for a connection.

Certificates are stored in a RACF® key ring and the CICS region user ID must be authorized to access a specific key ring that contains all the certificates that it needs to establish TLS connections with its partners. The personal certificates in the key ring are used to identify client and server. The signer certificates are used by the partner system to authenticate these certificates by using the public key from the CA.

For more information, see Transport Layer Security (TLS) for IP connections .

At the IPIC capability exchange (CAPEX) request

After the socket and its TLS session are established, the CICS IPIC capability exchange (CAPEX) request is the first request to flow between the local and remote CICS regions. The remote CICS region validates the CAPEX and uses the supplied information either to locate a matching IPCONN resource definition, or, if the IPIC autoinstall program is active, to install a new IPCONN resource definition.

The CAPEX response, including any negotiated IPIC session values, is returned from the remote CICS region to the local CICS region and, if required, a further socket is created by the local CICS region. If the connection is a 2-way IPCONN for CICS-to-CICS connectivity, the same process is repeated from the remote CICS region to the local CICS region to establish the inbound sockets and install the IPCONN resource definition in the local CICS region.

By default, TCPIPSERVICE resource definitions that have a PROTOCOL of IPIC specify the use of the default autoinstall program DFHISAIP. This program allows IPIC CAPEX requests from any system to connect dynamically if no matching IPCONN resource definition can be located.

Security best practice (validated by IBM Health Checker for z/OS): It is recommended that you do not use the default autoinstall program DFHISAIP in production. This can be done by setting the user-replaceable module (URM) attribute in the relevant TCPIPSERVICE resource definition to NO (meaning no URM is used) or to a user written URM. This is to prevent connections from any system.

A custom autoinstall URM can be written to validate incoming CAPEX requests. A sample program, DFH$ISAI, is supplied by CICS to validate connections based on a pre-defined network name, then uses this to locate an IPCONN resource definition template. For more information about the IPIC autoinstall user replaceable modules (URM), see Sample autoinstall user program to support predefined connection templates.