DB2 DDF security, TLS encryption, and two-phase commit

TLS on DDF is AT-TLS

Db2 supports SSL/TLS for DDF by using z/OS Communications Server Application Transparent Transport Layer Security (AT-TLS). The TCP/IP stack calls System SSL. Db2 still writes clear text to its socket; the stack encrypts on the wire. That is why DIST traces do not show TLS records, and why network administrators own PAGENT policy, not a Db2 ZPARM named “SSL=YES.”

Typical build-out (IBM Redpaper REDP-4799):

• Start PAGENT with AT-TLS policy.
• Define TTLSRule statements that match DDF’s secure port, a TTLSGroupAction with TTLSEnabled ON, and a TTLSEnvironmentAction.
• HandshakeRole Server — server authentication (the usual case). The client trusts the host certificate.
• HandshakeRole ServerWithClientAuth — client must present a certificate. ClientAuthType Required or SAFCheck maps the certificate to a RACF user.
• Point the policy at a RACF key ring owned by the DIST user. Each member’s UID has a ring of the same name.

Server authentication and client authentication often use two SECPORT values (two AT-TLS rules), because each rule has one HandshakeRole. JDBC clients set sslConnection=true and connect to the secure port, with sslTrustStoreLocation / sslCertLocation on the client and optionally securityMechanism=18 (TLS client certificate) plus a Java keystore.

Ports: PORT, SECPORT, RESPORT

DISPLAY DDF shows TCPPORT, SECPORT, and RESPORT. SECPORT=0 means no secure port is configured. Auditors often want TCPPORT disabled or equal to SECPORT so only TLS clients get in. Changing BSDS ports with DSNJU003 needs a DDF stop/start. Profile tables can reject non-secure authentication as a softer control.

Remote authorization and TCPALVER

After the TCP session exists, Db2 still has to know which RACF user owns the DBAT. The TCPALVER (TCP/IP already verified) subsystem parameter on installation panel DSNTIP5 decides how much proof is required.

IBM’s current security practice is SERVER_ENCRYPT. Installation CLIST APAR PH54096 warns when the value is not SERVER_ENCRYPT, because the old default NO allows passwords on a clear port. SERVER_ENCRYPT plus AT-TLS on SECPORT is the usual pair: the password never travels in the clear, and neither does the SQL.

Authentication methods

• User ID and password — RACF verifies the pair. Encrypt the session (TLS) or the password, depending on TCPALVER.
• RACF PassTicket — a short-lived, replay-protected substitute for a password. Useful for application servers that must not store a real password. SERVER_ENCRYPT accepts a PassTicket; it rejects a clear ordinary password (reason 00D30116 / DSNL030I when the “password” is not a PassTicket).
• Client certificate — not the same as “we turned on SSL.” Server authentication uses the host certificate. Client authentication sends the application’s certificate; SAFCheck maps it to a z/OS user that must be allowed to the DDF RACF resource (for example ssn.DIST).

Authorization after connect is ordinary Db2 privilege: the primary ID, secondary IDs, CURRENT SQLID, and roles. A common pattern is: grant table privileges to a role, not to the application user ID; create a trusted context that allows that role only when the connection uses a specific ID, encryption, and IP address or SERVAUTH zone. Then a stolen password from a laptop does not inherit the role.

Audit class 7 / IFCID 319 records how the client authenticated (password, PassTicket, certificate, clear text). Use it before you flip TCPALVER to SERVER_ENCRYPT so you can find clients that would break.

Distributed transactions and two-phase commit

A remote unit of work updates one server per COMMIT. A distributed unit of work can update more than one server in one COMMIT. When two resource managers must both commit or both roll back, Db2 uses two-phase commit:

1. Prepare (phase 1) — each participant writes enough log to promise it can commit, then votes yes, no, or read-only (forget).
2. Commit or rollback (phase 2) — the coordinator broadcasts the decision. Participants that voted yes become indoubt if they never hear phase 2.

Two common coordinators:

• DRDA two-phase commit — Db2 or another DRDA requester coordinates SQL across locations (CONNECT / three-part names with multi-site updates).
• XA / JTA — a Java transaction manager (WebSphere, other JTA containers) drives XAResource against IBM Data Server Driver type 4 connections. While the connection is in a global transaction, the application must not call Connection.commit, rollback, or setAutoCommit(true).

On z/OS, RRSAF uses Resource Recovery Services for local two-phase commit with CICS, IMS, or other RRS participants. That is not DDF, but the idea is the same: one coordinator, many resource managers, indoubt recovery.

Resynchronization

After a network or member failure, the requester must find the same member that owns the log for that unit of work. For TCP/IP, that is RESPORT — unique per data-sharing member in the sysplex. Register member domain names in DNS so the client can reconnect if the member restarts on another LPAR. SNA/VTAM keeps an LU affinity in the coupling facility for protected conversations until RESET GENERICLU.

Operators resolve leftover indoubt DBATs with -RECOVER INDOUBT when the coordinator will never return. XA indoubt XIDs also occupy SCA space in data sharing; resolve them rather than letting the list grow.

1
2
-DISPLAY THREAD(*) LOCATION(*) TYPE(INDOUBT)
-RECOVER INDOUBT ACTION(COMMIT) ID(luwid)

A practical secure DDF picture

1
2
3
4
5
6
7
8
* DISPLAY DDF — look for SECPORT not 0, unique RESPORT
-DISPLAY DDF
 
* JDBC client to the secure port
jdbc:db2://db2a.example.com:448/DB2A:sslConnection=true;
 
* ZPARM target
TCPALVER=SERVER_ENCRYPT

Combine AT-TLS on SECPORT, TCPALVER(SERVER_ENCRYPT), least-privilege owners, trusted contexts for application IDs, and a tested RECOVER INDOUBT procedure. Encryption without authentication still lets anyone who has an ID in. Authentication without TLS still leaves SQL on the wire.

Explain It Like I'm Five

DDF is the front door of the Db2 house. TLS is putting a locked, tinted tunnel in front of the door so neighbours cannot read the mail. AT-TLS is the building’s security guard (TCP/IP), not the Db2 butler, wrapping every letter. TCPALVER is whether the butler asks for a password, a special one-time ticket, or just believes the name on the hat. Two-phase commit is two kids promising to swap toys: first both say “I still have mine” (prepare), then both swap (commit). If the phone dies in between, they are indoubt and have to call back the same kid (RESPORT) to finish.

Exercises

1. Run DISPLAY DDF and list TCPPORT, SECPORT, and RESPORT. What would a JDBC URL look like for the secure port?
2. Look up TCPALVER on DSNTIP5 or DSN6FAC. If it is not SERVER_ENCRYPT, which clients would IFCID 319 show as clear-text passwords?
3. Explain the difference between “SSL is on” (server certificate) and client certificate authentication (SAFCheck).
4. Why must each data-sharing member have its own RESPORT for XA or DRDA 2PC?
5. Design a trusted context: application ID APP1, role PAYROLE, only from the app-server subnet, only on encrypted connections. What privileges go on the role versus APP1?