Security under the IBM Data Server Driver for JDBC and SQLJ

When you use the IBM® Data Server Driver for JDBC and SQLJ, you choose a security mechanism by specifying a value for the securityMechanism Connection or DataSource property, or the db2.jcc.securityMechanism global configuration property.

Important: The DATA_ENCRYPT authentication type is deprecated and might be removed in a future release. To encrypt data in-transit between clients and Db2 on Linux®, UNIX, and Windows systems databases, we recommend that you use the Db2 on Linux, UNIX, and Windows systems database system support of Secure Sockets Layer (SSL).

You can set the securityMechanism property in one of the following ways:

If you use the DriverManager interface, set securityMechanism in a java.util.Properties object before you invoke the form of the getConnection method that includes the java.util.Properties parameter.
If you use the DataSource interface, and you are creating and deploying your own DataSource objects, invoke the DataSource.setSecurityMechanism method after you create a DataSource object.

You can determine the security mechanism that is in effect for a connection by calling the DB2Connection.getDB2SecurityMechanism method.

The following table lists the security mechanisms that the IBM Data Server Driver for JDBC and SQLJ supports, and the data sources that support those security mechanisms.

Table 1. Data server support for IBM Data Server Driver for JDBC and SQLJ security mechanisms
Security mechanism	Supported by Db2 on Linux, UNIX, and Windows systems	Supported by Db2 for z/OS®	Supported by IBM Informix®	Supported by Db2 for IBM i
User ID and password	Yes	Yes	Yes	Yes
User ID only	Yes	Yes	Yes	Yes
User ID and encrypted password¹	Yes	Yes	Yes	Yes⁴
Encrypted user ID¹	Yes²	Yes	No	No
Encrypted user ID and encrypted password¹	Yes	Yes	Yes	Yes⁴
Encrypted user ID and encrypted security-sensitive data¹	No	Yes	No	No
Encrypted user ID, encrypted password, and encrypted security-sensitive data¹	Yes	Yes	No	No
Kerberos³	Yes	Yes	No	Yes
Plugin³	Yes	No	No	No
Certificate authentication³	No	Yes	No	No
Token authentication	Yes	No	No	No
Note: These security mechanisms use DRDA encryption. 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. For connections to Db2 on Linux, UNIX, and Windows systems, the encrypted user ID security mechanism is supported only for switching users on a trusted connection. Available for IBM Data Server Driver for JDBC and SQLJ type 4 connectivity only. The version of the data source must be Db2 for IBM i V6R1 or later.

The following table lists the security mechanisms that the IBM Data Server Driver for JDBC and SQLJ supports, and the value that you need to specify for the securityMechanism property to specify each security mechanism.

Important:

Starting with version 4.33 of the IBM Data Server Driver for JDBC and SQLJ:

The default security mechanism is ENCRYPTED_USER_AND_PASSWORD_SECURITY. If the data server does not support ENCRYPTED_USER_AND_PASSWORD_SECURITY, but supports CLEAR_TEXT_PASSWORD_SECURITY, the driver changes the security mechanism to CLEAR_TEXT_PASSWORD_SECURITY and attempts to connect to the data server.
When the driver retries the connection using CLEAR_TEXT_PASSWORD_SECURITY, performance might be degraded. To minimize the performance impact, take one of the following actions:
- Explicitly set the security mechanism to CLEAR_TEXT_PASSWORD_SECURITY on the client side.
- Change the data server setting to support ENCRYPTED_USER_AND_PASSWORD_SECURITY.
Any mismatch in security mechanism support between the requester and the data server other than CLEAR_TEXT_PASSWORD_SECURITY and ENCRYPTED_USER_AND_PASSWORD_SECURITY results in an error.
A connection to a Db2 for z/OS subsystem or data sharing group that uses the default security mechanism of ENCRYPTED_USER_AND_PASSWORD_SECURITY and AES encryption is successful only if the z/OS Integrated Cryptographic Service Facility (ICSF) is enabled on the z/OS system where each subsystem or data sharing member is installed. ICSF is required for decrypting the user ID and password. If ICSF is not installed, you need to set the security mechanism to CLEAR_TEXT_PASSWORD_SECURITY.

Before version 4.33 of the IBM Data Server Driver for JDBC and SQLJ, the default security mechanism is CLEAR_TEXT_PASSWORD_SECURITY. If the data server does not support CLEAR_TEXT_PASSWORD_SECURITY, but supports ENCRYPTED_USER_AND_PASSWORD_SECURITY, the driver changes the security mechanism to ENCRYPTED_USER_AND_PASSWORD_SECURITY and attempts to connect to the data server. Any other mismatch in security mechanism support between the requester and the data server results in an error.

Table 2. Security mechanisms supported by the IBM Data Server Driver for JDBC and SQLJ
Security mechanism	`securityMechanism` property value
User ID and password	`DB2BaseDataSource.CLEAR_TEXT_PASSWORD_SECURITY` (3)
User ID only	`DB2BaseDataSource.USER_ONLY_SECURITY` (4)
User ID and encrypted password¹	`DB2BaseDataSource.ENCRYPTED_PASSWORD_SECURITY` (7)
Encrypted user ID¹	`DB2BaseDataSource.ENCRYPTED_USER_ONLY_SECURITY` (16)
Encrypted user ID and encrypted password¹	`DB2BaseDataSource.ENCRYPTED_USER_AND_PASSWORD_SECURITY` (9)
Encrypted user ID and encrypted security-sensitive data¹	`DB2BaseDataSource.ENCRYPTED_USER_AND_DATA_SECURITY` (12)
Encrypted user ID, encrypted password, and encrypted security-sensitive data¹	`DB2BaseDataSource.ENCRYPTED_USER_PASSWORD_AND_DATA_SECURITY` (13)
Kerberos	`DB2BaseDataSource.KERBEROS_SECURITY` (11)
Plugin	`DB2BaseDataSource.PLUGIN_SECURITY` (15)
Certificate authentication	`DB2BaseDataSource.TLS_CLIENT_CERTIFICATE_SECURITY` (18)
Token authentication	`DB2BaseDataSource.TOKEN_SECURITY` (19)
Note: 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.