10. TLS
10.1. TLS Overview
Transport Layer Security (TLS) is used for two primary purposes:
- authentication of an end device (client or server) using a digital signature (DS)TLS uses PKI for device authentication. DSs are used to authenticate the client or the server. The server typically sends a certificate with a DS to the client.In certain situations, the server can request a certificate from the client to authenticate it. The client has a certificate (called a Trust Anchor) from the certificate authority (CA) which is used to authenticate server certificate and its DS. After the client provides a digitally signed certificate to the server and both parties are authenticated, the encryption PDUs can then be transmitted.When SR OS is acting as a server and it requests a certificate from the client, the client must provide the certificate. If the client fails to provide a certificate for authentication, SR OS will terminate the TLS session. The server TLS settings can be configured to not request certificates, in which case the client is not obligated to send the server a certificate for authentication.
- encryption and authentication of application PDUsAfter the clients and server have been successfully authenticated, the cipher suite is negotiated between the server and clients, and the PDUs will be encrypted based on the agreed cipher protocol.
10.2. TLS Server Interaction with Applications
TLS is a standalone configuration. The user must configure TLS server profiles with certificates and trust anchors, and then assign the TLS server profiles to the appropriate applications. When a TLS server profile is assigned to an application, the application should not send any clear text PDUs until the TLS handshake has been successfully completed and the encryption ciphers have been negotiated between the TLS server and the TLS client.
After successful negotiation and handshake, the TLS will be operationally up, and the TLS will notify the application which will begin transmitting PDUs. These PDUs will be encrypted using TLS based on the agreed ciphers. If, at any point, the TLS becomes operationally down, the application should stop transmitting PDUs.
For example, a TLS connection with the gMI application would operate as follows:
- A TLS server profile is assigned to the gMI application.
- gMI stops sending clear text PDUs because a TLS server profile has been assigned and TLS is not ready to encrypt.
- The TLS server begins the handshake.
- Authentication occurs at the TLS layer.
- The TLS server and TLS client negotiate ciphers.
- SALTs are negotiated for the symmetric key. A SALT is a seed for creating AES encryption keys.
- When negotiations are successfully completed, the handshake finishes and gMI is notified.
- TLS becomes operationally up, and gMI can resume transmitting PDUs. Until TLS becomes operationally up, gMI PDUs arriving from the client are dropped on ingress.
10.2.1. TLS Application Support
Table 45 lists the applications that support TLS.
Table 45: TLS Application Support
Application | TLS Server Supported | TLS Client Supported |
LDAP | ✓ | |
gRPC | ✓ |
10.3. TLS Handshake
Figure 34 shows the TLS handshake.
Figure 34: TLS Handshake
Table 46 describes the steps in the TLS handshake.
Table 46: TLS Handshake Step Descriptions
Step | Description |
1 | The TLS handshake begins with the client Hello message. This message includes the cipher list that the client wishes to use and negotiate, among other information. |
2 | The TLS server sends back a server Hello message, along with the first common cipher found on both the client cipher list and the server cipher list. This agreed cipher will be used for data encryption. |
3 | The TLS server continues by sending a server certificate message, where the server provides a certificate to the client so that the client can authenticate the server identity. The public key of this certificate (RSA key) can also be used for encryption of the symmetric key seed that will be used by the client and server to create the symmetric encryption key. This occurs only if the PKI is using RSA for asymmetric encryption. |
4 | Server key exchange is not supported by SR OS. SR OS only uses RSA keys; Diffie-Hellman key exchange is not supported. |
5 | The server can optionally be configured to request a certificate from the client to authenticate the client. |
6 | If the server has requested a certificate, the client should provide a certificate using a client certificate message. If the client does not provide a certificate, the server will drop the TLS session. |
7 | The client uses the server public RSA key that was included in the server certificate to encrypt a seed used for creating the symmetric key. This seed is used by the client and server to create the identical symmetric key for encrypting and decrypting the data plane traffic. |
8 | The client sends a cipher spec to switch encryption to this symmetric key. |
9 | The client successfully finishes the handshake. |
10 | The server sends a cipher spec to switch encryption to this symmetric key. |
11 | The server successfully finishes the handshake. |
After a successful handshake, TLS will be operationally up, and applications can then use it for application encryption.
10.4. TLS Client Certificate
TLS protocol is used for authentication, and as such, the server can ask to authenticate the client via PKI. If the server requests authentication from the client, the client must provide an X.509v3 certificate to the server so that it can be authenticated via the digital signature of its client. SR OS allows the configuration of an X.509v3 certificate for TLS clients. When the server requests a certificate via the server’s Hello message, the client will transmit its certificate to the server using a client certificate message.
10.5. TLS Symmetric Key Rollover
SR OS supports key rollover via HelloRequest messages as detailed in RFC 5246, section 7.4.1.1. Some applications have a longer live time than other applications, in which case SR OS can use a timer that prompts the HelloRequest negotiation for the symmetric key rollover. This timer is configurable using CLI.
If an application does not support the HelloRequest message, the no tls-re-negotiate-timer command should be configured under the config>system>security>tls context. For example, the gRPC application does not support HelloRequest messages.
When no tls-re-negotiate-timer is configured, the HelloRequest message is not generated, and symmetric keys are not renegotiated.
10.6. Supported TLS Ciphers
As shown in Figure 34, TLS negotiates the supported ciphers between the client and the server.
The client sends the supported cipher suites in the client Hello message and the server compares them with the server cipher list. The top protocol on both lists is chosen and returned from the server within the server Hello message.
The 7750 SR supports the following ciphers as a TLS client or TLS server:
- tls-rsa-with-null-md5
- tls-rsa-with-null-sha
- tls-rsa-with-null-sha256
- tls-rsa-with3des-ede-cbc-sha
- tls-rsa-with-aes128-cbc-sha
- tls-rsa-with-aes256-cbc-sha
- tls-rsa-with-aes128-cbc-sha256
- tls-rsa-with-aes256-cbc-sha256
10.7. SR OS Certificate Management
SR OS implements a centralized certificate management protocol that can be used by TLS and IPsec. Refer to the 7450 ESS, 7750 SR, and VSR Multiservice Integrated Service Adapter and Extended Services Appliance Guide for information about the configuration of the certificates and the corresponding protocols, such as OCSP, CMPv2, and CRL.
The main certificate configurations are:
- certificate configuration and management, configured using the admin>certificate commands
- PKI configuration (including creating a CA profile), configured using the config>system>security>pki commands
The two main configuration sub-trees for certificates are displayed below.
10.7.1. Certificate Profile
The certificate profile is available for both the TLS server and the TLS client. The cert-profile command is configured for the server or client to transmit the provider certificate and its DS to the peer so that the peer can authenticate it via the trust-anchor and CA certificate.
Multiple provider certificates can be configured on SR OS; however, SR OS currently uses the smallest index as the active provider certificate, and will only send the certificate to the peer.
10.7.2. TLS Server Authentication of the Client Certificate CN Field
If the client provides a certificate upon request by the server, SR OS checks the certificate’s common name (CN) field against local CN configurations. The CN is validated via the client IPv4/IPv6 address or FQDN.
If cn-authentication is not enabled, SR OS will not authenticate via the CN field and will only rely on certificate signature authentication.
10.7.3. CN Regexp Format
CN entries are configured by using the config>system>security>pki>common-name-list command. Entries should use regular expression (regexp), FQDN, or the IP address.
For information about regexp, refer to the Entering CLI Commands section in 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.
10.8. Operational Guidelines
10.8.1. Server Authentication Behavior
Following the Hello messages, the server sends its certificate in a certificate message if it is to be authenticated. If required, a ServerKeyExchange message may also be sent. Refer to RFC 5246, section 7.3, for more information about the authentication behavior on the LDAP server.
The trust-anchor-profile command determines whether or not the server must be authenticated by the client.
 | Note: If the trust-anchor-profile is configured and the ca-certificate or ca-profile is missing from this trust-anchor-profile, the TLS connection will fail and an “unknown_ca” error will be generated, as per RFC 5246 section 7.2.2. |
One of the following two configurations can be used to establish server connectivity.
- If trust-anchor-profile is configured under the TLS client-tls-profile context, the server must be authenticated via the trust-anchor-profile command before a trusted connection is established between the server and the client.
- If there is no trust-anchor-profile under the client-tls-profile context, the trusted connection can be established without server authentication. The RSA key of the certificate will be used for public key encryption, requiring basic certificate checks to validate the certificate. These basic checks are:
- time validity—the certificate is checked to ensure that it is neither expired nor not yet valid
- certificate type—the certificate is not a CA certificate
- keyUsage extension—if present, this must contain a digital signature and key encryption
- host verification—the IP address or DNS name of the server is looked up, if available (for LDAP, only the IP address is used), in the common name (cn) or subjectAltName extension. This is to verify that the certificate was issued to that server and not to another.
10.8.2. Client TLS Profile and Trust Anchor Behavior and Scale
SR OS allows the creation of client TLS profiles, which can be assigned to applications such as LDAP to encrypt the application layer.
The client-tls-profiles command is used for negotiating and authenticating the server. After the server is authenticated via the trust anchor profile (configured using the trust-anchor-profile command) of a client TLS profile, it negotiates the ciphers and authentication algorithms to be used for encryption of the data.
The client TLS profile must be assigned to an application for it to start encrypting. Up to 16 client TLS profiles can be configured. Because each of these client TLS profiles needs a trust anchor profile to authenticate the server, up to 16 trust anchor profiles can be configured. A trust anchor profile holds up to 8 trust anchors (configured using the trust-anchor command), which each hold a CA profile (ca-profile).
A CA profile is a container for installing CA certificates (ca-certificates). These CA certificates are used to authenticate the server certificate. When the client receives the server certificate, it reads through the trust anchor profile CA certificates and tries to authenticate the server certificate against each CA certificate. The first CA certificate that authenticates the server is used.
10.9. LDAP Redundancy and TLS
LDAP supports up to five redundant (backup) servers, as shown in Figure 35 and the configuration examples below. Depending on the timeout and retry configurations, if an LDAP server is determined to be out of service or operationally down, SR OS will switch to the redundant servers. SR OS will select the LDAP server with the next largest configured server index.
Figure 35: LDAP and TLS Redundancy
Configuration of Server-1:
Configuration of Server-5 (backup):
Each LDAP server can have its own TLS profile, each of which can have its own configuration of trust-anchor and cipher-list. For security reasons, the LDAP servers may be in different geographical areas and, as such, each will be assigned its own server certificate and trust anchor. The design is open to allow the user to mix and match all components.