tls


In a SIP network, you often have multiple servers communicating with each other. As soon as you add TCP and TLS to the mix, you will want to reuse connections. Why? Setting up A TLS connection involves a lot of messages going back and forth in the process up validating certificates and coming up with keying material for the encrypted session. Now if you have a re-invite that wants to put a call on hold, you don’t want to loose a lot of packet-roundtrip-times while this happens. A better solution is to keep connections open where possible and allow communication both ways.

RFC 3261 states that if you open a connection with a connection-oriented protocol, like TCP or STCP, the connection should stay open to cover the whole transaction. This means that if the other end sends a message in the dialog, a connection needs to be opened in the other direction. This is of course a problem with NAT between a device and a server, something that the SIP Outbound standard handles. Between servers, like B2bua’s and proxys, the problem still exists. This is managed by the Connection Reuse RFC, RFC 5923.

Mutual TLS authentication opens up for two-way communication

RFC 5923 – SIP Connection reuse – explains how this can work. One requirement is that the TLS connection has mutual connection, which means that the server ask the client for a certificate. The client indicates in the request that it is prepared to receive inbound requests, not only the response to the request, on the same connection. When that happens, the server and client sets up a connection table where the content of the certificates are stored – the domains and host names. Now if one of them has a request that is targeted to the same domain and the same IP and port (after DNS SRV lookups), the connection can be reused.

Checking and caching the certificate content

When the connection is initiated, both ends provide TLS certificates that contain one or multiple names or SIP uri’s. This list is cached and associated with the session. Now, if the same server host multiple domains, you can’t use the connection if the domain that is the target of the request doesn’t match the names in the certificate. In that case, you need to open a new connection to the same server.

Use DNS host names instead of IP addresses

On a related topic, notice that the RFC always use host names and not IP addresses in the Via: headers. This is of course a requirement if you want to match certificates. For TLS to work in all directions, host names should be used in Via: and Record-Route/Route headers. With a GRUU, you can also have a domain in the Contact. This also helps IPv4/IPv6 dual stack handling, letting every path select the optimal connection.

Combined with SIP outbound we have open connections all the way

Connection reuse is an important feature for all SIP servers, B2BUAs like Asterisk and SIP servers like Kamailio. Without it TLS will be hard to use and cause delays that will affect the calls. In combination with SIP Outbound, where the UA manages the connections to the first-hop servers, it is a working solution for TLS over NAT as well. Keeping TCP/TLS connections open like this is not new, Jabber/XMPP has done this from start. It’s just new to SIP.

I think SIP Connection Reuse support should be on the list of requirements when you select your next SIP application server for your Open Unifed Communication platform.

Lately, I’ve been going through a lot of SIP RFCs and drafts, trying to get an overview of the security suggested in all of these documents. The quality of this work, seen from a developer’s perspective, is quite poor. Sometimes it seems like authors think, “oh, we need to add that security stuff, so let’s add a few keywords like TLS and S/MIME here and there“. We need to get better in reviewing the drafts from a security perspective. Here are  some thoughts on instructions to RFC authors:

  • S/MIME: If you refer to S/MIME, make it very clear which certificates that are going to be used and how the certificate verification process should happen – which part of the SIP message should match with which part of the certificate? And which certificate should be used to encrypt?
  • TLS: If you refer to TLS, you need to be very clear on why – is this to provide authentication, confidentiality or something else? Does the solution require mutual authentication or just server authentication? If authentication is part of your solution, make it very clear how you verify the certificate with the message, down to SIP header fields and X.509v3/PKIX fields.
  • SIPS: If you suggest usage of SIPS, make it very clear on what this adds and how the message flow is supposed to look like. Is SIPS used in the request uri, the Contact or somewhere else? What is the effect? Make sure you really understand SIPS before this is added. Or even better, just avoid SIPS and let it fade away.
  • Certificate matching: If you refer to a certificate SubjAltName, make very clear if it’s a URI or a dnsName field that is required and preferences if there are multiple SubjAltNames in addition to the certificate subject.
The worst documenst so far are the RFCs related to SIP subscriptions. They suggest using S/MIME for encryption, but does not explain how. Now, if I subscribe to the presence status of sip:bob@example.com, my SUBSCRIBE request will end up at the presence server for the domain example.com. Should the user agent somehow find the certificate for sip:example.com to encrypt the message? Should we use the certificate of sip:bob@example.com – which would require the presence server to have the private key belonging to Bob? The RFCs doesn’t help at all.
RFC 3857 states the following on the topic of eavesdropping on SUBSCRIBE/NOTIFY requests:

“To prevent that, watchers MAY use the sips URI scheme when subscribing to a watcherinfo resource.  Notifiers for watcherinfo MUST support TLS and sips as if they were a proxy (see Section 26.3.1 of RFC 3261).”

This means that a UA should be able to SUBSCRIBE over a TLS connection, and get NOTIFY over – what? Remember that this was written before SIP Outbound was standardized. For a developer this means that the subscriber is required to have a TLS certificate and accept incoming connections on the TLS port if the Contact in the SUBSCRIBE is a SIPS uri. The RFC should discuss this in more detail.

Nine years after RFC 3261 we have a larger toolbox, including GRUUs, SIP Outbound, SIP Domain certificates, DNSsec and much more. It’s time we restart the work with a SIP security architecture and provide something that developers can implement and that users will clearly feel is a better and more trustworthy solution. The IETF mantra is “rough consensus and running code”. RFCs should make it easy to produce running code. The SIP RFCs fails do this on the topic of SIP security.

/Olle

 

 

 

Realtime communication in web browsersVideo sessions in the browser opens up for a lot of new applications. While this has been working with various plugins, new opportunities will open up when it becomes part of your standard web browser. HTML5 introduced native video in the browser. New standardization are looking into peer2peer multimedia sessions in the browser, not just broadcast. This opens up for a large set of applications, from “click2call” without plugins to video chats like in Facebook and Google+. This is exciting. And all the old SIP architects seems to have jumped onto this project, trying to get things right from start in this second generation effort. (more…)

Alec Saunders has written a new manifesto called “Voice 3.0: The emergence of the Voice Web“. It’s very good reading and I agree with most of it. Please read it! What I am missing, which you will see in my comment far down the side, are two things:

  • IPv6 – it’s the glue that will make Voice 3.0 work
  • Security – we need to learn from our mistakes and make Voice 3.0 secure by default

I have written a lot of information about SIP and IPv6 on Edvina’s web site, Twitter and Facebook. Dan York has joined me in this campaign and have a lot of good podcasts, presentations and information on Voxeo’s IPv6 resources page. There’s quite a lot of work we still need to do, but we’re heading in the right direction in the SIP community.

I’m embarrassed

Now is the  time to start working on security. I find it really embarrassing that we have almost no experience of security in VoIP. The protocol has been around for ten years or more and we’re still confused. The hardware vendors claim that the CPUs can’t handle it. Or the DSP’s. Or something else. As we move towards more video we need more CPU power to encrypt. On the other side we have users that doesn’t require any security. They run stuff over the enterprise networks, over home networks and the Internet without bothering with who can listen in, access the log files or access their accounts.

The dark side

This last year, the number of attacks on SIP servers has grown in numbers. I hear not only rumours, but see attacks in progress. I have met a number of people who have lost huge amounts of money on International calls to foreign countries, placed by unknown hackers that figured out that their account (typically “300″) had a very complicated password (typically “300″). The next thing that we’re going to see during summer leave or xmas is someone showing a journalist how easy it is to see that the boss calls the union several times a day, propably to negotiate layoffs. Or calling competition, maybe to sell the company.

Let’s agree on one thing: ALL networks are insecure

I think it’s time to stop ignoring security. I think we have to agree that it makes our architecture much more easy if we assume that ALL networks are insecure. We can not judge, our users surely can not determine if a network is secure or not. They have to be able to connect to any open WiFi network and use the services we produce. Without thinking about anything else than reaching their office, customer, family or the kid back home. Every communication needs to be secure. Period.

If we start there, we’re on the right track. Now we need to work together and figure out where to go. How do we exchange encryption keys? How do we handle identities? Where do we start. Let’s not make the mistake of trying to hook on to a global PKI that doesn’t scale (and has proven not to be secure) like the one used by the web. PGP is interesting, but only scale on a nerd level. It’s too complicated the way we use it today. I would not even try to explain it and make my mother use it. We need to work on this.

Distributed webs of trust

Maybe it’s Facebook, Google+ or LinkedIn that will be the trust platform. Or a combination of them using systems like OpenID, oAuth and SAML 2.0 in various combinations. We need something simple, scalable and secure. That’s not easy to fulfill. Especially in a world filled with engineers with a lot of opinions, experiences and ideas. It’s our responsibility to start working on this. The IETF and other parties are already working hard on other components of Voice 3.0.Let’s get our act together on the security part of the vision for Voice 3.0 too. We need to, step by step, build a trustworthy platform for realtime communication for everyone.

A friend of mine, Jacob Schlyter, has not only been busy working on DNSsec around the globe. He has also been co-writing a new draft in the IETF DANE working group. He blogs on kirei.se:

The working group’s first draft describes how to use DNSSEC to associate certificates with domain names For TLS. In this context, a certificate association is a secure binding between a DNS name, TLS/DTLS transport protocol (i.e., TCP, UDP or SCTP) and port number, to an end entity’s certificate or to a certification authority’s certificate.

This proposal builds a distributed PKI based on DNS.  If you want to call me in the voip-forum.com domain, you will be able to get my certificate chain from DNS and set up a secure and trusted session. The current PKI model used in the web delivers encryption – but few bothers with checking identity of the other end, check if the certificate chain is trusted or even if a certificate is revoked.

In SIP, we can do better and really kick off DANE. I will work on this and write more as I make progress in trying to understand the details.

For many years I have believed that DNSsec is a platform that will change the trust model on the net. Now, the light is on the ICANN, IANA and the TLD registries. Will they earn our trust?  Will they be better than the current set of web CAs that someone else approved for all of us? If not, we will have to start building a distributed trustworthy root soon. The technology is getting there, so the focus needs to move to the people and organizations that will be the new platform. These are interesting times. Let’s start discussing SIPdane and get a few implementations running soon!