- An important piece of valid encryption processes for data in motion is Transport Layer Security (TLS), a protocol meant to ensure there are mechanisms in place to protect and provide authentication, confidentiality and integrity of sensitive data during electronic communication. The Department of Health and Human Services (HHS) defers to NIST Special Publication 800-52 Revision 1, released in September 2013, for data in motion encryption best practices.
800-52 Revision 1 offers guidance to the selection and configuration of TLS protocol implementations while using Federal Information Processing Standards (FIPS) and NIST-recommended cryptographic algorithms. It also stipulates that TLS 1.1 configured with FIPS based cipher suites as the minimum appropriate secure transport protocol and recommends that agencies develop migration plans to TLS 1.2 by Jan. 1, 2015. Here are the similarities and differences, according to NIST, on the baseline requirements for TLS servers and TLS clients:
Minimum requirements for TLS servers
Protocol Version Support: TLS version 1.1 is required, at a minimum, in order to mitigate various attacks on version 1.0 of the TLS protocol. Support for TLS version 1.2 is strongly recommended. Servers that support government-only applications shall be configured to support TLS 1.1, and should be configured to support TLS 1.2. These servers will not support TLS 1.0 or any version of SSL. TLS versions 1.1 and 1.2 are represented by major and minor number tuples (3, 2) and (3, 3), respectively. Agencies must develop migration plans to support TLS 1.2 by January 1, 2015.
Server Keys and Certificates: The TLS server shall be configured with one or more public key certificates and the associated private keys. TLS server implementations should support multiple server certificates with their associated private keys to support algorithm and key size agility. There are six options for TLS server certificates that can satisfy the requirement for Approved cryptography: an RSA key encipherment certificate; an RSA signature.certificate; an ECDSA signature certificate; a DSA9 564 signature certificate; a Diffie- Hellman certificate; and an ECDH certificate.
At a minimum, TLS servers conforming to this specification shall be configured with an RSA key encipherment certificate, and also should be configured with an ECDSA signature certificate or RSA signature certificate. If the server is not configured with an RSA signature certificate, an ECDSA signature certificate using a Suite B named curve for the signature and public key in the ECDSA certificate should be used. TLS servers shall be configured with certificates issued by a CA, rather than self-signed certificates. Furthermore, TLS server certificates shall be issued by a CA that publishes revocation information in either a Certificate Revocation List (CRL) [RFC5280] or in Online Certificate Status Protocol (OCSP) [RFC6960] responses. The source for the revocation information shall be included in the CA-issued certificate in the appropriate extension to promote interoperability.
Server Certificate Profile: The server certificate profile, described in this section, provides requirements and recommendations for the format of the server certificate. For these guidelines, the TLS server certificate shall be an X.509 version 3 certificate; both the public key contained in the certificate and the signature shall have at least 112 bits of security. The certificate shall be signed with an algorithm consistent with the public key11 596:
- Certificates containing RSA (key encipherment or signature), ECDSA, or DSA public keys shall be signed with those same signature algorithms, respectively;
- Certificates containing Diffie-Hellman public keys shall be signed with DSA; and
- Certificates containing ECDH public keys shall be signed with ECDSA.
Obtaining Revocation Status Information for the Client Certificate: The server shall perform revocation checking of the client certificate, when client authentication is used. Revocation information can be obtained by the server from one of the following locations:
1. Certificate Revocation List (CRL) or OCSP [RFC6960] response in the server’s local store;
2. OCSP response from a locally configured OCSP Responder;
3. OCSP response from the OCSP Responder location identified in the OCSP field in the Authority Information Access extension in the client certificate; or
4. CRL from the CRL Distribution Point extension in the client certificate.
Server Public Key Certificate Assurance: After the server public key certificate has been verified by a client, it may be trusted by the client on the basis of policies, procedures and security controls used to issue the server public key certificate. The server is required to possess an X.509 version 3 public key certificate. The policy, procedures and security controls are optionally represented in the certificate using the certificate Policies extension, specified in [RFC5280] and updated in [RFC6818]. When used, one or more certificate policy OIDs are asserted in this extension. The actual policies and procedures and security controls associated with each certificate policy OID are documented in a certificate policy.
Minimum requirements for TLS clients
Protocol Version Support: The client shall be configured to support TLS 1.1, and should be configured to support TLS 1.2. The client may be configured to support TLS 1.0 to facilitate communication with private sector servers, where necessary. If TLS 1.0 is supported, the use of TLS 1.1 1324 and 1.2 shall be preferred over TLS 1.0. The client shall not support SSL version 3.0 or 1325 earlier. Agencies shall develop migration plans to support TLS 1.2 by January 1, 2015.
Client Keys and Certificates – Client Certificate Profile: When client authentication is needed, the client shall be configured with a certificate that adheres to the recommendations presented in this section. A client certificate may be configured on the system, or located on an external device (e.g., a PIV card). For this specification, the TLS client certificate shall be an X.509 version 3 certificate; both the public key contained in the certificate and the signature shall have at least 112 bits of security. The certificate shall be signed with an algorithm consistent with the public key:
- Certificates containing RSA (signature), ECDSA, or DSA public keys shall be signed with those same signature algorithms, respectively;
- Certificates containing Diffie-Hellman certificates shall be signed with DSA; and
- Certificates containing ECDH public keys shall be signed with ECDSA.
Obtaining Revocation Status Information for the Server Certificate: The client shall perform revocation checking of the server certificate. Revocation information can be obtained by the client from one of the following locations:
1. Certificate Revocation List (CRL) or OCSP [RFC6960] response in the client’s local certificate store;
2. OCSP response from a locally configured OCSP responder;
3. OCSP response from the OCSP responder location identified in the OCSP field in the Authority Information Access extension in the server certificate; or
4. CRL from the CRL Distribution Point extension in the server certificate.
Client Public Key Certificate Assurance: The client public key certificate may be trusted by the servers on the basis of the policies, procedures and security controls used to issue the client public key certificate as described in Section 3.5.1. For example, as the implementation of Personal Identify Verification (PIV) [FIPS201-1] becomes more established in Federal Agencies, these guidelines recommend that the PIV Authentication certificate be the norm for authentication of Federal employees and long-term contractors. For users who do not have PIV Cards, such as external users, the set of certificate policies to accept should be determined as specified in Appendix B of [SP800-63], based on the level of assurance required by the application. PIV Authentication certificate policy is defined in [COMMON] and PIV-I Authentication certificate policy is defined in [FBCACP].