Conversation security is part of SNA communications and prevents a physical connection if the security check fails. TCP/IP communications has no security checking. It is up to the server to determine if it will accept or reject a connection from a client. The physical connection must initially be accepted and security information must be transmitted and checked. If the security check fails, the server must close the connection.
If DRDA protocol is being used, the ACCSEC and SECCHK DDM data streams have been added to the DRDA architecture to handle this. They determine the security mechanism that will be used to validate the user and they provide the userid and password information. The security mechanism, userid and password are taken from the COMDIR entry.
If SQLDS protocol is being used, an explicit connect request is sent to the applcation server. The userid and password are taken from the COMDIR entry.
The risk with TCP/IP communications is that it allows an unencrypted password to be transmitted over the network. Two options exist to avoid this problem. The first is to allow a user be be already verified. The second is to use an external security manager that will provide an encrypted password that can be safely transmitted on the network.
If a user is already verified, only a user id must be transmitted. The target application server must be configured to accept already verified users. DB2 Server for VM provides the SECALVER initialization parameter. If SECALVER=Y, the DB2 Server for VM applications server will accept a TCP/IP connected user and only validate the userid. If SECALVER=N and a connection request comes in with only a userid, the connection will be rejected with a missing password error.
A DB2 Server for VM application requester would configure the security tag in the COMDIR to SAME and only specify a userid tag. The password tag would be omitted. If a password is included, it is used and verified even if security SAME was specified.
If the application requester can generate an encrypted password, the target application server must be able to verify it. DB2 for OS/390 can use RACF PassTickets for this purpose. If a DB2 for OS/390 application requester want to connect to a DB2 Server for VM application server using TCP/IP and is using PassTickets, the DB2 Server for VM application server must be able to verify the userid and the PassTicket. The DB2 Server for VM initialization parameter, SECTYPE=ESM, is used for this purpose. Specifying this parameter will establish a connection to an external security manager. This external security manager must support the RACROUTE interface. RACROUTE and PassTickets are supported by RACF V1R10 for VM (5740-XXH) or later. The DB2 Server for VM application server would pass the userid and PassTicket to the ESM to be verified. The ESM could also be used to verifiy users and unencrypted passwords, but its real value is in the use of PassTickets.
The default value for SECTYPE is DB2. If this is used, then userid and password verification is done by checking the values in the SYSUSERAUTH catalog table.
The SECALVER and SECTYPE parameters are only used if the incoming connect request is via TCP/IP from any type of requester or if the incoming connect request is from a DB2 Server for VSE DRDA application requester via SNA. DB2 Server for VSE does not support any connections via TCP/IP.
If only a userid is sent on the connect request, the DB2 Server for VM application server checks the value of the SECALVER parameter. If the value is N, the connection is rejected. SECALVER = N means the user is not already verified. A userid and password are required for verification. If the value is Y and only a userid is sent, the connection is accepted. SECALVER = Y means the user is already verified. Only a userid is required for verification. In this case the userid is verified based on the SECTYPE value. If SECTYPE = DB2, the SYSTEM.SYSUSERAUTH table is checked if the user has connect authority. The password column is not checked. If SECTYPE = ESM, the userid is passed to the ESM via RACROUTE. The password is not checked.
If a userid and password are sent on the connect request, the DB2 Server for VM server ignores the value of SECALVER and only checks the value of SECTYPE. The userid and password are both required for verification. The verification is based on the SECTYPE value. If SECTYPE = DB2, the SYSTEM.SYSUSERAUTH table is checked if the user with that password has connect authority. If SECTYPE = ESM, the userid and password is passed to the ESM via RACROUTE. The userid and password are both checked. In this case the password can be a PassTicket. The way the ESM was set up determines if it is expecting a password or PassTicket from this userid.
If SECTYPE = ESM is specified, a check is performed during initialization to ensure that the external security manager is available and that it supports the RACROUTE interface. On VM, the command RPIUCMS INIT is issued. The expected response is RPICMS016I USER/RACF VM communication path established. If this response is not received, an error message, ARI4108E Unable to initialize the external security manager is returned. The value of SECTYPE is switched to DB2 and processing continues.
The application requester must provide a userid and password to successfully connect to an application server. On VM, applications can specify the userid and password in the following ways:
In private flows, all methods may be used. In DRDA flows, only the last two methods can be used. In DRDA flows over TCP/IP, only method 2 is used.
In the VM application requester if the connection to be established is DRDA
via TCP/IP, security handshaking datastreams are sent. If the
connection is to be established via SNA or private flow via TCP/IP, no
security handshaking datastreams are sent. This is determined by the
values in the COMDIR and the value of the PROTOCOL parameter of
SQLINIT.
Table 36. DRDA Connections via TCP/IP
| SQLINIT PROTOCOL | Connection Protocol | Security Handshaking Done? |
|---|---|---|
| SQLDS | SNA | No |
| SQLDS | TCP/IP | No |
| AUTO | SNA | No |
| AUTO | TCP/IP | Yes |
| DRDA | SNA | No |
| DRDA | TCP/IP | Yes |
SECTYPE = ESM allows the user to use an external security manager to authenticate TCP/IP connections to the database manager. If the external security manager supports PassTickets, they can be used instead of a password to avoid having an unencrypted password sent on a TCP/IP network.
If SECTYPE = ESM is going to be used, two major set up steps of the external security manager must be completed.
If SECTYPE = ESM is going to be used, the external security manager must be set up to allow the application server to access it. Refer to the External Security Interface (RACROUTE) Macro Reference for MVS and VM manual for details. See the section titled "Authorization to Issue RACROUTE Requests".
The instructions given here only describe the minimum steps required. Refer to the above manual for any detailed instructions.
IUCV RACFVM PRIORITY MSGLIMIT 255
RDEFINE FACILITY ICHCONN UACC(NONE)
PERMIT ICHCONN CLASS(FACILITY) ID(userid | groupid)
ACCESS(appropriate-access)
Appropriate-access should be UPDATE or higher. To execute the RACROUTE REQUEST=VERIFY command on VM, the caller must have at least UPDATE authority to the ICHCONN profile in the FACILITY class.
SETROPTS CLASSACT(FACILITY)
The RPIUCMS module referred to in the procedures is available in the RACF product, not the VM operating system. If you install another external security product on VM, that external security product should provide an equivalent RPIUCMS function as described in Appendix C, "RACROUTE Interface to an External-Security-Manager Product (Non-RACF) on VM." in the External Security Interface (RACROUTE) Macro Reference for MVS and VM manual.
If PassTickets will be used instead of passwords, a Secured Signon application profile must be defined for the application in the PTKTDATA class. In addition, RACF must be at Version 1 Release 10 or later.
The user must generate a PassTicket before issuing the SQL CONNECT statement. The PassTicket is then used in the SQL CONNECT statement instead of the password. See the RACF Macros and Interfaces manual for details on how a PassTicket is generated.
If SECTYPE = DB2 is to be used, the users must be defined in the SYSTEM.SYSUSERAUTH catalog. This is done by a user with DBA authority using the SQL GRANT CONNECT command. See the DB2 Server for VSE & VM SQL Reference manual for details.