SIP Signaling over TLS Overview

1 Example TLS exchange
2 Call Flow
3 Public Key Certificates
4 Additional Information on the certificates
5 Cipher Suites
6 Additional Information

The IMG 2020 supports TLS (Transport Layer Security) to establish a trust with each external SIP gateway or trusted domain. TLS will provide endpoint authentication by using Mutual or Two-Way Authentication on a hop-by-hop basis. With Mutual or Two-Way authentication both the server and its client will use certificates from a Certificate Authority to authenticate each other. The IMG 2020 uses a digital certificate for authentication and a public key for encryption/decryption. Once the sender is verified then the receiver will send its certificate to the sender for verification. When all information is verified then the SIP signaling can begin. Below is diagram showing the TLS certification process supported on the IMG 2020.

The diagram below demonstrates the authentication process. Both endpoints have a common CA for their certificates. The certificate can be either a self signed certificate and key or a certificate obtained from a CA (Certificate Authority).

The IMG 2020 can act as both a Client and a Server. In the diagram above and example below, the IMG 2020 is the clientand the SIP Proxy/Gateway is the server.

Example TLS exchange

An outbound SIP request is sent from the client and the transport indicates the use of TLS. A TLS connection is opened towards the server on a specific IP address and port.

Client Hello - The client sends a Client Hello message specifying the TLS version and a list of suggested cipher suites it supports.
Server Hello - The server responds with a Server Hello message with the TLS version and a chosen cipher suite.
Certificate from Server - The server presents an X.509 certificate or certificate chain to the client for verification as part of the initial TLS handshake.
Server Certificate Request - The server then requests a certificate from the client so the connection can be mutually authenticated. (optional)
Server Key Exchange - The server sends the client a Server Key Exchange message with the Public Key information sent in step 3.
Server Hello Done - The server sends a Server Hello Done message to tell client it is finished with initial negotiations.
Certificate from client - If the server requests a certificate, the client must send the certificate or certificate chain.
Client Key Exchange - The client sends a Client Key Exchange message which may contain a PreMasterSecret, Public Key, or nothing depending on the cipher suite chosen.
Certificate Verify - This message is sent when the client presents a certificate as above. Its purpose is to allow the server to complete the process of authenticating the client.
Change cipher spec - The client sends a message telling the server to change to encrypted mode.
Finished - The server tells the client that it is ready for secure data communication to begin. This is the end of the SSL handshake.
Change Cipher Spec. - The server sends a message telling the client to change to encrypted mode.
Finished - The server tells the client that it is ready for secure data communication to begin. This is the end of the SSL handshake.
Encrypted data - The client and the server communicate using the symmetric encryption algorithm and the cryptographic hash function negotiated in Messages 1 and 2, and using the secret key that the client sent to the server in Message 8.
Close Messages - At the end of the connection, each side will send a close_notify message to inform the peer that the connection is closed.

Call Flow

Below is the authentication process shown in a call flow diagram to help understand the process.

Public Key Certificates

A Public Key Certificate provides a safe way for an entity (Client) to pass on its public key to another entity (Server) to be used in asymmetric cryptography. Asymmetric cryptography will verify that the client is who he says he is. There are two types of Certificates, CA signed and self signed. The IMG 2020 supports them both. The IMG 2020 supports the PEM (Privacy Enhanced Mail) standard for these certificates. The CA Organization will supply three PEM files which are loaded into the directory from which the IMG 2020 system software is loaded from. For example, if loading software from FTP server, the three files displayed below must be loaded in the directory that the bdn2020_ver230xxx_id0201.bin file is loaded from. Examples of certificate files are shown below.

privateKey.pem
publickey.pem
CAList.pem

The user can change the names of the files below if desired.

Additional Information on the certificates

CA signed Certificate - A CA certificate is a certificate created by a trusted CA Organization that issues these certificates. The CA Organization creates the certificates which contains a public key and the identity of the owner. It is up to the CA Organization to verify the applicants credentials. The certificate is then delivered to an endpoint which is pre-configured to trust certificates that are created/assigned at a CA Organization.

Self Signed Certificate - A self signed certificate is created by the user. The self signed certificate is faster to create but is not signed by a trusted CA Organization. The self signed certificate requires that any client that connects over an SSL connection to the server that has this certificate installed, be configured to trust the signer of this certificate. Because the certificate has been self-signed, the signature is not likely to be in the clients trust file and must be added. Self signed certificates are useful when each client interacting with the server can be configured to trust the certificate.

Cipher Suites

A cipher suite is a set of algorithms that TLS uses to encrypt the data to secure a connection. When a certificate is sent from the IMG 2020 during negotiation, the following cipher suites are offered. The server will decide which cipher suite will be used. The IMG 2020 supports the following cipher suites with SIPS protocol and they are not configurable:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_DH_DSS_WITH_AES_256_GCM_SHA384 (0x00a5)
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 (0x00a1)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 (0x0069)
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 (0x0068)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
TLS_DH_RSA_WITH_AES_256_CBC_SHA (0x0037)
TLS_DH_DSS_WITH_AES_256_CBC_SHA (0x0036)
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032)
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_DH_DSS_WITH_AES_128_GCM_SHA256 (0x00a4)
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
TLS_DH_RSA_WITH_AES_128_GCM_SHA256 (0x00a0)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 (0x003f)
TLS_DH_DSS_WITH_AES_128_CBC_SHA256 (0x003e)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
TLS_DH_RSA_WITH_AES_128_CBC_SHA (0x0031)
TLS_DH_DSS_WITH_AES_128_CBC_SHA (0x0030)
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

TLS only allows SIP entities to authenticate servers to which they are adjacent to. Establishing a TLS connection authenticates both transport endpoints but does not authenticate the SIP messages flowing through the link. For example, two proxies may carry traffic between them over TLS but this does not stop a malicious gateway from injecting suspect SIP traffic in either end of the TLS link. SIPS can be used to ensure that TLS is maintained for all hops carrying SIP messages, therefore reducing the risk of such an attack. SIPS is enabled/disabled in the SIP Profile - SIP Advanced Settings.

Additional Information

The IMG 2020 supports SSLv3 and TLSv1.2.
TLS is supported only over TCP and requires a separate port. The default port is 5061 and is configurable in the SIP Signaling object.
The IMG 2020 SIPS protocol supports 128 Bits Encryption only. Different than HTTPS where 256 Bits Encryption is also supported.
A Certificate Database is created and uploaded to the IMG 2020.
The IMG 2020 will allow a maximum of 16 Trust ID's or Certificate Entries
TLS is also supported on the IMG 2020's virtual IP addresses
The IMG 2020 supports X.509 certificates only and supports a maximum depth of CA certificates during certificate verification to four.
The use of certificates requires that the clock on the IMG 2020 be synchronized with the network time to ensure proper validation of certificates. To configure clock see Configure SNTP.
CRL (Certificate Revocation Lists) are not supported.
SNMP or MIB requirements are not supported.
DNS or ENUM lookups of NAPTR/SVR records containing SIP URI's is not supported.

Dialogic Integrated Media Gateways