The SIP security architecture
The SIP security architecture has grown during the years since RFC 3261, the original SIP standard, was published. At that time, there was no experience and no previous examples on how to secure. A lot of mechanisms was simply missing. Now, almost ten years later, the situation is different. A problem is that too many vendors still use RFC 3261 as the reference and haven’t looked at the new SIP platform.
Issues to handle
- Integrity: A message should not be changed in transmit – nor multimedia
- Confidentiality: If needed, no one should be able to eavesdrop on your communication
- Identity: Being able to verify parts involved in the communication
- Non-repudiation: Not being able to deny that communication happened
Provider-managed security or end-to-end security
SIP lives in the convergence between telecom and datacom. The telecom world traditionally have built centralized solutions and relied on customers trusting them to manage security. In the datacom world, security is handled locally, not by the external network provider (or ISP). Connections are secured end-to-end with protocols like SSH, IPsec, TLS and others. The provider is not involved, the customer manages the security platforms.
When looking at the SIP security infrastructure, you need to keep these models in mind.
Security mechanisms in SIP
The current SIP framework includes many mechanisms that provide security support for your SIP realtime infrastructure.
- HTTP authentication with MD5 or SHA256 – hop by hop
- TLS identification of servers and clients – hop by hop
- TLS confidentiality – hop by hop
- S/MIME identification – end to end
- S/MIME confidentiality – end to end
- S/MIME integrity – end to end
- SIP Identity – secure identities and message integrity between domains
- SRTP confidentiality – end to end
As you see, SIP requires a lot of trust in intermediary servers, since many security mechanisms are hop by hop – from the phone to the first server and server-to-server. In the server, between the hops, communication is insecure within the server. This is a good example of a traditional telecom model, a model that would be hard to implement across the Internet where you can’t put that amount of trust in an unknown server. It may work within enterprise networks, where there’s a security policy and known management principles. New security mechanisms are trying to focus on end to end solutions and trust between SIP domains to enable communication between different parties over the Internet.
TLS for SIP – identification protection of signalling
TLS provides a way to set up secure connections to servers that can be securely identified. Like in secure HTTP for the web, the server has a certificate and may request a client certificate in order to verify the identity of a client. The problem with TLS has been managing the certificates and providing the phones with identities. New standards provide a SIP certificate distribution facility that makes it possible to find other users credentials in order to set up a secure communication path, as well as getting the phones own certificate and keys.
Standards as SIP connection reuse and SIP outbound provides means to set up a secure connection and reusing it for requests in both directions – inbound and outbound calls – for a long period of time. This not only helps NAT traversal, but keeps the connection setup time to a minimum.
What about S/MIME?
S/MIME has been part of SIP from the start, yet not many SIP implementations exist that support it. S/MIME signs a message, and if needed encrypts it, in a way that makes it impossible to change the message in transit. Unfortunately, the first generation of NAT traversal solutions required that servers change messages in order to provide a working media path across the network boundaries. With new solutions like ICE, where the client finds a path across the network, S/MIME becomes possible again.