7. TLS
7.1. In This Chapter
This chapter provides information to configure Transport Layer Security (TLS).
Topics in this chapter include:
7.2. TLS Overview
The LDAP server can be used for managing public and private keys for SSH connections (see LDAP Authentication for more information). Unlike other AAA protocols, which have the encryption enabled within the protocol, LDAP uses Transport Layer Security (TLS) for encryption, and communication between the router and the LDAP server should be secured with LDAP over SSL/STL (LDAPS), as shown in Figure 18.
Figure 18: Public/Private Key Retrieval for SSH via LDAP
LDAP uses StartTLS (an LDAPv3 TLS extension for a secure connection) to signal to the server its interest in creating a secure TLS connection from the router to the LDAP server. After a TLS session is created, all application PDUs are encrypted via TLS between the client and the server.
TLS is a cryptographic protocol that provides communication security in an unsecure network. TLS uses X.509 certificates as its authentication mechanism for establishing a secure channel between two peers via Public Key Infrastructure (PKI). PKI can be used to negotiate the symmetric keys needed for TLS. When using X.509, a certificate authority (CA) is necessary to verify the relationship between the certificate and its owner.
TLS is a client-server application that encrypts the data of a connection in the application layer (unlike IPSec where the payload or the entire IP packet is usually encrypted, depending on the IPSec transport or tunnel mode).
Because protocols can operate either with or without TLS, the client must initiate the TLS handshake protocol to request a secure TLS channel between it and the server.
 | Note: TLS client functionality is currently only supported on LDAP. The SR-series routers support client functionality only. |
When a TLS client and server first start communicating, the client signals the need for a TLS session through a server-client handshake, and the client and server agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets. The handshake is described in the steps below (refer to RFC 5246, section 7.3, for more information).
| Note: If any one of the following steps fails, the TLS handshake fails, and the connection is not created. |
- A client connects to a TLS-enabled server, requesting a secure connection, and presents a list of supported cipher suites (ciphers and hash functions).
- From this list, the server picks a cipher and hash function that it also supports and notifies the client of its decision.
- The server usually sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted CA, and the server's public encryption key.Note that the SR OS TLS implementation only supports RSA public key. As such, the TLS server needs to send a certificate that contains a valid public RSA key.
- The client authenticates the server via the server certificate and an installed trust anchor certificate obtained from the same CA as the server. In the SR OS, the trust anchor certificate is not mandatory (see Server Authentication Behavior for more information).
- To generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt the number, using its private key.
- From the random number, both parties generate a master secret and then negotiate a session key for encryption and decryption.
This concludes the handshake and starts the secured connection, which is encrypted and decrypted with the key material until the connection closes.
Figure 19 displays the TLS handshake. Each TLS PDU corresponds to certain information, represented numerically; for example, “1. Client Hello” maps to the SR-series router client message of “1.Negotiate ciphers list, TLS version, etc…”.
Figure 19: TLS Handshake
If the handshake is successful, all of the application’s PDUs will be encrypted between the peers.
 | Caution: The TLS server can request a certificate from the client that is used to authenticate the client. The SR OS currently does not support client certificates. If the server sends a Certificate Request message (see message 5 Figure 19), SR OS will not provide this certificate. Therefore, the TLS server should be configured to not request a certificate from the client for client authentication. |
7.3. Supported TLS Ciphers
As shown in Figure 19, 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 via the server Hello message.
As a TLS client, the SR-series routers support the following ciphers:
- 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
7.4. SR OS Certificate Management
The SR OS has implemented a centralized certificate management protocol that can be used by TLS and IPSec. Refer to the Multiservice Integrated Service Adapter 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. See Public Key Infrastructure (PKI) Commands for more information.
7.5. Operational Guidelines
7.5.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.
7.5.2. Client TLS Profile and Trust Anchor Behavior and Scale
Currently, the SR OS only supports TLS client functionality, and only on the LDAP application. The 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.
7.6. LDAP Redundancy and TLS
LDAP supports up to five redundant (backup) servers, as shown in Figure 20 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, the SR OS will switch to the redundant servers. The SR OS will select the LDAP server with the next largest configured server index.
Figure 20: 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.