SIP Security
From Pbxnsip Wiki
Why is security an issue?
Users expect that their phone calls are kept private. Listening to phone calls without permission from a public authority is illegal, and there are frequently cases in the press when this rule is being violated. Unfortunately, there are methods that make it possible to redirect packets in the local area network, for example to a desktop PC (ARP attacks). While you had to get physical access to the cable for TDM-based PBX, you can do this by installing a sniffer tool on your PC.
To address this problem, SIP uses the secure transport layer (TLS), which is also used for web-based security. TLS is based on SSL 3.0. The encryption of the voice packets uses a different standard, SRTP. SRTP is based on AES with at least 128 bit. This should be "pretty private", even if someone is able to relay the packet via PC in the network.
How does it work?
When a phone registers, it establishes a secure connection to the PBX. This security negotiation may take a few seconds—there is some heavy number crunching involved. But the registration period is not time critical, because the user is not aware of this delay.
After the secure connection between the phone and the PBX is established, either the phone or the PBX may initiate a call. The call-related information like caller-ID will be private between the PBX and the phone, because the information is exchanged using the existing secure connection. This call setup is fast, as the necessary security information has already been negotiated during the registration process.
The keys for the SRTP can now also be exchanged in a secure way. Like the caller-ID, this information is invisible to someone listening on packets in the network.
During the call, the PBX will receive SRTP packets, decrypt them, and send them out on the other side of the call. If the other side of the call is also using SRTP, the PBX will encrypt the RTP traffic using the key that has been negotiated with this side. This is called “SRTP transcoding”. Because the PBX does have the security context for both calls, it is able to record the call, even if both sides are using secure media.
Is SDES supported, if yes in which versions?
SDES stands for “Session Description Protocol Security Descriptions for Media Streams”. The SDES standard is used to exchange the keys between the phone and the PBX (see for example http://en.wikipedia.org/wiki/SDES). The pbxnsip PBX supported SDES right from the beginning. SDES is not a RFC (http://tools.ietf.org/html/rfc4568).
Is MIKEY supported, if yes in which versions?
No, this is not supported. The reason is that MIKEY comes with a high implementation effort and it seems that most implementers prefer SDES.
In the context of SRTP, what happens if the IP-phone supports authentication tag but with length less than 80-bit (as described in RFC3711)?
According to SDES, the MAC must be either 4-byte or 10-byte. We support both modes. The negotiation happens in SDES.
In the context of TLS, briefly how the certificates are managed?
You can upload a standard certificate into the PBX. Currently we support only one certificate for one domain that might change in further releases. We do not check the certificates of the clients, as usually they use self-signed certificates (DHCP).
How can I provision phones in a secure way?
The provisioning phase is a very critical phase, because during that time passwords have to be put into the phones and it must be made sure that no one captures the password on the network. Using a secure connection for the provisioning solves the problem of keeping the password secure, but it requires that the phone authenticates itself (otherwise any client can retrieve the password).
There are three methods for provisioning secure passwords:
- The PBX does not provision passwords with the plug and play mechanism. While you can use the plug and play for all other parameters, you must put the passwords either through a secure web server connection on the phone or you manually enter the password in the user interface of the phone.
- The PBX provisions the password only once. All other requests for the configuration file will skip the password information. The domain administrator may set or reset the flag for an extension manually if a new phone needs to be provisioned or if a specific extension should be blocked from automatic provisioning.
- The PBX always provisions the password. This most is very convenient, but not very secure.
What is (in terms of technology) "security end-to-end"?
That is a security policy enforcement triggered by the use of a "sips" URI. If the phone sends this scheme, the PBX will establish a call on the other side of the B2BUA only if the other side is secure. Trunks can be marked as exception, as practically there are only very few secure PSTN gateways able to support TLS/SRTP. Please note that this features must be specifically enabled.
Which phones support security?
snom works with TLS/SRTP/SDES. This phone allows easy setup of the TLS connection, because by default it accepts any certificate.
The counterpath soft phone also works with the pbxnsip TLS/SRTP/SDES mechanisms. However, counterpath is very strict on accepting certificates from the server, therefore you must make sure that the PBX uses a valid certificate.
Polycom phones are also supporting TLS transport layer. However, there is no experience regarding the support of SDES and SRTP.
Cisco phones are reported to support TLS, but it is not clear how to make them use TLS.
We expect that all SIP phones will offer security soon, because of the security threats in computer networks.
