Use of AT-TLS with IBM MQ for z/OS

Application Transparent Transport Layer Security (AT-TLS) provides TLS support for z/OS® applications without those applications having to implement TLS support, or even be aware that TLS is being used. AT-TLS is only available on z/OS.

AT-TLS can be used with all versions of IBM® MQ for z/OS.

Before making use of AT-TLS with IBM MQ for z/OS, make sure you understand the Restrictions involved.

To use Application Transparent Transport Layer Security you define policy statements containing a set of rules which are used by z/OS Communications Server to decide which TCP/IP connections have TLS transparently enabled.

IBM MQ for z/OS has its own TLS implementation, which requires that channels have the SSLCIPH parameter configured with a supported CipherSpec.

When deciding to enable TLS on a channel the IBM MQ administrator can decide to either use AT-TLS or IBM MQ TLS. The decision is often made based on whether AT-TLS is used for other middleware, or because of performance implications. For a basic comparison of the performance of AT-TLS and IBM MQ TLS see MP16: Capacity Planning and Tuning for IBM MQ for z/OS.

Scenarios

Use of AT-TLS with IBM MQ is supported in the following scenarios:

Scenario 1

Between two IBM MQ for z/OS queue managers where both sides of the channel use AT-TLS. That is, neither channel specifies the SSLCIPH attribute. This approach can be used with any message channel.

Image showing two queue managers where both sides of the channel use AT-TLS

Implementation of this scenario consists of defining two AT-TLS policies, one for each side of the channel. These policies are the same as those used with Scenario 3.

For example, if the channel was being changed from using a single, named CipherSpec to using AT-TLS, the outbound channel would use the policy from Configuring AT-TLS on an outbound channel to an IBM MQ for Multiplatforms queue manager using a single, named CipherSpec and the inbound channel would use the policy from Configuring AT-TLS on an inbound channel from an IBM MQ for Multiplatforms queue manager using a single, named CipherSpec.

Scenario 2

Between an IBM MQ for z/OS queue manager and an IBM MQ Java client application running on z/OS where both sides of the channel use AT-TLS. That is, neither the server-connection channel, nor the client-connection channel specify the SSLCIPH attribute.

Image showing a z/OS queue manager and a Java client application where both sides of the channel use AT-TLS

Implementation of this scenario consists of defining two AT-TLS policies, one for each side of the channel. These policies are the same as those used with Scenario 3.

For example, if the channel was being changed from using a single, named CipherSpec to using AT-TLS the client-connection channel would use the policy from Configuring AT-TLS on an outbound channel to an IBM MQ for Multiplatforms queue manager using a single, named CipherSpec and the server-connection channel would use the policy from Configuring AT-TLS on an inbound channel from an IBM MQ for Multiplatforms queue manager using a single, named CipherSpec.

Scenario 3

Between an IBM MQ for z/OS queue manager and a queue manager running on IBM MQ for Multiplatforms, where the IBM MQ for z/OS queue manager uses AT-TLS and the IBM MQ for Multiplatforms queue manager uses IBM MQ TLS. This applies to all message channel types other than cluster-sender and cluster-receiver.

Image showing a z/OS queue manager using AT-TLS and a Multiplatform queue manager using MQ-TLS

See Configuring AT-TLS on an outbound channel to an IBM MQ for Multiplatforms queue manager using a single, named CipherSpec for an example AT-TLS configuration for outbound channels from the IBM MQ for z/OS queue manager to the IBM MQ for Multiplatforms queue manager, and Configuring AT-TLS on an inbound channel from an IBM MQ for Multiplatforms queue manager using a single, named CipherSpec for an example AT-TLS configuration for inbound channels from the IBM MQ for Multiplatforms queue manager to the IBM MQ for z/OS queue manager.

The same AT-TLS configuration can be used when both queue managers are on z/OS, but the queue manager on the right hand side has not been configured to use AT-TLS.

Scenario 4

Between an IBM MQ for z/OS queue manager and a client application running on IBM MQ for Multiplatforms, where the IBM MQ for z/OS queue manager uses AT-TLS and the client application uses IBM MQ TLS by specifying the SSLCIPH attribute with a single, named CipherSpec.

Image showing a z/OS queue manager using AT-TLS and a client application on Multiplatforms using MQ-TLS, by specifying the SSLCIPH attribute with a single named CipherSpec

This scenario requires a single AT-TLS policy which meets the same requirements as those used by an inbound message channel; see Configuring AT-TLS on an inbound channel from an IBM MQ for Multiplatforms queue manager using a single, named CipherSpec.

The same AT-TLS configuration can be used when the client application is a Java application, and is also running on z/OS, but has not been configured to use AT-TLS.

Restrictions

IBM MQ for z/OS is not AT-TLS aware, therefore there are several restrictions that apply with the preceding scenarios:

AT-TLS in combination with IBM MQ TLS does not work with cluster-sender and cluster-receiver channels.
IBM MQ for z/OS queue managers are not aware that they are using AT-TLS and do not receive any certificate information from their partner queue manager or client. Therefore, the following attributes have no effect on the z/OS side of a channel using AT-TLS:
- The SSLCAUTH, and SSLPEER channel attributes
- The SSLRKEYC queue manager attribute
- The SSLPEERMAP attributes of CHLAUTH rules
Use of TLS secret key renegotiation requires that both sides of the channel use IBM MQ TLS. Therefore, an IBM MQ for Multiplatforms queue manager, or client, should not have TLS secret key renegotiation enabled if connecting to an IBM MQ for z/OS queue manager using AT-TLS.
To disable TLS secret key renegotiation for a queue manager set the queue manager SSLRKEYC parameter to 0. For a client, set the relevant parameter to 0 depending on client type. For details on how to do this, see Resetting SSL and TLS secret keys.

AT-TLS configuration statements

AT-TLS is configured using a set of statements. The ones used in the scenarios documented in this topic are:

TTLSRule: Specifies a set of criteria for matching a TCP/IP connection to a TLS configuration. This in turn refers to the other statement types.
TTLSGroupAction: Specifies whether the referencing TTLSRule is enabled or not.
TTLSEnvironmentAction: Specifies the detailed configuration for the referencing TTLSRule and references a number of other statements.
TTLSKeyringParms: References the key-ring that is to be used by AT-TLS.
TTLSCipherParms: Defines the cipher suites that are to be used.
TTLSEnvironmentAdvancedParms: Defines which TLS or SSL protocols are enabled.

Attention: There are other AT-TLS policy statements with AT-TLS which are not documented here, and could be used with IBM MQ depending on need. However, IBM MQ has only been tested with the policies described in this topic.