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

Evaluation of Existing Voice over
Download
1 / 32

  • 138 Views
  • Uploaded on
  • Presentation posted in: General

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

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

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.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


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

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: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


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: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


Aib example

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


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: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


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


  • Login