TLS

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 specific 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 terminates 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 PDUs

  After the clients and server have been successfully authenticated, the cipher suite is negotiated between the server and clients, and the PDUs are encrypted based on the agreed cipher protocol.

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 is operationally up, and the TLS notifies the application which begins transmitting PDUs. These PDUs are 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 gRPC application would operate as follows:

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

2. 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 AES encryption keys.

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

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

TLS handshake shows the TLS handshake.

TLS handshake step descriptions describes the steps in the TLS handshake.

After a successful handshake, TLS is operationally up, and applications can then use it 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.

TLS protocol is used for authentication, and therefore, 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 transmits its certificate to the server using a client certificate message.

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).

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.

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

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

If an application does not support the HelloRequest message, you can disable the timer configuration. For example, the gRPC application does not support HelloRequest messages. When the time is not 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.

The 7750 SR supports the following ciphers as a TLS 1.2 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 7750 SR 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

LDAP supports up to five redundant (backup) servers, as shown in LDAP and TLS redundancy 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 switches to the redundant servers. SR OS selects the LDAP server with the next largest configured server index.

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, therefore, each are assigned their own server certificate and trust anchor. The design is open to allow the user to mix and match all components.

[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
----------------------------------------------