As computer threats evolve, so, too, do security controls and the standards around them. In 2011, the U.S. National Institute of Standards and Technology (NIST) issued a document titled “Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths,” which outlines a path of migration and upgrade for existing network security infrastructure. It specifically recommends changes in algorithm usage and an increase in the key lengths required for cryptographic operations within a particular timeline.

For example, the use of public-key cryptography for connecting two systems securely has used a default key length of 1024 bits in the past. This key length, while still reasonable for many operations, is no longer considered “secure enough” for particularly sensitive information. The standard now recommends a key length of 2048 bits to maintain a secure posture against today’s threats.

The mainframe is no exception to these new rules. The System z hardware, operating systems and hypervisors are moving not only to support the maximum values identified by these standards, but to enforce the minimum values as well. While a guest has its own security configuration and faces threats particular to it, it’s essential to note that protecting the hypervisor is an equally important part of an end-to-end security policy. Access to the hypervisor grants a special form of access to any particular guests, so it’s critical to maintain secure connectivity to and from the hypervisor.

Reintroducing the z/VM V6.3 SSL Server

z/VM has long supported a security server for TCP/IP traffic. The current server is a pool of commonly configured virtual machines associated with a particular TCP/IP stack. This server handles the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols for z/VM. In addition to negotiating the handshake, these protocols encrypt and decrypt traffic to and from the hypervisor layer. This cryptographic barrier extends security controls to prevent unauthorized modification to the Control Program or to the guests running underneath it.

In previous versions and releases of z/VM, the SSL Server supported the SSL 3.0 and TLS 1.0 protocols. Its cryptographic library, a port of z/OS’s System SSL feature, provided security support for asymmetric key sizes up to 4096. However, z/VM’s implementation only surfaced one configuration option to augment available security—an EXEMPT statement to disable a specific cipher suite. A cipher suite, which is a combination of asymmetric key exchange, symmetric encryption standard, hashing algorithm and key length requisites may vary in applicability from protocol to protocol, and some have proven more durable than others over time. This option, while important in managing security policy, lacked granularity and didn’t account for more recent protocol versions.

z/VM Version 6.3, made Generally Available in July 2013, has upgraded the SSL Server in several ways. First, it allows for the encryption and decryption of IPv6 traffic. It supports the verification of a client’s certificate during the handshaking process. Finally, and most important, it offers new options for the configuration of security policy for the TCP/IP stack. It adds support for SSL/TLS protocol selection, and its underlying System SSL library adds support for TLS 1.2. Through a New Function APAR PM93363, z/VM V6.3 delivers the capability to place the SSL Server into an 800-131a-compliant mode through a single option.

These options not only benefit those system or network administrators beholden to obey a strict SP 800-131a requirement, but they allow for greater flexibility in managing secure connectivity to the hypervisor. 

Selecting an SSL or TLS Protocol Version

The first part of controlling secure connectivity to z/VM is control of the protocols usable by the z/VM SSL Server. By default, the SSL Server continues to provide SSL v3 and TLS 1.0. While these may be sufficient for some installations, other security policies may require a system administrator to enable other protocols or to disable the defaults entirely.

z/VM V6.3 provides an SSL Server that supports connections ranging from SSL v2 up to TLS 1.2. The protocols can be enabled or disabled through the use of a new PROTOCOL keyword. This keyword is specified in the DTCPARMS file, which defines all the other server options in a z/VM TCP/IP configuration. The DTCPARMS file is read-only during the start-up of an SSL Server—most commonly, when the TCP/IP stack is coming online. These options can’t be modified while the SSL Server is in use, so using them requires some advance planning.

In an SSL Server definition, the PROTOCOL keyword is specified as part of the raspberryarms list of options. The server defined in Figure 1 is a pool of SSL servers—multiple virtual machines that encrypt traffic for a single TCP/IP stack. They must all abide by the security rules defined in the DTCPARMS file. In this case, the parameters include the enablement of TLS 1.2, TLS 1.1 and SSL v3. TLS 1.0 and SSL v2 are disabled.

2 Pages