Plan Your Implementation of the TLS Protocol
Before you configure Connect:Direct® Secure Plus, review the following concepts, requirements, and terms to ensure that you have all the resources and information necessary to implement the Transport Layer Security (TLS) protocol.
Overview of the TLS Protocol
The TLS protocol provides three type of authentication:
- During the first type of authentication, called server authentication, the site initiating the session (PNODE) requests a certificate from its trading partner (SNODE) during the initial handshake. The SNODE returns its ID certificate (read from its KeyStore) and the PNODE authenticates it using one or more trusted root certificates stored in its KeyStore. Root certificates are signed by a trusted source—either a public certificate authority, such as Thawte, or by the trading partner acting as its own CA. If the ID certificate from the SNODE cannot be validated using any root certificate found in the KeyStore, or if the root certificate has expired, the PNODE terminates the session. IBM Connect:Direct writes entries to the statistics logs of both nodes and the session is aborted.
- The second type of authentication, called client authentication, is optional. If this option is enabled in the SNODE's IBM Connect:Direct parameters file definition for the PNODE, the SNODE will request a certificate from the PNODE and authenticate it using the information in its KeyStore. If this authentication fails, the SNODE terminates the session and IBM Connect:Direct writes information about the failure to the statistics log of both nodes.
- The third type of authentication is also optional and consists of validating the certificate
common name. This authentication is enabled when the security administrator specifies the common
name (CN) expected to be contained in the ID certificate to be validated in its IBM Connect:Direct
Parameters file.
- During the first type of authentication, the PNODE compares the common name it has specified for the SNODE in its IBM Connect:Direct Parameters file with the common name contained in the certificate sent by the SNODE. If the compare fails, that is, the information is not identical, the PNODE terminates the session, and IBM Connect:Direct writes information about the failure to the statistics logs of both nodes.
- During the second type of authentication, the SNODE compares the common name it has specified for the PNODE in its IBM Connect:Direct Parameters file with the common name contained in the certificate sent by the PNODE. If the compare fails, that is, the information is not identical, the SNODE terminates the session, and IBM Connect:Direct writes information about the failure to the statistics logs of both nodes.
Protocol Support
Before you configure Connect:Direct Secure Plus, you must determine the protocol that you and your trading partners will use to secure communications sessions. For planning information, see Plan Your Implementation of the SSL or TLS Protocol.
Transport Layer Security Protocol (TLS)
The TLS protocol use certificates to exchange a session key between the node that initiates the data transfer process (the primary node, or PNODE) and the other node that is part of the communications session (the secondary node, or SNODE). A certificate is an electronic document that associates a public key with an individual or other entity. It enables you to verify the claim that a given public key belongs to a given entity. Certificates can be self-issued (self-signed) or issued by a certificate authority (CA). See Self-Signed and CA-Signed Certificates for details on the differences between self-signed and CA-issued certificates.
When a CA receives an application for a certificate, the CA validates the applicant's identity, creates a certificate, and then digitally signs the certificate, thus vouching for an entity's identity. A CA issues and revokes CA-issued certificates.
Self-signed certificates are created and issued by the owner of the certificate, who must export the certificate in order to create a trusted root file that includes this certificate and supply the trusted root file to the partner in a connection.
TLS 1.3
Deprecated Protocols
The support of deprecated protocols like TLS1.0, TLS1.1, and SSL3.0 has been removed and these protocols can no longer be configured. In case TLS1.0 or TLS 1.1 was configured before an upgrade to IBM Sterling Connect:Direct for UNIX 6.3, these will still be honored and will be preserved until removed explicitly. Once removed, they cannot be reconfigured.
In the case of SSL3.0, the support has been completely removed. Even if SSL3.0 was configured before an upgrade to Connect:Direct for UNIX 6.3, it will not be used after the upgrade. If any other supported protocol is configured, it will be used in such a case, otherwise, TLS1.2 will be used in the background.
NIST SP800-131a and Suite B support
Connect:Direct supports a new standard from The National Institute of Standards and Technology (NIST), SP800-131a to extend the current FIPS standards, as well as Suite B cryptographic algorithms as specified by the National Institute of Standards and Technology (NIST).
The government of the Unites States of America produces technical advice on IT systems and security, including data encryption and has issued Special Publication SP800-131a that requires agencies from the Unites States of America to transition the currently-in-use cryptographic algorithms and key lengths to new, higher levels to strengthen security.
Applications must use strengthened security by defining specific algorithms that can be used and what their minimum strengths are. These standards specifies the cryptographic algorithms and key lengths that are required in order to remain compliant with NIST security standards.
- Enable TLS 1.2 and be prepared to disable protocols less than TLS 1.2
- Cryptographic keys adhere to a minimum key strength of 112 bits
- Digital signatures are a minimum of SHA-2
The following is included in Secure Plus for NIST SP800-131a and Suite B support:
- Support TLS 1.1 and 1.2 with SHA-2 cipher suites
- Support for SP800-131a transition and strict modes
- Support for NSA Suite B 128 and 192 bit cipher suites and modes
- Support for migration of IBM CMS Keystore to PKCS12 Keystore via a Connect:Direct for UNIX upgrade.
- Support for migrating existing Secure+ certificates to the PKCS12 Keystore.
For more information on NIST security standards, see http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf.
For more information on Suite B security standards, see http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
Self-Signed and CA-Signed Certificates
Determining the type of certificate to use for secure communications sessions and the method to generate the certificate is challenging. Self-signed certificates and digital certificates issued by certificate authorities offer advantages and disadvantages. You may also be required to use both types of certificates, depending on the security requirements of your trading partners. The following table compares the advantages and disadvantages of self-signed and CA-signed certificates:
| Type of Certificate | Advantages | Disadvantages |
|---|---|---|
| Self-signed certificate | No cost | Requires you to distribute your certificate, minus the private key, to each trading partner in a secure manner |
| Easy to generate | Difficult to maintain; anytime the certificate is changed, it must be distributed to all clients | |
| Self-validated | Not validated by a third-party entity | |
| Efficient for small number of trading partners | Inefficient for large number of trading partners | |
| CA-signed certificate | Eliminates having to send your certificate to each trading partner | Trading partners must download digital CA-signed certificate used to verify the digital signature of trading partner public keys. |
| No changes are required on the trading partner's system if you recreate the CA digitally-signed certificate using the same CA | Must be purchased from third-party vendor |
Certificate Terminology
The following defines the security terms associated with TLS certificates and communication sessions. The terms are listed in alphabetical order.
- CA-signed certificate
Digital document issued by a certificate authority that binds a public key to the identity of the certificate owner, thereby enabling the certificate owner to be authenticated. An identity certificate issued by a CA is digitally signed with the private key of the certificate authority.
- Certificate (also known as digital certificate, public key certificate, digital ID, or identity certificate)
Signed certificate that is obtained from a certificate authority by generating a certificate signing request (CSR). It typically contains: (1) distinguished name and public key of the server or client; (2) common name and digital signature of the certificate authority; (3) period of validity (certificates expire and must be renewed); and (4) administrative and extended information. The certificate authority analyzes the CSR fields, validates the accuracy of the fields, generates a certificate, and sends it to the requester.
A certificate can also be self-signed and generated by any one of many tools available, such as OpenSSL. These tools can generate a digital certificate file and a private key file in PEM format, which you can combine using any ASCII text editor to create a key certificate file.
- Certificate authority (CA)
An organization that issues digitally-signed certificates. The certificate authority authenticates the certificate owner's identity and the services that the owner is authorized to use, issues new certificates, renews existing certificates, and revokes certificates belonging to users who are no longer authorized to use them. The CA digital signature is assurance that anybody who trusts the CA can also trust that the certificate it signs is an accurate representation of the certificate owner.
- Certificate signing request (CSR)
Message sent from an applicant to a CA in order to apply for a digital identity certificate. Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains information identifying the applicant (such as a directory name in the case of an X.509 certificate), and the public key chosen by the applicant. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority, and the certificate authority may contact the applicant for further information.
- Cipher suite
A cryptographic key exchange algorithm that enables you to encrypt and decrypt files and messages with the TLS protocol.
- Client authentication
A level of authentication that requires the client to authenticate its identity to the server by sending its certificate.
- Key certificate file
File that contains the encrypted private key and the ID (public key) certificate. This file also contains the certificate common name that can be used to provide additional client authentication.
- Passphrase
Passphrase used to access the private key.
- Private key
String of characters used as the private, “secret” part of a complementary public-private key pair. The symmetric cipher of the private key is used to sign outgoing messages and decrypt data that is encrypted with its complementary public key. Data that is encrypted with a public key can only be decrypted using its complementary private key.
The private key is never transmitted and should never be shared with a trading partner.
- Public key
String of characters used as the publicly distributed part of a complementary public-private key pair. The asymmetric cipher of the public key is used to confirm signatures on incoming messages and encrypt data for the session key that is exchanged between server and client during negotiation for a TLS session. The public key is part of the ID (public key) certificate. This information is stored in the key certificate file and read when authentication is performed.
- Self-signed certificate
Digital document that is self-issued, that is, it is generated, digitally signed, and authenticated by its owner. Its authenticity is not validated by the digital signature and trusted key of a third-party certificate authority. To use self-signed certificates, you must exchange certificates with all your trading partners.
- Session key
Asymmetric cipher used by the client and server to encrypt data. It is generated by the SSL software.
- Trusted root certificate file (also known as root certificate file
File that contains one or more trusted root certificates used to authenticate ID (public) certificates sent by trading partners during the IBM Connect:Direct protocol handshake.