Start of change

Customizing DCAS for TLS/SSL

You can customize DCAS to use IBM® System SSL or implement TLS security by using AT-TLS policies.

Before you begin

Ensure that you have the following setup or configuration:
Guideline: Using AT-TLS is the preferred way to implement TLS security because it provides access to the latest features of System SSL, including the newest TLS versions and cipher suites. DCAS's direct use of System SSL is limited to TLS version 1.0 and SSL versions 3 and 2 and it does not exploit many other System SSL features that AT-TLS can.
Requirement: To use AT-TLS, you must configure the Policy Agent and enable the TCP/IP stack for AT-TLS. To configure AT-TLS, see Application Transparent Transport Layer Security data protection.

Procedure

Complete the following steps to customize DCAS to use IBM System SSL or implement TLS security by using AT-TLS policies.

  1. Code the following statement in the DCAS configuration file to enable the server for AT-TLS:
    TLSMECHANISM ATTLS
  2. Decide the level of authentication that you use for TLS sessions:
    • Server authentication only
    • Client authentication level 1
    • Client authentication level 2
    • Client authentication level 3
    For more information about server authentication and client authentication, see Secure Socket Layer overview.
  3. Create the server key ring database and add the certificates that you need to the server key ring database. For more information about server authentication, see Server authentication.
    • For server authentication, because every TLS session handshake includes server authentication, you must add a certificate for this server to the server key ring database. If a server certificate is self-signed, you must also export this certificate to the key ring databases of the clients that log in by using TLS. If a server certificate is signed by a certificate authority (CA), this CA certificate, instead of the server certificate, must be in the client key ring databases. For more information about server authentication, see Server authentication.
    • For client authentication, if you use client authentication and self-signed certificates, you must import the client certificates into the server key ring database. If a client certificate is signed by a certificate authority (CA), this CA certificate, instead of the client certificate, must be in the server key ring database. For more information, see Client authentication.
  4. You must configure the AT-TLS policies for DCAS. For more information about configuring AT-TLS, see Configuring the server system. To migrate the DCAS server from using IBM System SSL to using AT-TLS, see Migrating the DCAS server to use AT-TLS policies.
    Note the following requirements for policy configuration when DCAS TLSMECHANISM is set to ATTLS:
    • You must complete the following configuration for AT-TLS policies:
      • Code the TTLSEnvironmentAdvancedParms statement with the ApplicationControlled parameter ON in the policy configuration file. The ApplicatonControlled parameter enables DCAS to start TLS security on a connection.
      • Set the HandshakeRole parameter to ServerWithClientAuth on the TTLSEnvironmentAction statement in the policy configuration file.
      • Code the same level of client authentication, the CLIENTAUTH parameter, in the DCAS configuration file and AT-TLS policies, the ClientAuthType parameter.
      • The TTLSRule statement with the LocalPortRange parameter and the LocalAddr parameter must include the DCAS configured values for PORT and IPADDR.
    • Configure TTLSCipherParms statement in the policy configuration file to use ciphers.
    • See Digital Certificate access server (DCAS) configuration file keywords and parameters in z/OS Communications Server: IP Configuration Reference for detailed information.
    Table 1. Required AT-TLS policies when DCAS TLSMECHANISM is set to ATTLS
    DCAS Configuration Value AT-TLS Policy value (policy configuration file)
      Direction Inbound
      TTLSEnabled On
      ApplicationControlled ON
      HandshakeRole ServerWithClientAuth
    CLIENTAUTH LOCAL2 (default) ClientAuthType SAFCHECK
    CLIENTAUTH LOCAL1 ClientAuthType Required (default)
    PORT <portValue> LocalPortRange <include portValue>
    IPADDR <inaddrValue> LocalAddr <inlcude inaddrValue>
    The following Policy Agent AT-TLS configuration sample shows the required policy configuration statements for AT-TLS:
    TTLSGroupAction secure_DCAS_group
    {
          TTLSEnabled On
    }
    
    TTLSEnvironmentAction secure_DCAS_env
    {
          TTLSKeyringParms
          {
                Keyring server-keyring-database  # Use Keyring or SAFKeyring
          }
    
          HandshakeRole ServerWithClientAuth
    
          TTLSEnvironmentAdvancedParms
          {
                ApplicationControlled On
                ClientAuthType SAFCHECK            # Used with CLIENTAUTH Local2
          }
    
          TTLSCipherParmsRef DCAS_ciphers   # Used to customize ciphersuites for DCAS 
    }
    
    TTLSCipherParms DCAS_ciphers
    {
          # Sample ciphers. Should be customized!
          V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA
          V3CipherSuites TLS_RSA_WITH_3DES_EDE_CBC_SHA
          V3CipherSuites TLS_RSA_WITH_NULL_SHA
    }
    
    TTLSRule secure_DCAS_rule
    {
          LocalPortRange 8990     # This should be set to the port DCAS is
                                  # listening on (PORT keyword in DCAS configuration file)
          Direction Inbound
          TTLSGroupActionRef secure_DCAS_group
          TTLSEnvironmentActionRef secure_DCAS_env
    }
    Tip: You can enable more security settings with AT-TLS, such as LDAP servers and handshake timeout values. The configuration that is used in the sample is the minimum requirement to allow the DCAS server to use AT-TLS.
  5. Decide which cipher suites that the server should use to protect data transfers and control information. DCAS and AT-TLS support TLS through the System SSL cryptographic services, which is a base element of z/OS®. System SSL supports multiple cipher suites that provide encryption, data authentication, and data integrity.
    • Encryption algorithms scramble the data so that the data is transferred confidentially and cannot be interpreted without a special key.
    • Data authentication algorithms ensure that the data is originated from the expected sender.
    • Data integrity algorithms ensure that the data is not modified during transfer.
    Some of the supplied cipher suites provide only data authentication or data integrity but others also provide encryption. The cipher suite that is used for the session is determined by a negotiation between the server and client. For example, if you configure DCAS to use a list of three different cipher suites, the client chooses which of those three that the client can support based on its own configuration. The first matching suite in the list is chosen. If the client does not support any of the three suites, the negotiation fails and the secure connection is not established.

    Select which cipher algorithms to use by coding a TTLSCipherParms configuration statement to specify the cipher suites that the server can use. For the cipher suites that are supported on the TTLSCipherParms statement, see z/OS Communications Server: IP Configuration Reference. List the cipher suites in the order of preference and put the most preferred cipher suite first. The cipher suite is negotiated with the server on behalf of the client by using the same order of preference as the order that the TTLSCipherParms statement indicates.

    Guileline: The default cipher suites that System SSL uses include a null cipher, which has no encryption, authentication, or integrity. A TTLSCipherParms statement must be coded to remove the null cipher from the acceptable ciphers.
  6. Configure your security product for TLS. For more information, see TLS/SSL security.
End of change