1 / 32

Evaluation of Existing Voice over Internet Protocol Security Mechanisms &

Evaluation of Existing Voice over Internet Protocol Security Mechanisms & A Recommended Implementation for a SIP-based VoIP Phone Brett Wilson Hakan Evecek. Overview. Basic Voice Over IP (VoIP) Architecture Basic VoIP Calling Procedure VoIP Service Issues

joben
Download Presentation

Evaluation of Existing Voice over Internet Protocol Security Mechanisms &

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Evaluation of Existing Voice over Internet Protocol Security Mechanisms & A Recommended Implementation for a SIP-based VoIP Phone Brett Wilson Hakan Evecek Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  2. Overview • Basic Voice Over IP (VoIP) Architecture • Basic VoIP Calling Procedure • VoIP Service Issues • Call Setup and Management Security • Session Initiation Protocol (SIP) Overview • SIP Security Mechanisms • Recommended minimum implementation to protect SIP call setup/management • Media Stream Security • Secure Real Time Protocol (SRTP), Multimedia Internet Keying (MIKEY) • Recommended minimum implementation to protect media stream Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  3. Basic VoIP Architecture • End Users • VoIP handsets, conferencing units, mobile units, PC softphones • Network Components • Network Protocols • Public Switched Telephone Network (PSTN) gateways provide access to non-VoIP phones • Call managers, routers, Network Address Translations (NATs), firewalls, gateways • SIP Proxies/H.323 Gatekeepers Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  4. VoIP Calling Procedure • Call setup/maintenance • H.323 or SIP used as the signaling protocol • Both are commonly used to establish contact and negotiate the media stream connection and details • SIP is newer and has several advantages over H.323 • Media connection • After calling session has been created a media connection is created for exchanging media packets • A separate connection/protocol • RTP is common Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  5. H.323 Protocol Stack Terminal Control & Management Audio Application Voice Codec G.711, 723, 729, etc. RTCP H.225RAS H.225 Call Signaling H.245 RTP TCP UDP IP Link & Physical Layer Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  6. SIP Protocol Stack Terminal Control & Management Audio Application Voice Codec G.711, 723, 729, etc. RTCP SIP SDP RTP TCP UDP IP Link & Physical Layer Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  7. SIP vs H.323 • Distinct advantages to both protocols • SIP • Many recent comparisons regard SIP as the future for VoIP • However, H.323 use will continue due to existing implementations and its advantages • Currently receiving most attention from researchers and the VoIP implementers • Our research focused on SIP Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  8. Basic SIP Operation • Bob wants to place a call to Alice • Bob sends INVITE msg to Alice through his SIP proxy server • May require authentication to the proxy • Bob’s proxy server relays request to Alice’s proxy server • Bob’s proxy finds Alice’s proxy using DNS • Alice’s proxy server relays request to Alice’s location • Alice’s location is known only if she “registers” her location with her proxy • Typically done by the user agent on a periodic basis • Alice replies with OK msg to Bob back through the proxies • Bob sends Alice an ACK directly to his location Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  9. Basic SIP Operation Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  10. Example SIP INVITE message INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.biloxi.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Alice <sip:alice@atlanta.com> From: Bob <sip:bob@biloxi.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.biloxi.com CSeq: 314159 INVITE Contact: <sip:bob@pc33.biloxi.com> Content-Type: application/sdp Content-Length: 142 (Bob's SDP not shown) Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  11. Basic SIP Operation, cont’d • SIP does not establish media connection parameters • SIP body typically contains Session Description Protocol (SDP) used to negotiate media parameters • After call is established, SIP can be used to modify call (add more participants, etc) and to end the call Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  12. VoIP Service Issues • QoS • Can packet-switched networks provide the same reliability/voice quality as the PSTN? • Latency, jitter, echo • Security • Confidentiality • Concealing signaling details as well as media streams • Integrity • Ensuring message content is unaltered • Providing a way to determine/authenticate message origin • Availability • Preventing denial or disruption of service Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  13. Disclaimers & Problems • Protocol security is only a piece of the big picture security of a system may always be compromised by naïve implementation or administration. • Security of a single protocol does not help all participating protocols have to be made secure. • Physical security counts as well. • Security protocols cannot solve social layer issues. Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  14. Disclaimer #4 Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  15. SIP Issues with Network Address Translation (NAT) traversal • NAT presents major difficulties • How to accurately register oneself from inside NAT? • Only know local private IP • How to receive incoming calls? • Proxy only knows public IPs of NAT • How to set up public NAT IP/ports for negotiated media stream? • Real Time Protocol (RTP)/RTCP require sequential ports Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  16. Solutions for SIP NAT traversal • Application Layer Gateways/MIDCOM • Allow control of NAT IP/port assignments • Con - Someone at home can’t control ISP’s NAT • New “Translate” SIP header • Requires registration server to associate translated IP/port with given contact name • Registration connection must be maintained • Use of Simple Traversal of User Datagram Protocol (STUN)/Traversal Using Relay NAT (TURN) • STUN allows NAT discovery/type determination and public IP/port assignments • TURN allows external connection requests to reach application behind NAT • Acts as relay server between external and internal hosts Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  17. SIP vulnerabilities • Registration • Prevent unauthorized registration modification • Impersonation of Registration Server • Prevent attacker from impersonating a valid registration server • Protecting SIP message bodies • End-to-End security • Prevent attackers from interfering with call setup negotiation • Session security • Ensuring attackers can not alter sessions • Protecting SIP headers • Denial of Service • Protect against numerous attack strategies that can generate large volume of SIP msgs at target host Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  18. Considerations for securing SIP • Entire SIP message can not be encrypted end-to-end • SIP relies on proxies to modify/insert header fields • SIP transport mechanisms are specified on a hop-by-hop basis • User has no control over how proxy server relays request • Firewalls/NATs present major challenges Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  19. Securing SIP • HTTP Authentication • Digest authentication allows for one-way authentication and replay-attack prevention • Network/Transport Layer • IPSec • Can provide hop-by-hop security for UDP, TCP SCTP • An IPsec profile detailing protocols/mechanisms for securing SIP would be needed • Key management issues • TLS • Can not be applied to UDP-based SIP (only TCP or other reliable transport protocol) • Applied hop-by-hop • All SIP proxies required to implement Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  20. Securing SIP, cont’d • S/MIME • Use for public key distribution, authentication, integrity, and confidentiality of SIP signaling data • Protect SIP header fields through tunneling entire SIP message as an S/MIME body • SIP Authenticated Identity Body • Basically same as S/MIME tunneling, but instead of “tunneling” the entire message, only a specific subset of headers are signed Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  21. AIB Minimum Content Content-Type: message/sipfrag Content-Disposition: aib; handling=optional From: Alice <sip:alice@example.com> To: Bob <sip:bob@example.net> Contact: <sip:alice@pc33.example.com> Date: Thu, 21 Feb 2002 13:02:03 GMT Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  22. AIB Example INVITE sip:bob@example.net SIP/2.0 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@example.net> From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.example.com> Content-Type: multipart/mixed; boundary=unique-boundary-1 --unique-boundary-1 Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 example.com s=Session SDP c=IN IP4 pc33.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  23. AIB Example, cont’d --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-Length: 608 --boundary42 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional From: Alice <sip:alice@example.com> To: Bob <sip:bob@example.net> Contact: <sip:alice@pc33.example.com> Date: Thu, 21 Feb 2002 13:02:03 GMT Call-ID: a84b4c76e66710 CSeq: 314159 INVITE --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- --unique-boundary-1-- Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  24. Securing SIP, cont’d • SIP Authenticated Identity Management • Proposes that each SIP proxy provide authentication services and then sign such authentication with a trusted certificate • Insert into new “Identity” header • Addresses the fact that most end users don’t have their own certificate • “Signs” the assertion that the user in the “from” field has the authority to use that Address of Record Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  25. Recommended Implementation to Secure SIP • Ability to establish and maintain a TLS connection for registration and requests • Provides complete confidentiality, authenticity, integrity • Ability to respond to digest authentication challenges • Authenticate with proxy for registration/service • Ability to use AIB to protect SIP body and headers • In absence of TLS anywhere along route will still provide authentication and integrity of original SIP request • Ability to handle receipt of an AIB payload and correctly deduce whether security violations have occurred in transit • Must be able to determine whether changes in SIP headers are legitimate (due to intermediaries) or represent a security breach Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  26. Securing the Media Stream • Encryption of media content • May take place either at IP or RTP layer • Performance overhead considerable • New established solutions for keying – Multimedia Internet Keying (MIKEY) protocol Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  27. The Secure Real – Time Transport Protocol (SRTP) The security goals for SRTP are to ensure: · The confidentiality of the RTP and RTCP payloads, · The integrity of the entire RTP and RTCP packets, together with protection against replayed packets. Goals for the protocol are:    • A framework that permits upgrading with new cryptographic transforms, A low computational cost,        • Low bandwidth cost, a framework preserving RTP header compression efficiency, and, asserted by the pre-defined transforms, A small footprint (i.e., small code size and data memory for keying information and replay lists), • Independence from the underlying transport, network, and physical layers used by RTP, in particular high tolerance to packet loss and re-ordering. Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  28. Key Management for SRTP – MIKEY • A key management scheme that addresses real-time multimedia scenarios (e.g. SIP calls and RTSP sessions, streaming, unicast, groups, multicast). • MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1 MIKEY defines three options for the user authentication and negotiation of the master keys all as 2 way-handshakes. They are: • Symmetric key distribution (pre-shared keys, MAC for integrity protection·        • Asymmetric key distribution public keys • Diffie-Hellman key agreement protected by digital signatures; needs a certificate like in the public key case. Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  29. Recommended Implementation to Secure VoIP Media Stream • Support for SRTP • AES – Counter Mode Encryption • Support for MIKEY Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  30. Conclusion • VoIP security is complex • Numerous protocols • NAT/firewall traversal issues • QoS issues • Technologies are in place to secure VoIP • Solutions we’ve discussed • However, no “standard” approach is being used • Current VoIP providers do not secure calls • http://www.vonage.com/help_knowledgeBase_article.php?article=841 • Searches of AT&T and Earthlink turned up no info on secure VoIP Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  31. Evaluate the effects of the recommended security systems on different VoIP platforms. PC-to-Phone or PC-to-PC quality testing with security measures setup. Evaluate new mechanisms for Firewall/NAT problems. How Advanced Services (transfer,conferencing, instant messaging) are affected with these security parameters. Future Research/Tests Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

  32. Dorgham Sisalem, Jiri Kuthan: Understanding SIP D. Richard Kuhn, Thomas J. Walsh, Steffen Fries: Security Considerations for Voice Over IP Systems Daniel Collins: Carrier Grade Voice over IP, 2002 Using AES Counter Mode With IPsec ESP, Jan 2004RFC 3686 M. Baugher [Cisco Systems, Inc.], D. McGrew [Cisco Systems, Inc.], M. Naslund [Ericsson Research], E. Carrara [Ericsson Research], K. Norrman [Ericsson Research],The Secure Real-Time Transport Protocol (SRTP) Tim Greene, Phil Hochmuth, VoIP security a Moving Target Colin Perkins: RTP Audio and Video for Internet, 2003 RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol (SIP) http://www.ietf.org/rfc/rfc3686.txt?number=3686 RFC 3893, SIP Authenticated Identity Body (AIB) Format, http://www.ietf.org/rfc/rfc3686.txt?number=3686 Useful links: VoIP-WLAN-QoS Useful Links References Hakan Evecek and Brett Wilson - UCCS CS691 Spring '05

More Related