z/OS Communications Server - Group home

We  have already introduced z/OS Encryption Readiness Technology (zERT), which monitors a wide variety of cryptographic protection attributes for TCP and Enterprise Extender (EE) traffic on z/OS, and provided some details of zERT discovery and zERT aggregation. Now let's clearly define some of the important terms that you’ll see used with zERT.

Cryptographic Protocol Provider (CPP): A z/OS-resident component that processes a specific cryptographic network security protocol (i.e., TLS/SSL, IPSec or SSH).  There are a few categories of CPPs:
– IBM zERT-enabled CPPs: z/OS System SSL, z/OS OpenSSH and the IPSec support in the z/OS TCP/IP stack
– IBM non-zERT-enabled CPPs: Java Secure Sockets Extension (JSSE).  As of this writing, z/OS JSSE is not zERT-enabled
– 3rd party non-zERT-enabled: Tectia SSH for z/OS, OpenSSL (ported to z/OS), etc.

Protection state: The cumulative state of cryptographic protection of a connection. There are several possible combinations here:
– No cryptographic protection (connection is in cleartext mode)
– Protection from a single cryptographic protocol (the most common case)
– Protection from multiple cryptographic protocols (for example, a TCP connection protected by both TLS and IPSec)

The key point here is that a single TCP connection can be protected by zero or more cryptographic protocols.  For Enterprise Extender, which is based on UDP, the only supported cryptographic protocol is IPSec.

Application connection: A sockets-based connection between two application programs. No security is implied or provided – it’s just a cleartext path over which two programs communicate.

Security session: The application (by a CPP) of an agreed-to set of security attributes (as defined by a cryptographic security protocol) to one or more application connections between the same client and server.  Examples are TLS/SSL sessions, IPSec tunnels, and SSH sessions.

Here is an example using TLS to help you better understand the differences between an Application connection and a Security session.

1. Client application establishes a TCP connection with the server.
2. Client application initiates a TLS handshake which authenticates the server (and, optionally, client) and negotiates a cipher suite and keys to be used to protect the data. Upon successful completion of the handshake, a secure TLS session exists between the communication partners to protect the TCP connection.
3. Data flows over the TCP connection under protection of the TLS session using the cryptographic algorithms and keys negotiated during the handshake.

A firm understanding of these terms will make it easier to understand and to use zERT discovery and zERT aggregation.