slide1
Download
Skip this Video
Download Presentation
Evaluation of Existing Voice over Internet Protocol Security Mechanisms &

Loading in 2 Seconds...

play fullscreen
1 / 32

Evaluation of Existing Voice over Internet Protocol Security Mechanisms & - PowerPoint PPT Presentation


  • 170 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Evaluation of Existing Voice over Internet Protocol Security Mechanisms & ' - joben


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

overview
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

basic voip architecture
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

voip calling procedure
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

h 323 protocol stack
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

sip protocol stack
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

sip vs h 323
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

basic sip operation
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

basic sip operation1
Basic SIP Operation

Hakan Evecek and Brett Wilson - UCCS CS691 Spring \'05

example sip invite message
Example SIP INVITE message

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.biloxi.com;branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Alice <sip:[email protected]>

From: Bob <sip:[email protected]>;tag=1928301774

Call-ID: [email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 142

(Bob\'s SDP not shown)

Hakan Evecek and Brett Wilson - UCCS CS691 Spring \'05

basic sip operation cont d
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

voip service issues
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

disclaimers problems
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

disclaimer 4
Disclaimer #4

Hakan Evecek and Brett Wilson - UCCS CS691 Spring \'05

sip issues with network address translation nat traversal
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

solutions for sip nat traversal
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

sip vulnerabilities
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

considerations for securing sip
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

securing sip
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

securing sip cont d
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

aib minimum content
AIB Minimum Content

Content-Type: message/sipfrag

Content-Disposition: aib; handling=optional

From: Alice <sip:[email protected]>

To: Bob <sip:[email protected]>

Contact: <sip:[email protected]>

Date: Thu, 21 Feb 2002 13:02:03 GMT

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Hakan Evecek and Brett Wilson - UCCS CS691 Spring \'05

aib example
AIB Example

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Max-Forwards: 70

Date: Thu, 21 Feb 2002 13:02:03 GMT

Contact: <sip:[email protected]>

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

aib example cont d
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:[email protected]>

To: Bob <sip:[email protected]>

Contact: <sip:[email protected]>

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

securing sip cont d1
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

recommended implementation to secure sip
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

securing the media stream
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

the secure real time transport protocol srtp
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

key management for srtp mikey
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

recommended implementation to secure voip media stream
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

conclusion
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

future research tests
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

references
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

ad