SIP Security in IP Telephony

Transcription

1 SIP Security in IP Telephony Muhammad Yeasir Arafat and M. Abdus Sobhan School of Engineering and Computer Science Independent University, Bangladesh Abstract Today the session initiation protocol (SIP) is the predominant protocol for IP Telephony Signaling. The intention of this paper is to present an overview of IP Telephony security issues - both current and future focusing on SIP. We start by presenting some fundamental differences between IP Telephony and the public switched telephone network (PSTN). We then look at specific problems for SIP signaling that arise from these differences. We summarize current activities regarding SIP security, including recent developments in the research community and standardization efforts within the IETF. Finally, the paper gives an outlook on the security issues of IP Telephony. Keywords IP Telephony, Voice over Internet Protocol (VoIP), Session Initiation Protocol (SIP), PSTN, ISP. I. INTRODUCTION This document is a template. An electronic copy can be downloaded from the conference website. For questions on paper guidelines, please contact the conference publications committee as indicated on the conference website. Information about final paper submission is available from the conference website. II. DIFFERENCES BETWEEN IP TELEPHONY AND THE PSTN IP Telephony as it is used today has some fundamental differences compared to speech transmission in the Public Switched Telephone Network (PSTN): In the PSTN, signaling is done in a separate and closed network. With IP Telephony, signaling is done in an open, highly insecure network (e.g. the Internet). Traditional telephones are simple devices with limited functionality. IP Telephony terminals, on the other hand, are complex devices with their own TCP/IP stack. IP Telephony offers mobility: users can change their location and still use the same identity in the network. A IP Telephony -user only needs access to the Internet. By contrast, in the PSTN there is no mobility. Because there is no mobility in the PSTN, authentication is not necessary. Anybody who has physical access to a socket in the wall can use that line. As IP Telephony can be used from anywhere in the Internet, additional authentication must be utilized. III. SIGNALLING WITH SIP The Session Initiation Protocol (SIP) is an Internet Engineering Task Force (IETF) standard designed for initiating, maintaining and terminating interactive communication sessions between users. These sessions may include voice, video, instant messaging, interactive games, and virtual reality. The Session Initiation Protocol (SIP) was specified by the IETF as a standard for signalling and control in multimedia communications over IP [1]. SDP, the Session Description Protocol, is used to select parameters (such as the codec and media type) for the transmission. After a session has been established with SIP, the actual media transfer is transmitted with the Real-time Transport Protocol (RTP). Because SIP is used to set up a session, any secure communication that can be established in a SIP session can further be used to negotiate secrets for a secure RTP stream. Therefore, SIP security is of high importance for IP Telephony security. SIP is a client-server protocol which resembles HTTP. Signaling is based on text messages: A message consists of a header and an optional body. Messages are either requests or responses. If a SIP entity receives a request, it performs the corresponding action and sends back a response to the originator of the request. Responses are threedigit status codes. Table 1 list SIP requests; table 2 lists classes for SIP response codes. SIP Request INVITE BYE ACK OPTIONS CANCEL REGISTER TABLE I SIP REQUESTS Description Initiates a call signalling sequence Terminates a session Acknowledge Queries a server about its capabilities Used to cancel a request in progress Used to register location information at a registrar 40

2 TABLE II SIP RESPONSE CODES SIP Response Codes 1xx informational 2xx ok 3xx redirection 4xx client error 5xx server error 6xx global failure Addressing in SIP is done with Uniform resource Identifiers (URIs). A SIP-URI is similar to an e- mail address and generally of the type sip:user@domain. SIP designates different (logical) entities: user agent, proxy, registrar, redirect server, and location server. A User agent is a terminal participating in SIP communications (this can be hardware or software). A proxy receives messages and forwards them to another SIP entity. A redirect server redirects the sender of the message to another SIP entity instead of forwarding the message. Users can register their current location (i.e. IP-address) with the registrar of their domain. This enables mobility: A location server is used by a registrar to store the location of users (the binding of a SIP-URI with a current IPaddress). The location server provides a directory for other SIP entities to look up the current location for a given SIP-URI. Example: Setting up a Simple Voice Connection with SIP registrar (1) to be able to receive calls. The registrar stores the location information at a location server (2). When user agent A wants to call user agent B, it sends an INVITE-request to its local SIP-proxy (3) which passes on the request (possibly after a DNS lookup) to the proxy of user B s domain (4). The proxy in domain B needs lo look up the IP-address of user agent B at the location server (5, 6) before it can send the request to user agent B (7). The response message for user agent A can take the same route back (8, 9, 10). (A) SIP Security Mechanisms The SIP standard, as specified in RFC 3261 [1], includes several security mechanisms: S/MIME: Because SIP is using MIME for message bodies, S/MIME can be used to send authenticated and encrypted messages between user agents. Digest Authentication: SIP entities sharing a secret (e.g. a password) can authenticate each other with a challenge-response mechanism. To Prevent replay attacks; this challengeresponse authentication includes nonces. TLS & IPSec: Hop-by-hop security for SIP signaling can be achieved either on the transport layer (TLS) or on the network layer (IP sec). In theory, these security mechanisms can make SIP signaling secure. However, they require a pre-call trust relationship or rely on a trust infrastructure (like a public key infrastructure), which all users can use and with one root that all users trust. IV. SIP OPERATION Fig.1 Setting a Phone Call with SIP The establishment of a voice connection between two users is illustrated in Figure_1. In this example, user agent A and B are in different domains and have different proxies. First, the caller (user agent B) needs to register with its local To establish a call, the INVITE request is the most fundamental and important SIP request. The following example of a SIP message exchange between two users, and , shows the basic functions of SIP. Hope it will facilitate the understanding of the procedure of services offered by SIP. In this example, who resides in the domain, wants to call Usually they reside within the same domain, so Dan may use a soft phone (SIP-based) to send an INVITE for sip: @ ( s SIP URL) to a local proxy server, shown in the figure as home.com Proxy Server. 41

3 The INVITE request contains a number of header fields and it might look like this: Origina tor TABLE 3 SIP INVITE REQUEST Switch Term inato r Message INVITE sip: @ 100 Trying INVITE sip: @ Trying ACK sip: @ OK 200 OK ACK sip: @ BYE sip: @ BYE sip: @ : OK 200 OK For INVITE sip: @ details message is look like this: INVITE sip: @ c9d d8754z-;rport Contact: <sip: @ :6256> <sip: @> " "<sip: @>;t ag=015ccc4a Call-ID: BYE, REFER, NOTIFY, MESSAGE, REGISTER, SUBSCRIBE, INFO Content-Type: application/sdp Supported: replaces User-Agent: PortGo v6.8, Build Content-Length: 474 v=0 o= IN IP s= c=in IP t=0 0 m=audio RTP/AVP a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:121 G7221/100 a=rtpmap:100 SPEEX/100 a=rtpmap:9 G722/8000 a=rtpmap:97 ilbc/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=ptime:20 m=video RTP/AVP 34 a=rtpmap:34 H263/90000 a=fmtp:34 CIF=1 QCIF=1 For SIP 100 Trying 100 Trying c9d d8754z- ;received=.35 <sip: @>;tag=015ccc4a <sip: @> 42

4 Contact: For INVITE 6.20 INVITE ;branch=z9hg4bkbd5d53b00d 678 Contact: Content-Type: application/sdp Content-Length: 383 v=0 o=itelswitchplus_ IN IP4 s=sip Session c=in IP4 t=0 0 m=audio 1856 RTP/AVP a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:121 G7221/100 a=rtpmap:100 SPEEX/100 a=rtpmap:9 G722/8000 a=rtpmap:97 ilbc/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: For 100 Trying Trying ;branch=z9hg4bkbd5d53b00d 678;received= <sip: @>;tag=46644 <sip: @6.20> Call-ID: bddbbegekphtwe @ Server: Asterisk PBX BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, timer Contact: <sip: @6.20> For c9d d8754z- ;received=.35 <sip: @>;tag=015ccc4a <sip: @>;tag= Contact: <sip: @> For ;branch=z9hg4bkbd5d53b00d 678;received= <sip: @>;tag=46644 <sip: @6.20>;tag=as41ebef58 Call-ID: bddbbegekphtwe @ Server: Asterisk PBX BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, timer Contact: <sip: @6.20> For ;branch=z9hg4bkbd5d53b00d 678;received= <sip: @>;tag=

5 Call-ID: Server: Asterisk PBX BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, timer Contact: For c9d d8754z- ;received=.35 Contact: For ACK 6.20 ACK ;branch=z9hg4bkbg8d86b00d 681 Contact: CSeq: ACK For 200 OK OK ;branch=z9hg4bkbd5d53b00d 678;received= Call-ID: Server: Asterisk PBX BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, timer Contact: Content-Type: application/sdp Content-Length: 280 v=0 o=root IN IP s=asterisk PBX c=in IP t=0 0 m=audio RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=ptime:20 For 200 OK 200 OK c9d d8754z- ;received=.35 <sip: @>;tag=015ccc4a <sip: @>;tag= Contact: <sip: @> Content-Type: application/sdp Content-Length: 287 v=0 o=itelswitchplus_ IN IP4 s=sip Session c=in IP4 t=0 0 m=audio 1834 RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:

6 a=ptime:20 For ACK ACK :6256;branch=z9hG4bK-d8754zb95fd665be79b d8754z-;rport Contact: ag=015ccc4a Call-ID: CSeq: 1 ACK User-Agent: PortGo v6.8, Build For BYE sip: @ 6.20 BYE sip: @ 6.20;branch=z9hG4bK3249e361;rport <sip: @6.20>;tag=as41ebef58 " " <sip: @>;tag=46644 Call-ID: bddbbegekphtwe @ CSeq: 102 BYE User-Agent: Asterisk PBX X-Asterisk-HangupCause: Normal Clearing X-Asterisk-HangupCauseCode: 16 For BYE sip: @ :6256 BYE sip: @ :6256 ;branch=z9hg4bk-d8754z- b95fd665be79b d8754z- <sip: @>;tag= " " <sip: @>;tag=015ccc4a CSeq: 2 BYE For 200 OK OK 6.20;branch=z9hG4bK3249e361 <sip: @6.20>;tag=as41ebef58 " " <sip: @: 50>;tag=46644 bddbbegekphtwe @ CSeq: 102 BYE For 200 OK 200 OK ;branch=z9hg4bk-d8754z- b95fd665be79b d8754z- Contact: <sip: @ :6256> " "<sip: @>;t ag=015ccc4a <sip: @>;tag= Call-ID: CSeq: 2 BYE User-Agent: PortGo v6.8, Build V. CURRENT SECURITY PROBLEMS FOR SIP SIGNALING By its very definition, VoIP uses IP networks for setting up voice communication. Thus, all threats that are well-known in IP-networks (e.g. denial-ofservice, spoofing, sniffing ) are inherited by VoIP. Furthermore, implementation vulnerabilities (e.g. buffer overflows) are likely because VoIP servers and terminals are complex IP-devices. Specific to SIP are among others - the following threats: Registration/call hijacking Impersonating a SIP-entity 45

7 Tampering with message bodies Tearing down sessions Denial of service Eavesdropping Spam Many activities exist with the goal of making IP Telephony more secure. Within the scope of this paper, it is only possible to list some important challenges and summarize current activities to mitigate these problems. For a more depletive list of threats to VoIP and SIP the reader is referred to [2], [3]. (A) Authentication One of the fundamental problems for SIP security is end-to-end authentication of communication partners in the absence of a universal trust infrastructure2. If the communication partners have a pre-call trust relationship (e.g. via ), S/MIME can be used. Hop-by-Hop solutions (e.g. TLS, IPSec) only work if there is a transitive trust path between sender and receiver of a SIP message. Unlike https, SIP messages via TLS can pass many application layer hops between sender and receiver, and some intermediary entities may not be trustworthy. The following approaches are trying to mitigate authentication problems for SIP/VoIP: ZRTP [4] is a protocol developed by Phil Zimmermann, the inventor of PGP. ZRTP enables a Diffie Hellman key exchange within an RTP stream. This key exchange is protected against man-in-the middle attacks through an authentication string. The user can verify this authentication string with the actual voice of his communication partner. Thus, ZRTP offers authentication of a known communication partner without using any trust infrastructure. RFC 3325 specifies a SIP header in which a proxy of a domain can assert the identity used in a SIP message. However, this assertion is not signed. It can be exchanged between domains that have a TLS connection. In [5], a similar SIP Identity mechanism is suggested. With this approach, a proxy can assert proper authentication of an identity from its domain and sign such an assertion. The SIP community has realized that hop-tohop security offered by TLS is insufficient for authentication in many cases. The goal of [6] is to develop a new way to establish endto-end authentication between user agents with SIP. No more than 3 levels of headings should be used. All headings must be in 10pt font. Every word in a heading must be capitalized except for short minor words as listed in Section III-B. (B) Security of Terminals & Servers Because SIP devices are complex, implementation weaknesses seem unavoidable. Vulnerabilities for SIP implementations are found frequently (e.g. [7]). The following efforts strive to make SIP implementations more secure by fostering SIP black-box testing: RFC 4475 describes various test messages that can be used to torture a SIP implementation. Many simple tools (e.g. [8]) can be used to carry out tests on SIP implementations. An advanced tool to construct sophisticated testcases for SIP is SIPp [9]. SIPp offers the definition of complex and dynamic tests for SIP implementations. (C) Spam over Internet Telephony (SPIT) Though not an issue today, it is estimated that Spam over Internet Telephony (SPIT) will become a problem in the future. First, automatic generation of SIP-based phone calls is feasible and cheap. Second, VoIP Spam will be much more intrusive than Spam is today: A phone will actually ring with each SPIT occurrence (possibly in the middle of the night). VoIP deals with real-time audio signals. Thus, the same countermeasures as for spam may not work for SPIT. (D) Lawful Interception Most countries legally allow for authorized wiretapping of telephone calls by law enforcement agencies, so called Lawful Interception. Depending on the use case and national law, Lawful Interception legislation may apply to VoIP. However, Lawful Interception for VoIP is much harder than in the PSTN due to the following technical facts: The SIP provider and the Internet Service Provider (ISP) may be different. Signaling and payload usually take a different route; traffic is only linked in terminals. The signaling and payload of the conversation may be encrypted. Thus, in order to reliably deploy Lawful Interception for VoIP it would be necessary to a) intercept all SIP traffic and b) intercept the network traffic in real-time of a provider not known prior to call-setup. Several scientists have realized the potential problems of Lawful Interception for VoIP. They have made a proposal arguing that the benefit of Lawful Interception for VoIP may be 46

8 outweighed by the negative consequences for society [10]. VI. CONCLUSION The intention of this paper has been to present an overview of important challenges and current activities on SIP security. Due to many threats, challenges, and the huge amount of work going on, we were only able to give an overview on some important aspects of SIP security. Many problems for IP Telephony security have not yet been solved satisfactorily. SIP is used to initiate IP Telephony communications. Thus, SIP security will remain an active and interesting research area in the near future. REFERENCES [1] J. Rosenberg, H. Schulzrinne et al., SIP: session initiation protocol, RFC 3261, 2002 [2] Voice over IP Security Alliance, VoIP Security and Privacy Threat Taxonomy, Public Release 1.0, Oct [3] Bundesamt für Sicherheit in der Informationstechnik, VOIPSEC Studie, tm [4] P. Zimmermann, A. Johnston, J. Callas, ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP, mann-avt-zrtp-01.html, internet draft, March 2006 [5] J. Peterson, C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress), October [6] V. Gurbani, F. Audet, D. Willis, The SIPSEC Uniform Resource Identifier (URI), internet draft (work in progress), June 2006 [7] Cisco Security Advisory: Multiple Vulnerabilities in Cisco IP Telephones, [8] sipsak homepage, SIP swiss army knife, [9] SIPp, [10] S. Bellovin, M. Blaze, et al., Security Implications of Applying the Communications Assistance to Law Enforcement Act to Voice over IP, pdf [12] SIP Security, Status Quo and Future Issues, Jan Seedorf, ecurity in Distributed Systems (SVS) University of Hamburg, Dept. of Informatics, Vogt- Kölln-Str. 30, D Hamburg, [13] Arkko, J. Torvinen, V. Camarillo, G., Niemi A. and Haukka T. (2003), Security Mechanism Agreement for the Session Initiation Protocol RFC 3329 IETF [14] Cisco Systems Inc., "Overview of the Session Initiation Protocol", oice /sipsols/biggulp/bgsipov.htm#xtocid8, accessed at January, [15] IP telephony protocols, architectures and issues, Raimo Kantola (editor), Helsinki University of Technology Networking Laboratory, Teknillinen Korkeakoulu Tietoverkkolaboratorio Espoo