A recent comment on Leo's stand alone VoIP service post brought up a topic always worth exploring; SIP security. Here's the quote:
The big thing I am concerned with is will [Google] implement [SIP service] securely??? Will it utilize encryption, for both signaling and media? I could see malicious folks attempting to utilize SIPVicious and other sip cracking tools to try and take over accounts. Also, this could lead to toll fraud, in my opinion. If you have a balance on your account or automatic billing, someone takes over your account (which is easier now because all they have to do is brute force your sip client) then they can start making calls as you on your dime. I think there are several security risks involved with this..... Nick Grant secvoip.com
This comment has some good points that I want to to explore because it's important to understand what we mean when we say secure SIP. When talking about securing your VoIP traffic, you can really break this down into 3 large categories:
- Securing passwords
- Signaling encryption
- Media encryption
Securing Passwords
First, let's take a look at password security. In our minds, this is the most important of your VoIP (or any other webservice) security layers. In OnSIP, your VoIP password is what we use to authenticate your phone when it attempts to perform certain actions. For example, we require authentication for registration and dialing toll-based services like the PSTN. With this kind of reliance on passwords, an insecure password can directly lead to hacked accounts and lost money through toll fraud. In this case, the key to preventing a hacked account is to choose secure passwords that are not easily guessed or so short that they're likely to be in someone's rainbow table. This is one reason we only allow randomly generated passwords for the VoIP password. All too often do we hear about our PSTN gateway customers running their own PBXs on which they choose their own passwords - or even worse don't change the default passwords - and end up using passwords that are easily guessed by hackers and fraudsters.
Once we have a strong password configured on the server and in the phone, we need a way to let the phone send its password to the server without communicating it to anyone who may be snooping around the network. Further, we need a way to do this when the whole channel is unencrypted. Enter digest authentication and one-way hashing. Let's look at a SIP registration back and forth to examine how SIP uses digest authentication and what that means for transmitting your password.
My password is in that Authorization header, but you can't tell me what it is. Even though the packets may be transmitted in plain text via UDP, TCP, or this blog post, the password is one way hashed via the "quality of protection" (QOP) auth mechanism defined for digest authentication. From the RFC:
The Digest Access Authentication scheme is not intended to be a complete answer to the need for security in the World Wide Web. This scheme provides no encryption of message content. The intent is simply to create an access authentication method that avoids the most serious flaws of Basic authentication.
Computing Digest Authentication Responses
Each piece of the digest authentication is designed as a mechanism to make the authentication stage stronger against various attack vectors. Here is a short definition list of the more obscure parts of digest authentication with a quick note about each parameter's purpose.
- nonce
- A server side generated seed for securing the digest response. The nonce may be unique for each client and used only for a limited time so as to protect the server against replay attacks
- cnonce
- (client nonce) Like the server nonce, the cnonce is a client side generated seed. Instead of being designed to protect the server, though, the cnonce is designed to protect the client against nefarious proxies, man in the middle (MITM) attacks, precomputed dictionary attacks, and other attack vectors. The cnonce is an optional mechanism in the original spec, but it's required in the case of
qopbeing defined. For instance, let's say badserver.org is out on the interwebs sendingINVITEs to random SIP clients 24x7. When unluckybob@unsuspecting.org answers his phone, the badserver.org folks just wait for unluckybob to hang up the phone and send theBYE. At this point, badserver.org rejects theBYEwith a 407 Proxy Authentication response. Poor unluckybob@unsuspecting.org may now have been tricked into sending his (precomputed) hashed up authentication credentials to badserver.org. If Bob's user-agent responds to authentication schemes that don't require a cnonce, then he may have just given away his username and password. (Thanks to Sjur Usken for that case.) If the client seeds its response back to the server with a shared cnonce, it will effectively make badserver.org's large, precomputed table of common password responses useless. - qop
- The "Quality of Protection" field, effectively the digest auth specification, allows for alternate computational algorithms to be defined. The qop field allows the server to communicate to the client which computations it can accept.
- nc
- (nonce count) Nonce count is an incrementing integer, controlled by the client and tracked on the server, indicating the numbered sequential requests that have been sent by the client with this nonce/cnonce pair. This allows servers to detect replay attacks and "act appropriately" if so... like shut down and run for cover.
To view a sample implementation of the QOP auth algorithm, I've coded up this small ruby utility to calculate the digest auth for you, check it out here. Feel free to use it off the command line like so:
$ ./digest_auth.rb unluckybob lazypassword sip:unsuspecting.org REGISTER badserver.org easy-nonce auth client-nonce-protects-bobHere's your digest:d0fe5c04c64f4b1bbf6e6d35d684046d
Feel free to use this utility however you see fit; however, keep in mind its only intended purpose is as a demonstration of digest auth for the current discussion.
I hope this explains how digest authentication is used to avoid plain text password transmission is avoided even when SIP signaling is transmitted in the clear. As long as you are choosing strong passwords, and using SIP clients that will only respond to strong authentication requests then your password should stay safe.
Signaling and Media Encryption
I hope it's obvious now, that it is unnecessary to encrypt your traffic to secure your password. However, let's talk about encrypting your signaling and media traffic. For this discussion, I will only take a look at the SIP/SDP/(S)RTP protocol stack. (Any protocols and standards defined outside of the RFCs referenced in this post are outside the context of this discussion (is that a tautology?)). This post is only meant as an overview of common industry practices). 
Just to remind us, let's keep in mind the OSI (7 layer burrito) model and where we are at at each point of this discussion.
Securing the Signal
Unlike password hashing, we must be able to decrypt VoIP signaling and media to make usable messages out of them on the remote endpoint. Various methods exist for securing the signaling; however, TLS remains the most common, complete, and recommended solution to securing SIP. Even more than simply sending an encrypted SIP packet across one hop, what a user truly wants in SIP security is an encrypted end to end stream.
RFC 3261 recommends SIPS to be delivered over TLS on every segment of the call, providing end to end security. If a remote endpoint can't be reached via secure channels, then insecure SIP URIs may be attempted. But, when calling a SIPS URI, the call signaling is supposed to be encrypted end to end. SIP encryption via IPSec is a more ad hoc approach and does not guarantee end to end encryption. By definition, IPSec only provides hop to hop encryption, and no alternate security URI is defined to identify SIP over IPSec like there is the SIPS URI. Other suggestions also exist for DTLS in the case of UDP; however, finding either client or server implementations is difficult, at best, and really just non standard in practice.
Because SIPS over TLS is the SIP standard for security (see RFC 3261), there is a slightly higher barrier to entry for providing secure SIP service than for providing connectionless message oriented SIP service (i.e. UDP). I will stop here. It is out of this article's scope to explain why maintaining streams consumes more physical resources than maintaining datagram based connections in standard select/poll based architectures... (but let's hope OpenSIPs new 2.0 architechture is making great strides here).
Securing the Media
When discussing signaling and media encryption, we must encrypt signaling before worrying about encrypting the media. Why is this? Many people think of encrypting your VoIP calls as simply obfuscating the media stream. That view point is forgetting the important detail that the signaling always controls the media stream. SRTP, described via SDP payloads of SIP packets, is encrypted using a set of clear text cryptography parameters to describe the encryption algorithm and keys that allow decryption of the associated RTP. If those keys are sent in the clear, then any unauthorized party would have all necessary information ahead of time to decrypt the encrypted media, rendering the encryption useless. From RFC 4568:
...IT IS REQUIRED that encryption of the encapsulating payload be used whenever a master key parameter (inline) appears in the message. Failure to encrypt the SDP message containing an inline SRTP master key renders the SRTP authentication or encryption service useless in practically all circumstances...
Most of the following discussion can be found in section 4 of rfc 4568. Describing the SRTP encryption parameters comes through the crypto SDP attribute:
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
In a practice example, this ends up looking like the following:
...sdp attributes...a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32...more sdp...
I'll leave the description of the crypto attribute as an exercise for you to read about in the rest of RFC 4568. The point here is that the sender must transmit to the receiver all necessary information to decrypt the SRTP packet in order to make that packet useful at the receiver end. As this information is described in the signaling layer, we must encrypt the signaling in order to encrypt the media in any meaningful way.
Google Voice DNS Records
OK... so what's my point and how does this at all involve Google?
Since we've been on a recent tangent about talking about a possible SIP avenue into Google Voice provided numbers and with the comment at the top of this article I thought I would simply enumerate the SRV records that we can find for Google's SIP service in the hopes it gives us some insight on what they're planning.
In short, it looks as though Google will only roll out UDP service to start, unless they have some other domain names that I don't know about, which is entirely possible. Anyway, let's assume for this discussion that sip.voice.google.com is the only domain we're considering here. Because RFC 3263 tells us how to find a SIP server, we know how to look for DNS records to do some snooping around Googles SIP service. Lets start with some NAPTR records.
Click to view NAPTR DNS lookups
Well, unfortunately there is not much to go off of there for named pointer records; although, we did learn about a few new domain names. Let's try doing SRV record lookups on sip.voice.google.com...
OK, so here at least we see something interesting. From the UDP SRV lookup we can see a list of a few servers listed as providers for UDP SIP service for sip.voice.google.com. Although there is nothing listed for TCP and SIPS TLS records. Infer what you will from this but I will take this as a sign that there is no near term plan to offer TCP or SIPS service (although - I belive gizmo phone did have a TCP offering - _sip._tcp.gizmo5.com. 8000 IN SRV 10 10 5060 proxy01.sipphone.com.). If that is true (about no TCP) then I think it may allow us to reasonably assume that in any near term offering on Google Voice SIP service, there will probably be no encryption services available as hoped for in the original comment. That being said - if Google wanted to roll out a SIP phone registration service (which I doubt) they would of course still be able to do this over UDP while keeping passwords secure... hey I know a company that does that!