S 5.134 Secure VoIP signalisation

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Head of IT, Administrator

When using VoIP, it is far more important to ensure the integrity and confidentiality of the signalling information than to protect the media streams. One way to ensure integrity and confidentiality is to transport the signalling information using encrypted VPN channels. Another possibility is to use signalling protocols which provide their own protection mechanisms. The two most important protocols for VoIP signalisation are SIP and H.225 (setup signalisation), as well as H.245 (for establishing the logical channels) in the H.323 framework. The security mechanisms of these signalling protocols are described in the following.

In addition to these protocols, there are other signalling protocols such as IAX2 that do not have their own security mechanisms. Furthermore, there are special signalling protocols to control media gateways, such as MGCP, that do not provide any security mechanisms either. These protocols therefore usually need to be secured in the network layer using suitable security safeguards.

H.235

In general, the signalisation can be protected in the H.323 framework using security mechanisms in the transport or network layer (for example using SSL, TLS, or IPSec). These mechanisms, which are independent from the signalling protocol, can be used in environments with high security requirements. Furthermore, protocol H.235 can also be used to protect the integrity and confidentiality as the only protection mechanism for signalling in the event of normal protection requirements. It must be decided whether and how the signalling will be protected with H.323. The decision made must be documented.

H.235 defines comprehensive security mechanisms to protect H.323-based telephony. The specified mechanisms particularly cover the protection of the call-signalling channel (H.225/Q.931) and of the control channel (H.245) in addition to the security of the media stream.

H.235 deems all system components that are end points of an encrypted H.245 control channel or an encrypted logical channel trustworthy components that need to be authenticated accordingly. A gateway is an example of a trustworthy system component requiring authentication.

One of the following types of authentication should be selected:

a) Authentication using symmetric cryptography and a shared secret that has been exchanged beforehand (for example a password). Symmetric encryption procedures or keyed hash functions can serve as the cryptographic procedure, in which case the shared secret is used as a symmetric cryptographic key or can be used to derive the cryptographic key securely.

b) Authentication based on certified public keys and signed messages.

Each of these procedures can be implemented to use two messages with time stamps or three messages with randomly generated challenges as a challenge-response protocol.

c) Diffie-Hellman key negotiation protocol with optional authentication: In the first phase, both communication parties run a Diffie-Hellman key negotiation protocol based on certified public keys. The shared symmetric key generated is then used in the optional, second authentication phase for the actual authentication based on symmetric encryption.

H.235 also specifies another mechanism (media anti-spam) so the recipient of RTP packets can efficiently check if an RTP packet is authentic and comes from an authorised sender. For this, a short MAC (Message Authentication Code) is calculated using selected fields in the RTP packet that is verified by the recipient before starting to actually process the RTP packet. The MAC can be calculated using either an encryption algorithm or a keyed hash function. This mechanism is intended to fend off DoS attacks such as RTP flooding and SPIT on well-known RTP ports and should be enabled whenever possible.

If communication via H.235 is not supported by the VoIP gateways, it is urgently recommended to restrict the access to the gateway as much as possible using IP addresses and H.323 identities. To accomplish this, it is recommended to use a gatekeeper and only permit access to the VoIP gateway in the "routed mode". In contrast to the "bridged mode", in which the gatekeeper is only involved in the authentication and registration processes, all signalisation is performed using the gatekeeper in the "routed mode".

SIP

A basic problem in securing signalling protocols such as SIP is that several components (terminal devices and servers) are often involved in the signalisation, and each component needs to read or even change parts of the signalling information. For this reason, it is impossible to simply apply end-to-end security mechanisms, and application-specific changes need to be made instead.

The SIP standard therefore advocates the use of security mechanisms in the layers below the application layer. In this case, only the communication between the individual SIP components (UA and the proxy, registrar, redirect, and location servers) is secured, which is often referred to as "hop-by-hop" security.

Another argument in favour of hop-by-hop security mechanisms is pointed out in the SIP 2.0 standard, stating that the servers must to be familiar with each other to a certain extent anyway. However, a clear distinction between trust in terms of the signalisation and trust in terms of the media transport is required at this point, i.e. the voice data. If high security requirements were specified, it should be checked whether suitable end-to-end security mechanisms are additionally necessary to protect the media transport. This applies, for example, to the key exchange process for SRTP.

The signalisation should be protected using SIP with SSL or TLS (Transport Layer Security), especially when higher security requirements apply. The SIP specification RFC 3261 specifies that all servers conforming to the SIP protocol (proxy servers, redirect servers, location servers, and registrar servers) must support the TLS protocol with mutual authentication and with one-way authentication. The terminal devices should use TLS to protect their communication with proxy, redirect, and registrar servers.

Review questions:

© Federal Office for Information Security. All rights reserved.