The Role Of SIP In Advancing A Secure IP World

Internet telephony is poised for widespread adoption. Already, there are countless Voice over IP (VoIP) services that collectively boast millions of users worldwide, with a compelling new set of telephony services and features appearing on desktops and mobile telephones everywhere.

Today, the Internet allows users to readily send information to many people with great ease and speed a significant departure from the managed service of the traditional telephone network, where service providers oversee every call. However, with these innovative new capabilities, how will the Internet live up to consumer expectations for superior security and privacy, two hallmarks of traditional voice service?

The Session Initiation Protocol (SIP) identity standards have evolved as a means of addressing VoIP security issues. SIP provides VoIP services with a critical rendezvous function by connecting users to one another. More specifically, SIP allows a user to discover how best to reach the person they want to contact whether on their mobile phone, home phone or PC. SIP identifies the right device to accept a call, then allows the endpoints to negotiate what sort of session is optimal based on their device capabilities and preferences (VoIP, instant messaging, videoconferencing, etc.) Finally, once the endpoints have agreed on what kind of session is optimal, SIP manages the session for its lifetime, controlling when media will and will not be sent, allowing endpoints to add new media to a session as necessary, and closing down the session when the communication is finished.

SIP leaves the work of describing sessions to a different protocol: the Session Description Protocol (SDP). SDP is tunneled within certain SIP messages as a MIME body, the same way that a plain-text MIME body might be carried in an e-mail message. These SDP messages are not intended to be written and read by users, however. Instead, SIP devices and applications use them. A SIP device creates an SDP message that describes its own capabilities (voice, instant messaging, etc.) and combines them with priorities set by users. When a device receives a SIP request containing SDP, it compares the capabilities and preferences described in the SDP with its own, and creates a response that determines the best way for these two devices to communicate.

Once SIP has provided the rendezvous function, and SDP has figured out the right way for devices to communicate, the actual session media can begin to flow between devices. That media can take any number of forms, depending on what kind of session has been established. For VoIP sessions, the most common type of media is the Realtime Transport Protocol (RTP), a lightweight protocol optimized for carrying real-time information on the Internet. RTP carries the actual packets of audio that are gathered by the devices participating in a VoIP session. Also, RTP starts and stops when SIP tells it to do so. The precise IP address to which audio packets are sent is specified within SDP, as are the codecs supported by the endpoints.

These three protocols (SIP, SDP and RTP) operate in concert to provide a VoIP service for the Internet, making the security capabilities of these protocols quite interdependent.

When we start to investigate the security needs of VoIP, the core questions are fairly obvious: How can I know who is calling me? How can I be sure that the audio I am hearing is coming from the right place? How can I prevent unwanted calls? How can I prevent eavesdropping?

Because SIP draws so much of its protocol design from e-mail and the Web, it is able both to rely on the strengths of e-mail and Web security and to learn from their shortcomings.

So what are the strengths of email and Web security? Most Web users are familiar with the Secure Sockets Layer (SSL) that is used to secure e-commerce connections, though few may know that SSL changed its name a while back to Transport Layer Security (TLS). TLS is most famous for providing encryption that prevents eavesdroppers from learning credit card numbers sent to Web pages. Perhaps even more importantly, though, TLS passes a certificate from a Web server to a browser, which identifies the Web site to which the browser is connected. The browser can then compare the URL entered by the user (e.g., http://www.example.com) with the URL contained in the certificate. If the two match, then the user knows he or she has connected to the right Web site, and that a wrongdoer isnt trying to collect their credit card number through a phony Web site.

Another security mechanism familiar to Web users is passwords. The manner in which the Hypertext Transport Protocol (HTTP) handles passwords is called Digest authentication. Digest only sends an encoded password over the Internet, which helps protect the password in the absence of a mechanism like TLS. Even with TLS, if a Web request goes through a Web proxy, users still might not want that proxy to know their passwords.

The designers of SIP saw how well TLS and Digest work in the Web space, and decided to incorporate these mechanisms into SIP. For example, when a SIP user logs onto to a SIP server and becomes available for calls, the manner in which they register and prove their identity is via Digest. For example, if someone were registering at a SIP service at neustar.biz under the name john.doe, he would send a SIP registration request to neustar.biz with the password for john.doe in a Digest header. In order to be sure that he was actually connecting to neustar.biz, and not another server pretending to be neustar.biz, he would use TLS and verify that the certificate passed by the server matched neustar.biz.

But SIP security cant stop there. In terms of its architecture, and the way SIP messages travel around the Internet, SIP has quite a bit in common with e-mail. Most importantly, SIP messages travel from one endpoint to another endpoint, just like e-mail messages, and they tend to pass through one or more servers on the way. While someone can use a password to identify himself or herself to his local SIP server, sharing a password with all people who might be included in a future SIP session is unrealistic. There may be plenty of people he or she wants to call, with whom he or she has no previous association.

One of the biggest challenges facing e-mail security is the way one knows who sent an e-mail message. There is a From header that indicates to the recipient the identity of the sender. Unfortunately, users can usually put whatever identity they want in the From header. Spammers leverage this tactic constantly to spoof mail from various sources; clever spammers even try to spoof mail from people the recipient may know, increasing the likelihood that the recipient will open and read it. The SIP From header works the same way as the e-mail From header. That is, endpoints populate it. So, the question becomes: how can one ever truly know who is trying to make contact?

The answer is that the security of TLS and Digest can be leveraged to provide an assurance of the identity of the caller. In SIP, this assurance is reflected by the presence of the Identity header. When a SIP call is placed, the calling endpoint connects to a local server and provides a password with Digest just as it does when it logs on. This server then checks the From header field and compares it to the password to make sure the user is authorized to claim the identity listed in the From header. If this is actually the case, an Identity header is added to the request, and signed with the certificate that the server uses for TLS. In other words, the identity header says that the calling domain (e.g., neustar.biz) vouches that this user (e.g., john.doe) authenticated himself properly and that the From header field is accurate. Who better than neustar.biz to tell the recipient that a given endpoint is [email protected]? This Identity header stays with the SIP message as it makes its w ay through proxy servers all the way to the endpoint. Any of these recipients, intermediaries or endpoints can look at the Identity header and see who the calling domain vouches for in the From header.

Identity doesnt just vouch for the From header; it also contains a signature over the body of a SIP message. That secures SDP, and lets any recipient make sure that no one has tampered with SDP. If SDP is secure, then it can contain keys that allow RTP to be encrypted, which prevents eavesdropping. The result is a chain of trust starting with SIP that cascades all the way down to the session media, letting callers know to whom they are talking and making sure that their conversation is private.

Identity itself does not innately prevent unwanted calls or spam, but it does prevent impersonation, which is a critical enabler for both spam and unwanted calls. Without an assurance of identity, spammers can claim to be anyone and thus, there is no way for endpoints to create policy that can block particular senders.

Furthermore, identity provides accountability. The Identity header tells one what domain vouches for a caller, so that domain can be contacted (or blacklisted, as necessary, in cases of abuse). This general idea has applicability far beyond SIP; there is even an initiative for e-mail called Domain Keys/Identified Mail (DKIM) that also uses a domain-based signature to assurance the identity of an e-mail sender.

Through mechanisms like TLS, Digest, and Identity, SIP may very well enable VoIP services that are more secure than what users can expect from the PSTN and just as easy to use. All a user needs to get started is a service and a password, just as e-mail and the Web operate today. The true advantage of a standard approach like SIP is that these services, including security features, will be interoperable across the disparate providers and devices using VoIP on the Internet. If the marketplace brings these standards into their offerings, consumers will rarely have to give VoIP security a second thought. IT

Jon Peterson works in the Strategic Technology Initiatives group at NeuStar, Inc. For more information, please visit the company online at www.neustar.biz.

If you are interested in purchasing reprints of this article (in either print or PDF format), please visit Reprint Management Services online at www.reprintbuyer.com or contact a representative via e-mail at [email protected] or by phone at 800-290-5460.