Security mechanisms for Db2 for z/OS as a server

As a server, Db2 for z/OS can accept either SNA or DRDA authentication mechanisms. Make sure to use network security, such as client certificate authentication, SSL connections that use AT-TLS, or IPSec, to secure DRDA authentication mechanisms over a network that is not secure.

Db2 authenticates remote users from the security tokens that are obtained from the SNA ATTACH (FMH-5) or from the DRDA security commands that are described by each of the protocols. See Security mechanisms for DRDA and SNA for more information about using DRDA encryption.

If you use TCP/IP protocols, Db2 accepts connection requests from remote clients that use AES or DES encryption to protect user credentials. Specifically, Db2 supports the following authentication methods for connection requests over a TCP/IP network:

  • User ID only (already verified at the requester)
  • User ID and password
  • User ID and PassTicket
  • Kerberos tickets
  • Unencrypted user ID and encrypted password
  • Encrypted user ID and encrypted password
  • User ID, password, and new password
  • Start of changeFL 505 Authentication token only (with the activation of Db2 function level 505). A DRDA client must be operating at Security Manager Level 10 where the authentication token presented to Db2 is a Base64 encoded string and is acceptable to RACF® for validation.End of change

Db2 as a server also supports the following authentication mechanisms if the z/OS Integrated Cryptographic Service Facility is installed and active:

  • Encrypted user ID and encrypted security-sensitive data
  • Encrypted user ID, encrypted password, and encrypted security-sensitive data
  • Encrypted user ID, encrypted password, encrypted new password, and encrypted security-sensitive data

Security-sensitive data is any input or output data. Examples are rows that are retrieved from a remote server, rows that are sent to the remote server, and SQL statement text.