Configuring Personal Communications Session Security

Whether you are configuring a TN3270, TN5250, or VT session, the underlying protocol must be TCP/IP. Use the following procedure to enable security:

Start a workstation profile from the Session Manager; or, from an active session, click Configure from the Communication menu. When the dialog box opens, click Configure.
In the Customize Communication panel, choose the appropriate Type of Host, Interface, and Attachment values for the desired Telnet host.
Click Link Parameters.
On the Host Definition property page, do the following:
1. Enter the Host Name or IP Address.
2. Enter the LU or Pool Name.
3. Enter the Port Number.
4. To establish a secure connection on the port for a specific host, select the corresponding Enable Security checkbox.
5. Click OK to save the settings.
For 3270 sessions, select the Telnet-negotiated option to have Personal Communications negotiate security with the Telnet 3270 server. See Negotiated Telnet Security for details. If Enable Security is unchecked, the Telnet-negotiated option cannot be selected.
On the Security Setup property page, select the IBM Global Security Kit (GSKit) or Microsoft CryptoAPI (MSCAPI) security package.
Note:
To avoid the need of manually adding host certificate into the Microsoft Certificate Store, refer to Pass Through Certificate Validation.
For GSKit, you can click Advanced to control key ring access password options and Smart Card setup.
In the Key Ring Access group box, you can choose whether or not to use the key database password stash file. Select Use Password Stash (STH) File to use key database stash file and not be prompted for the key database file password. You can use this option with or without the Client Authentication function.

Select Cryptographic Support to enable Smart Card use. Click Setup to enter module and token information.
Use the Security Protocol drop-down list to choose TLS protocol for negotiation of the secure session. The supported TLS protocols are TLS 1.2, TLS 1.1, and TLS 1.0.
If the host does not support the selected TLS security protocol, Personal Communications will drop down to the next lower level of security protocol, and continue negotiations to establish a secure session. For example, if TLS1.2 is chosen from the Security Protocol drop-down box, and the host supports only up to TLS1.0, then the negotiation is carried out at TLS1.0.
To protect against security vulnerability in RC4 stream cipher, the FIPS (Federal Information Processing Standard) mode has been made mandatory.
For GSKit, the following FIPS-approved cipher suites are available:
- FIPS Allowed TLSV10 CipherSpecs:
  - TLS_RSA_WITH_AES_128_CBC_SHA
  - TLS_RSA_WITH_AES_256_CBC_SHA
  - TLS_RSA_WITH_3DES_EDE_CBC_SHA
- FIPS Allowed TLSV11 CipherSpecs:
  - TLS_RSA_WITH_AES_128_CBC_SHA
  - TLS_RSA_WITH_AES_256_CBC_SHA
  - TLS_RSA_WITH_3DES_EDE_CBC_SHA
- FIPS Allowed TLSV12 CipherSpecs:
  - TLS_RSA_WITH_AES_128_CBC_SHA
  - TLS_RSA_WITH_AES_256_CBC_SHA
  - TLS_RSA_WITH_3DES_EDE_CBC_SHA
  - TLS_RSA_WITH_AES_128_GCM_SHA256
  - TLS_RSA_WITH_AES_256_GCM_SHA384
  - TLS_RSA_WITH_AES_128_CBC_SHA256
  - TLS_RSA_WITH_AES_256_CBC_SHA256
  - TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
  - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  - TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
For more details, you are suggested contacting IBM Technical Support.

For MSCAPI, refer to the vedor documentation for the latest information.

MSCAPI and the version of GSKit both packaged with Personal Communications are FIPS-compliant.
Note:
Follow the below steps to enable AES support with MSCAPI on Windows® 8, Windows® 8.1, Windows® 10, Windows® Server 2008, and Windows® Server 2012.
1. From an administrator account, open Group Policy Editor (gpedit.msc).
2. Choose Computer Configuration->Administrative Templates->Network->SSL Configuration Settings.
3. Open SSL Cipher Suite Order and select Enabled.
4. Alter the cipher order as per you organization's needs, save the changes, and REBOOT the system for the above changes to apply.
It is important to note that the client can only present the server a prioritized cipher list. The host has the final say on what gets selected as the cipher for the session. When choosing an algorithm with a specific a bit length, one important consideration is to remember that encryption and decryption are CPU intensive operations which take time depending upon the key size. In almost all cases, a 128-bit key is more than sufficient to protect the information you are exchanging over your telnet connections.
Enable Check for Server Name and Certificate Name Match to have the session authenticate the server by matching the server name to the host or server certificate name. The server and certificate names must match exactly. For MSCAPI sessions, if the certificate name and server name do not match, an error is returned. For GSKit sessions, if the host certificate name does not match the name of the host to which are connecting, the session is terminated.
In the Client Authentication group box, you determine when and how the client certificate will be chosen for sending to the server.
If you want to enable client authentication and have the personal client certificate from the key database file sent to the server when requested, check Send Personal Certificate to Server if Requested.

Send Personal Certificate Trusted by Server

Select this option if you do not want to be prompted to select a personal client certificate from a key database file. Personal Communications will send the personal client certificate trusted by the server.

Send Personal Certificate based on Key Usage

Use this option to select one or more key usages. Click Key Usage to select the defined Object ID (OID) key usages. Go to the Extended Key Usage panel to add a new OID and description to the list.
At authentication time, Personal Communications chooses certificates for client authentication, based on the key usage that you select. If a certificate's Enhanced Key Usage attribute contains one or more of the OIDs that you specify, the certificate is eligible for use.

If no eligible certificates are found, the authentication fails. If one eligible certificate is found, it is automatically used. If two or more eligible certificates are found, you will be prompted to select a personal client certificate.

Select or Prompt for Personal Client Certificate

Use this option if you want to choose the personal client certificate. You will be prompted to select a personal client certificate during session establishment, when the server requests the client certificate.
To preselect a personal client certificate during configuration, click Select now and choose the Personal Certificate Label.

Pass Through Host Certificate Validation

Use this option to disable the default certificate validation process during TLS handshake. Applicable only for Microsoft schannel provider.
Note:
By default, schannel (MSCAPI) is responsible for validating the host certificate chain received during TLS handshake. Schannel runs several checks on the received certificate chain one of which is verifying that the signature affixed to the certificate valid, that is, the hash value computed on the certificate contents matches the value that results from decrypting the signature field using the public component of the issuer. In order to perform this operation, the user must possess the public component of the iss either through some integrity-assured channel, or by extracting it from another (validated) certificate. The default certificate valid process is exhaustive and runs several checks on the host certificate chain in order to successfully validate it. By enabling this option the user would effectively suppress the default validation done by schannel and the identity of the host is not verified. The use of this option is not recommended.