Configuring SSL authentication levels

The Secure Socket Layer (SSL) protocol supports server and client authentication during the handshake phase. You can specify to use either server authentication, client authentication, or both depending on your security need.

To specify whether to use server authentication, client authentication, or both, use the following approaches:

• If you need only a minimum level of security to authenticate the communications between a server and its clients, consider using server authentication. To use server authentication, specify the HandshakeRole Server parameter for the TTLSEnvironmentAction statement in the AT-TLS policy, as shown in the following example:

  TTLSEnvironmentAction DB2ServerSecureEnvAct
  {
     TTLSKeyRingParms
     {
        Keyring DB2ServerKeyring
     }
     HandshakeRole Server
  }

  With this configuration, AT-TLS sends the server certificate to the client during the handshake phase of a connection request. The client then validates the server by examining the server certificate that it receives.
• If you need additional security, consider using client authentication. To use client authentication:
  1. Specify the HandshakeRole ServerWithClientAuth parameter for the TTLSEnvironmentAction statement in the AT-TLS policy, as shown in the following example:

     TTLSEnvironmentAction DB2ServerSecureEnvAct
     {
        TTLSKeyRingParms
        {
           Keyring DB2SERVERKEYRING
        }
        HandshakeRole ServerWithClientAuth
        TTLSEnvironmentAdvancedParms
        {
           ClientAuthType SAFCheck
        }
     }

  2. Determine the level of client authentication by specifying the ClientAuthType parameter for the TTLSEnvironmentAdvancedParms statement in the AT-TLS policy.

     Table 1. Client authentication levels

     Client Authentication Level	ClientAuthType	Client Certificate	SERVAUTH Class Active and Server SERVAUTH Profile Defined	Certificate Validation
     None	PassThru	Optional	N/A	None
     None	Full	Optional	N/A	Certificate is validated against key ring, if provided
     Level 1	Required (default)	Required	N/A	Certificate is validated against key ring
     Level 2	SAFCheck	Required	Optional	Certificate is validated against key ring and must be associated with a user ID in the security product
     Level 3	SAFCheck	Required	Required	Certificate is validated against key ring and must be associated to a user ID in the security product and must be permitted to access server's SERVAUTH profile

     Depending on the authentication type (ClientAuthType) you specify, AT-TLS may not require the client to present its certificate during the SSL handshake phase.
  3. The RACF security administrator can associate user IDs with the connection that was created with SSL authentication by taking one of the following actions:
     • Create a one-to-one association, as described in Enabling client login using certificates.
     • Create a certificate name filter, as described in Certificate name filtering.

     It is not necessary to store the certificates that represent the client in RACF, unless a one-to-one certificate to user ID association is used. However, certificates that represent the trusted certificate authority (CA) that signed the client certificates must be available to RACF. Specifically, the CA certificate must be connected to the RACF KEYRING associated to the Db2 server process via the Keyring specification of TTLSKeyRingParms of the TTLSEnvironmentAction statement in the AT/TLS policy.