TLS

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 is successfully completed and the encryption ciphers are negotiated between the TLS server and the TLS client.

After successful negotiation and handshake, the TLS is operationally up and notifies the application, which begins transmitting PDUs. These PDUs are encrypted using TLS based on the agreed ciphers. At any point, if the TLS becomes operationally down, the application stops transmitting PDUs.

For example, the following sequence describes a TLS connection with the gRPC application:

1. A TLS server profile is assigned to the gRPC application.

2. The gRPC stops sending clear text PDUs because a TLS server profile has been assigned and TLS is not ready to encrypt.

3. The TLS server begins the handshake.

4. Authentication occurs at the TLS layer.

5. The TLS server and TLS client negotiate ciphers.

6. Salts are negotiated for the symmetric key. A salt is a seed for creating Advanced Encryptions Standard (AES) encryption keys.

7. When negotiations are successfully completed, the handshake finishes and the gRPC is notified.

8. TLS becomes operationally up, and the gRPC can resume transmitting PDUs. Until TLS is operationally up, gRPC PDUs arriving from the client are dropped on ingress.

The following figure shows the TLS handshake.

The following table describes the steps in the TLS handshake.

After a successful handshake, TLS is operationally up and applications can use TLS for application encryption.

TLS 1.3 is required for faster handshakes and stronger encryption and authentication algorithms.

All SR OS applications that use TLS 1.2 also support TLS 1.3, unless specifically stated otherwise.

The user can configure the node to use TLS 1.2, TLS 1.3, or both for its client or server negotiation.

When TLS 1.3 is negotiated with a client, the node no longer negotiates the TLS version down to 1.2 as long as the session is alive.

The TLS protocol is used for authentication. It allows the server to authenticate the client via PKI. If the server requests authentication from the client, the client response must provide an X.509v3 certificate that the server can authenticate using the digital signature of its client. The SR OS supports the configuration of an X.509v3 certificate for TLS clients. When the server requests a certificate using the Hello message, the client sends a client certificate message to transmit its certificate to the server.

A certificate authority (CA) can revoke issued certificates by listing them in a certificate revocation list (CRL). In TLS, an optional CRL is applied for CA certificates. The CRL does not apply to the intermediate or end issuer of an end entity (EE) certificate. To extend this optional configuration to include EE certificates, use the status-verify default-result commands under the following contexts:

configure system security tls client-tls-profile
configure system security tls server-tls-profile

The command options are revoked (default value) or good.

This default result is used when the revocation status of a certificate cannot be determined because of an invalid CRL (for example, it is missing, expired, or corrupt).

The TLS default-result for EE certificates is set to revoked for safety purposes. If an expired CRL in the CA profile is matched as the issuer of the EE certificate, the EE certificate is treated as revoked. If the expired CRL is further up in the certificate chain, the optional CRL works as expected.

The status-verify default-result commands allow users to override the recommended revocation check policy when there is legitimate reason to accept EE certificates without checking their revocation status (for example, to keep the automatic CRL update working during a temporary network issue).

The SR OS supports key rollover using HelloRequest messages, in accordance with RFC 5246, section 7.4.1.1. Some applications have a longer live time than other applications, in which case the SR OS can use a timer that prompts the HelloRequest negotiation for symmetric key rollover. This timer can be configured using CLI.

Use the following command to configure the TLS re-negotiate timer.

configure system security tls server-tls-profile tls-re-negotiate-timer

You can disable the timer configuration for applications that do not support HelloRequest messages (for example, the gRPC application).

When the tls-re-negotiate-timer command is configured, the HelloRequest message is not generated and symmetric keys are not renegotiated.

As shown in TLS handshake, 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.

SR OS supports the following TLS 1.2 ciphers as a TLS client or TLS server:

• 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

• tls-rsa-with-aes128-gcm-sha256

• tls-rsa-with-aes256-gcm-sha384

The SR OS supports the following TLS 1.3 ciphers, groups, and signature algorithms as a TLS client or TLS server:

• tls-aes128-gcm-sha256

• tls-aes256-gcm-sha384

• tls-chacha20-poly1305-sha256

• tls-aes128-ccm-sha256

• tls-aes128-ccm8-sha256

• Groups:

  • tls-ecdhe-256

  • tls-ecdhe-384

  • tls-ecdhe-521

  • tls-x25519

  • tls-x448

• Signature algorithms:

  • tls-rsa-pkcs1-sha256

  • tls-rsa-pkcs1-sha384

  • tls-rsa-pkcs1-sha512

  • tls-ecdsa-secp256r1-sha256

  • tls-ecdsa-secp384r1-sha384

  • tls-ecdsa-secp521r1-sha512

  • tls-rsa-pss-rsae-sha256

  • tls-rsa-pss-rsae-sha384

  • tls-rsa-pss-rsae-sha512

  • tls-rsa-pss-pss-sha256

  • tls-rsa-pss-pss-sha384

  • tls-rsa-pss-pss-sha512

  • tls-ed25519

  • tls-ed448

SR OS implements a centralized certificate management protocol that can be used by TLS and IPsec.

Use the commands in the following contexts to configure and manage certificates:

• MD-CLI

  admin system security pki
  configure system security pki

• classic CLI

  admin certificate
  configure system security pki

This section provides operational guidelines for TLS.

LDAP supports up to five redundant (backup) servers, as shown in the following figure and the configuration examples below. Depending on the timeout and retry configurations, if an LDAP server is determined as out of service or operationally down, the SR OS switches to the redundant servers. The SR OS selects the LDAP server with the next largest configured server index.

Each LDAP server can have its own TLS profile, can each profile can have its own configuration of trust-anchor and cipher-list. For security reasons, the LDAP servers may be in different geographical areas, so each server is assigned its own server certificate and trust anchor. The open design allows the user to mix and match all components.

The following example shows the configuration of LDAP Server-1 and Server-5 (backup).

[ex:/configure system security aaa remote-servers ldap]
A:admin@node-2# info
    public-key-authentication true
    server 1 {
        address 1.1.1.1 
        server-name "active-server"
        tls-profile "server-1-profile"{
        }
    }

[ex:/configure system security tls]
A:admin@node-2# info
    client-tls-profile "server-1-profile" {
        admin-state enable
        cipher-list "to-active-server"
        trust-anchor-profile "server-1-ca"
    }

[ex:/configure system security aaa remote-servers ldap]
A:admin@node-2# info
    public-key-authentication true
    server 5 {
        address 5.5.5.1 
        server-name "backup-server"
        tls-profile "server-5-profile"{
        }
    }

[ex:/configure system security tls]
A:admin@node-2# info
    client-tls-profile "server-5-profile" {
        admin-state enable
        cipher-list "to-backup-server-5"
        trust-anchor-profile "server-5-ca"
    } 

A:node-2>config>system>security>ldap# info
    public-key-authentication
    server 1 create
        address 1.1.1.1
        ldap-server ‟active-server”
        tls-profile ‟server-1-profile”

A:node-2>config>system>security>tls# info
    client-tls-profile ‟server-1-profile” create
        cipher-list ‟to-active-server”
        trust-anchor-profile ‟server-1-ca”
        no shutdown
    exit

A:node-2>config>system>security>ldap# info
    public-key-authentication
    server 5 create
        address 5.5.5.1
        ldap-server ‟backup-server-5”
        tls-profile ‟server-5-profile”

A:node-2>config>system>security>tls# info
    client-tls-profile ‟server-5-profile” create
        cipher-list ‟to-backup-server-5”
        trust-anchor-profile ‟server-5-ca”
        no shutdown
    exit

Basic TLS server configuration requires the following:

• Use the following command to create a cipher list.

  configure system security tls server-cipher-list

• Use the following command to assign the cipher list to the TLS server profile.

  configure system security tls server-tls-profile cipher-list

• Use the following command to create a certificate profile.

  configure system security tls cert-profile

• Use the following command to assign the certificate profile to the TLS server profile.

   configure system security tls server-tls-profile cert-profile

Basic TLS client configuration requires the following:

• Use the following command to create a cipher list.

  configure system security tls client-cipher-list

• Use the following command to assign a TLS client to the TLS client profile.

  configure system security tls client-tls-profile cipher-list

TLS imports the trust anchor certificate for (TLS) peer certificate authentication and public key retrieval.

The following example shows a TLS configuration.

[ex:/configure system security tls]
A:admin@node-2# info
    client-cipher-list "to-active-server" {
        tls12-cipher 1 {
            name tls-rsa-with-aes256-cbc-sha256
        }
        tls12-cipher 2 {
            name tls-rsa-with-aes128-cbc-sha256
        }
        tls12-cipher 3 {
            name tls-rsa-with-aes256-cbc-sha
        }
    }
    client-tls-profile "server-1-profile" {
        admin-state enable
        cipher-list "to-active-server"
        trust-anchor-profile "server-1-ca"
    }
    trust-anchor-profile "server-1-ca" {
        trust-anchor "tls-server-1-ca" { }
    }

A:node-2>config>system>security>tls# info
----------------------------------------------
        trust-anchor-profile "server-1-ca" create
            trust-anchor "tls-server-1-ca"
        exit
        client-cipher-list "to-active-server" create
            cipher 1 name tls-rsa-with-aes256-cbc-sha256
            cipher 2 name tls-rsa-with-aes128-cbc-sha256
            cipher 3 name tls-rsa-with-aes256-cbc-sha
        exit
        client-tls-profile "server-1-profile" create
            cipher-list "to-active-server"
            trust-anchor-profile ‟server-1-ca‟
            no shutdown
        exit
---------------------------------------------- 

This section provides information about common configuration tasks.