Security mechanisms for DRDA and SNA

DRDA encryption is not intended to provide confidentiality and integrity of passwords or data over a network that is not secure, such as the Internet. DRDA encryption uses an anonymous key exchange, Diffie-Hellman, which does not provide authentication of the server or the client. DRDA encryption is vulnerable to man-in-the-middle attacks.

Db2 for z/OS® and z/OS support a wide variety of cryptographic authentication schemes and protocols, such as the use of the z/OS Communications Server IP Application Transparent Transport Layer Security (AT-TLS), to provide an authenticated key agreement that helps prevent man-in-the-middle and related attacks. These methods mathematically bind the agreed-upon key to other agreed-upon data to secure data over a network that is not secure.

DRDA and SNA have different security mechanisms. DRDA allows a user to be authenticated by using SNA security mechanisms or DRDA mechanisms, which are independent of the underlying network protocol. 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.

DRDA encryption for LOBs or XML requires the entire data to be materialized in memory before encrypting or decrypting it. When you use DRDA encryption for LOBs or XML, ensure that each LOB or XML is not larger than 2GB-64 bytes, which is the Db2 pool limit. Consider using the Secure Socket Layer (SSL) protocol , instead of DRDA encryption, for large data.

For an SNA network connection, a DRDA requester can send security tokens by using a SNA attach or a DRDA command. Db2 for z/OS as a requester uses SNA security mechanisms if it uses a SNA network connection (except for Kerberos) and DRDA security mechanisms for TCP/IP network connections (or when Kerberos authentication is chosen, regardless of the network type).