Transport layer protocol (TLS)

TLS support

Transport Layer Security (TLS) is a cryptographic protocol for establishing encrypted communication between a client and server. NSP supports TLSv1.2 protocol by default. While not recommended, administrators can still enable TLSv.1.1 and/or TLSv1.0 in NFM-P on certain external interfaces, such as OSS clients. Upgrading legacy clients to support TLSv1.2 is preferable to enabling TLSv.1.1 and/or TLSv1.0 in NFM-P.

Note: The ability to enable unsecure protocols in NSP will be removed with little notice in a future release.

Note: Outdated TLS versions present a security risk and are disabled by default in NSP. Customers that enable older insecure TLS protocols do so at their own risk. TLSv1.2 is the recommended version.

Cipher suites

Cipher suites define a set of cryptographic algorithms for each TLS connection.  During cipher suite negotiation, both server and client must agree on the same cipher suite in order to establish a connection. A cipher suite defines the combination of key exchange, authentication, encryption, and integrity algorithms for the TLS connection.

The following example displays the format of a TLS cipher suite.

Figure 3-1: TLS cipher suite example
TLS cipher suite example

NSP supports strong TLSv1.2 cipher suites by default. The default list of supported cipher suites may be updated in future releases to account for changes in the security level of cryptographic algorithms.

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy (PFS) is a feature of certain key agreement protocols in which there is no link between the server’s private key and each session key. Therefore, if an attacker gains access to a server private key, the attacker cannot use the private key to decrypt any archived TLS sessions. Cipher suites prefixed with "TLS_DHE" and "TLS_ECDHE" support PFS.

Note:  Exercise caution when removing TLS cipher suites; incompatible cipher suites prevent NSP system access from browser and OSS clients.

Authenticated Encryption with Additional Data (AEAD)

In general, TLSv1.2 ciphers compute a mac over the plaintext then the authenticated payload is encrypted.  Although highly unlikely in an NSP environment, this "mac-then-encrypt" approach could open the possibility for some sophisticated padding attacks. Authenticated Encryption with Additional Data (AEAD) is a special class of ciphers that combines encryption and integrity into one operation (ie. mac-and-encrypt). These ciphers compute mac and encrypt simultaneously which can mitigate padding attacks. In NSP, AEAD cipher suites are supported with TLSv1.2. These cipher suites are identified with Galois Counter Mode algorithms (ie. AES-GCM) and CHACHA20_POLY1305.

ECC curves

For cipher suites using EC based DHE key exchange, NSP supports standard TLS curves.

Diffie-Hellman Parameters

For cipher suites using non-EC based DHE key exchange, NSP supports 2048-bit DH parameters. Clients that do not support 2048-bit DH modulus cannot connect to NSP with a DHE cipher.

NSP clusters do not offer any cipher suites supporting DHE key exchange.

Cipher Preference

Certain attacks on TLS server's can be mitigated by enforcing the server's cipher order instead of allowing the client to choose the cipher. NSP server interfaces accessible by external TLS clients are configured to enforce server-side cipher order.

Cipher Customization

NFM-P supports the ability for administrators to customize the list of supported TLS cipher suites. The default list of cipher suites provides a balance of algorithm strength and compatibility. That said, NFM-P administrators may still chose to customize the list of supported cipher suites. See the NSP System Administrator Guide for more information about updating TLS versions and ciphers.

Note: Exercise caution when customizing TLS protocols/cipher suites. Incompatible cipher suites will prevent NSP/NFM-P system access from browser and OSS clients.

TLS certificates

NSP currently supports RSA certificates. ECC certificates may be supported in the future. DSA certificates are not supported.

Note: Certificates with RSA key size of 2048-bits are recommended.

NSP PKI server

The NSP PKI server is a standalone utility that signs TLS certificate signing requests (CSRs) from requesting entities in an NSP system. The NSP PKI server utility is mandatory and is used sign TLS certificates for internal services used by NSP components. It can also be optionally used to sign TLS certificates presented by NSP to external clients (ie. Automated TLS deployment) when a custom NSP certificate is not provided. The PKI server must continue to run until the installation of all products and NSP components that use the PKI server is complete.  Root user privileges are required on the station where the PKI server utility is run.

Note: The PKI server utility only needs to run during installation of NSP components. After installation is complete, the NSP PKI server utility must be stopped.

Certificates signed by the NSP PKI server have the following characteristics:  

In rpm installations, an administrator can configure the IP address of the host running the NSP PKI server. During install, a CSR is sent to the NSP PKI server, which returns a signed certificate. Unlike rpm installations, the NSP container configuration file does not accept an NSP PKI server IP address. Instead, the existing NSP PKI server certificate and key are needed to ‘seed’ a local copy of the NSP PKI utility, which is active long enough to sign the pod certificates.

Note: The PKI server utility is intended for NSP components only.

Certificate Expiry

NSP TLS certificate replacement may be required when:

An NSP/NFM-P checks the expiry date of each local TLS certificate during installation, and every 24 hours thereafter. If a certificate is expired or approaching expiry, the NSP raises one of the following SSLKeystore or SSLClientKeystore alarms:

NFM-P expiry alarms are shown in the NSP and the Alarm Window of the NFM-P GUI.

Configuring advance warning for certificate expiry

Administrators must carefully monitor and refresh NSP TLS certificates before expiry. If certificates expire, some application functions that depend on secure communication may be inoperable. For example, NSP clients may be completely unable to connect to the NSP.

Using the NSP and NFM-P GUI, administrators can configure alarm policies (referred to in the NSP as “e-mail policies” and the NFM-P as “alarm e-mail policies”) to ensure that advance warning emails are sent for certificate expiry events. For example, an NSP policy containing an advanced filter for “Alarm Name equals SSLKeystoreCertificateExpiring” sends an email to the recipient list when the NSP raises the initial warning alarm for TLS certificate expiry.

See the NSP Network and Service Assurance Guide or NSP System Administrator Guide for more information about configuring alarm e-mail policies, depending on platform installation type.

Certificate revocation

Certificate revocation is a mechanism, normally for clients, to identify and reject connections to a server with a revoked certificate. The primary use-case for revoking a server's certificate is if the private key of server or CA has been compromised. Clients have two options to determine when a server's certificate has been revoked:

The client-side mechanisms listed above have some drawbacks related to performance and privacy. OCSP 'stapling' is an attempt to avoid these drawbacks by moving the revocation check to the server. Currently, the NSP application does not support OCSP 'stapling'.

© 2023 Nokia. Nokia Confidential Information

Use subject to agreed restrictions on disclosure and use.