z/OS Communications Server - Group home

z/OS V2R5 is here!  If you check out any of the press coverage or if you ventured to read the z/OS V2R5 announcement letter, you know it's loaded with lots of great new features and enhancements.   If you focus on z/OS network security like me, you have plenty to be excited about in your own right.   Here are six reasons I am excited about z/OS V2R5:
 

1. zERT policy-based enforcement

z/OS Encryption Readiness Technology has been part of z/OS since V2R3, providing a detailed SMF audit trail of the cryptographic network protection attributes for all the TCP and Enterprise Extender (EE) connections that terminate on the local z/OS TCP/IP stack.  The z/OS community quickly adopted and implemented zERT on their systems to gain a clear understanding of the strengths and weaknesses in their z/OS network security protection. 

With V2R5, we have taken zERT to the next level – from a simple audit trail to active, realtime monitoring of cryptographic network protection through user-configured rules and actions.  zERT policy-based enforcement is configured through a new perspective of the z/OSMF Network Configuration Assistant (NCA).  The z/OS Communications Server Policy Agent installs the NCA-generated rules into the TCP/IP stack.  

zERT rules can specify either acceptable or unacceptable protection according to your local security standards along with the actions to take when a connection matches the attributes specified on the rule.  Available actions are:

• Silently allow the connection (this is the default action)
• Log the connection to syslogd
• Log the connection to the console (TCP/IP job log)
• Write a special SMF type 119 subtype 11 zERT Connection Detail record - the writing of these records can be enabled separately from all the other subtype 11 records, giving you an audit trail of just the connections that match rules with this type of action.
• Reset (drop) the TCP connection

Note that the logging, audit (SMF) and reset actions can be combined as needed on the same rule.

Once the zERT rules are installed, every new TCP connection that is established to or from the TCP/IP stack will be evaluated against the rule sets for whichever network security protocol (TLS, SSL, IPsec, SSH) are used to protect that connection.  You can also define rules for connections that do not have any recognized cryptographic protection.   

zERT policy-based enforcement gives you very granular, real-time reporting and control over connections that use questionable or unacceptable protection.

2. TLSv1.3 (and even some TLSv1.2) performance enhancements

Support for TLSv1.3, the latest TLS standard adopted by the IETF in 2018, was added to System SSL and AT-TLS in V2R4.  TLSv1.3 beefs up connection security in several ways, including mandatory use of key exchange algorithms that ensure forward secrecy, earlier encryption of handshake messages, and the use of some new cryptographic algorithms. 

When first implemented, some of the newer cryptographic algorithms were only implemented in software, which consumed large amounts of CPU.  With z/OS V2R5, hardware acceleration using Crypto Express adapters and z15 CPACF provides a dramatic performance boost for those mandatory algorithms, both in terms of reduced CPU consumption as well as increased throughput.   As an added benefit, the z15 CPACF acceleration for elliptic curve key exchange operations provides a big boost to TLSv1.2 handshakes that use ECDHE-based cipher suites (that enhancement is also available through ICSF APAR 0A58377 (for HCR77D1) on V2R4).

Bottom line, these performance enhancements make TLSv1.3 competitive with TLSv1.2 and greatly reduce the cost of using TLSv1.2 ECDHE-based cipher suites, which many organizations now require.

3. System SSL, AT-TLS, and IKE (IPsec) digital certificate diagnostic enhancements

Working with X.509 digital certificates on z/OS is well known to come with some complexities.  With V2R5, a few enhancements are added to begin simplifying z/OS digital certificate administration and diagnosis.  

The first of these is the addition of more detailed diagnostic information to AT-TLS and IKE daemon syslogd messages when AT-TLS handshakes or IKE negotiations fail while validating a remote peer's certificate. Prior to V2R5, this level of information was only available through System SSL traces.  With this enhancement, you will find:

• detailed error codes that unambiguously identify errors related to certificates received from remote communication partners
• an ordered listing of all the Certificate Authority and end-entity certificates sent by the communication partner
• which of those certificates was found to be in error.  

Note that all the above error information is also available to any application that calls System SSL directly through new and enhanced programming interfaces.

This new support should eliminate the need to take System SSL traces in most of the situations that previously required them and should simplify AT-TLS and IKE certificate-related problem determination.

4. IPsec certificate reporting enhancements

Next, certificate-related reporting of the ipsec -k display command, the IPsec network management interface (NMI), and SMF type 119 subtype 73 and 74 records are enhanced to make it easier to validate IPsec-related X.509 certificate configurations.  The enhancements provide information about the X.509 certificates used during Internet Key Exchange (IKE) negotiations by the local and remote IKE peers, including certificate expiration information, certificate serial number, and subject and issuer distinguished names.   Having this information easily accessible reduces the need to search through message logs to verify when refreshed certificates are put into use by the IKE daemon.

5. Digital certificate fingerprints

Another common pain point related to digital certificates on z/OS is identifying which certificates are and are not being used.   With V2R5, RACF and z/OS PKI Services add support for SHA-256 "fingerprints" which uniquely identifies each certificate.  These fingerprints are displayed by the relevant RACDCERT commands and PKI Services web pages, are searchable through PKI Services, and are included in SMF records that both RACF and PKI Service write. 

SHA-256 fingerprints are commonly displayed by certificate-related tooling on other platforms as well, making it easier to match up the exact certificates used by z/OS in certificate exchanges like those used in TLS handshakes and IKED negotiations.

6. Notification of availability of TCP/IP extended services

While this one isn't directly focused on network security, it provides a solution to the age-old question "when is the TCP/IP stack ready for my application to begin secure communications?" 

Prior to V2R5, there was no straightforward way for an application to know when extended services like sysplex dynamic VIPA (DVIPA) initialization, IP security infrastructure initialization, and completion of network policy installation were complete for a TCP/IP stack.    With this V2R5 enhancement, the TCP/IP stack emits a clear message indicating that not only the TCP/IP stack has completed initialization, but also all the required extended services have as well.  

In addition to the new console message, a new ENF signal and a new system-scope name/token pair are introduced so applications can programmatically determine whether or when the stack and its extended services have initialized.


So there they are - six new or enhanced capabilities to help you secure your z/OS network connections!  I hope you get a chance to dig into these and many other enhancements that come in z/OS V2R5!    For more information, check out the What is new in z/OS (V2R4-V2R5) topic on the IBM z/OS Documentation center.