TLS 1.2 is the newest of the point-to-point encryption protocols, and it provides a couple of new features. First, it allows for hashing in the SHA2 family of ciphers (SHA-256 and above). These ciphers are exclusive to this highest level. Second, it will prevent the use of some older ciphers—DES and the “export ciphers” can’t be used through the TLS 1.2 protocol. Finally, it will automatically disable SSL v2 if it’s enabled, as the two protocols can’t coexist.
TLS 1.0 and SSL v3 are enabled by default, so they don’t have to be specified. However, as previously mentioned, a disabling statement must be specified to prevent their use.
When a protocol is enabled, this allows a client application (such as IBM Personal Communications 6.0.8) to negotiate its use during the SSL/TLS handshaking process. If a client and the server can’t agree on a common protocol, then connectivity won’t be established. As a result, you must be certain the application being used to connect to z/VM can support the security protocols being specified.
Enabling New Cryptographic Policies
z/VM V6.3 delivers key functionality in allowing for the upper boundaries of security policy to expand. However, the second half of NIST SP 800-131a is a minimum level of security. This functionality isn’t available in the base z/VM V6.3 product; it’s only available through the application of a PTF.
APAR PM93363 introduces a second new keyword called MODE, which automatically configures the SSL Server to meet a particular cryptographic policy. z/VM V6.3 supports two cryptographic modes: FIPS 140-2 and NIST SP 800-131a.
The Federal Information Processing Standard (FIPS) 140-2 has existed for some time, and z/VM V6.1 was validated as meeting its requirements when configured with a keyword FIPS. (An evaluation for z/VM V6.3 is currently in progress, per an IBM Statement of Direction released in July 2013.) FIPS 140-2 places certain restrictions on both the protocols and ciphers the z/VM SSL Server can use. Specifically, MODE FIPS-140-2 enforces only TLS protocols and restricts the use of cipher suites to ones that have been approved for FIPS-level usage.
FIPS mode can be specified through the MODE keyword on the arms statement in the DTCPARMS file (see Figure 2). Using FIPS mode also requires the use of a FIPS-mode certificate database. A FIPS-mode certificate database is digitally signed and verified during the initialization of the SSL Server to determine if tampering has occurred. This verification is accomplished through a combination of RSA Known Answer testing and HMAC-SHA256 integrity checking. This cryptographic mode requires a minimum key length of 1024 for asymmetric key exchange; either RSA or DSA signed certificates are valid in this mode.
MODE NIST-800-131A is a distinct mode of operation and is separate from FIPS mode (see Figure 3). This mode of operation carries several conditions with it. The first, as noted previously, is that only TLS 1.2 can be used with this mode. Attempting to use any other protocol with this mode will result in a warning message, and failure to enable TLS 1.2 via the PROTOCOL operand will prevent the SSL Server from commencing operation. This is because NIST SP 800-131a requires the use of the SHA2 family of hashes, and these hashes are only operable when using TLS 1.2.
The second condition is the asymmetric key exchange; the minimum key length in this mode is 2048. z/VM V6.3’s System SSL implementation is a port of similar function for z/OS V1.13 (with some added function). Because this crypto library on z/VM V6.3 supports a maximum DSA key length of 1024, no DSA-signed certificates can be used in this mode. Similarly, RSA-signed certificates of length 1024 will be rejected, even if hashed with SHA-256 or SHA-512. There are no requirements on the certificate database when using MODE NIST-800-131A. All the requirements in this case are placed on the certificates. Fortunately, the state of existing certificates (and determination of whether they meet these conditions) can be examined through the gskkyman application. This application is a port of the z/OS function of the same name; it’s executable from the GSKADMIN virtual machine or a similarly configured guest. Gskkyman allows for certificate database management as well as certificate import and export.
Can these modes of operation be combined? Yes, they can; however, because they adhere to a different set of requisites, combining them restricts the SSL Server configuration to the maximal common subset of functionality–TLS 1.2 exclusively, a minimum key exchange length of 2048, and a FIPS-mode certificate database. This will provide exemplary security strength with very little flexibility.
z/VM V6.3 delivers some significant improvements to the strength and configurability of TCP/IP network security. The availability of TLS 1.2 allows for state-of-the-art encrypted connections to or from the hypervisor layer, and the implementation of the PROTOCOL operand allows for non-default SSL/TLS settings to be configured. APAR PM93363 further refines security capability by allowing for automatic configuration of an SSL Server (or pool thereof) to meet a particular cryptographic standard. The key determination will be what configuration provides the appropriate levels of security strength, network speed and certificate flexibility for a z/VM administrator’s environment. With the upgraded cryptographic library and configuration settings, though, an administrator has some options at his disposal.
NIST SP 800-131A: “Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths,” www.nist.gov/manuscript-publication-search.cfm?pub_id=907517.