Evaluation of Existing Voice over Internet Protocol Security

Download Report

Transcript Evaluation of Existing Voice over Internet Protocol Security

Evaluation of Existing Voice over
Internet Protocol Security Mechanisms
&
A Recommended Implementation
for a SIP-based VoIP Phone
Brett Wilson
Hakan Evecek
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
1
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
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
2
Basic VoIP Architecture

End Users


Network Components



5/3/05
VoIP handsets, conferencing units, mobile units, PC
softphones
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
3
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


5/3/05
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
4
H.323 Protocol Stack
Audio
Application
Terminal Control & Management
Voice Codec
G.711, 723,
729, etc.
RTCP
RTP
H.225
RAS
H.225
Call
Signaling
H.245
TCP
UDP
IP
Link & Physical Layer
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
5
SIP Protocol Stack
Audio
Application
Terminal Control & Management
Voice Codec
G.711, 723,
729, etc.
RTCP
SIP
SDP
RTP
TCP
UDP
IP
Link & Physical Layer
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
6
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
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
7
Basic SIP Operation

Bob wants to place a call to Alice





5/3/05
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
8
Basic SIP Operation
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
9
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)
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
10
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
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
11
VoIP Service Issues

QoS


Can packet-switched networks provide the same reliability/voice
quality as the PSTN?
 Latency, jitter, echo
Security



5/3/05
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
12
Disclaimers & Problems




5/3/05
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
13
Disclaimer #4
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
14
SIP Issues with Network Address
Translation (NAT) traversal

NAT presents major difficulties



5/3/05
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
15
Solutions for SIP NAT traversal

Application Layer Gateways/MIDCOM



New “Translate” SIP header



Allow control of NAT IP/port assignments
Con - Someone at home can’t control ISP’s NAT
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
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
16

Registration


End-to-End security
 Prevent attackers from interfering with call setup
negotiation
Session security



Prevent attacker from impersonating a valid registration
server
Protecting SIP message bodies


Prevent unauthorized registration modification
Impersonation of Registration Server


SIP vulnerabilities
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
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
17
Considerations for securing SIP

Entire SIP message can not be encrypted endto-end


SIP transport mechanisms are specified on a
hop-by-hop basis


SIP relies on proxies to modify/insert header fields
User has no control over how proxy server relays
request
Firewalls/NATs present major challenges
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
18
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

5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
19
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

5/3/05
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
20
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
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
21
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
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
22
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-5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
23
Securing SIP, cont’d

SIP Authenticated Identity Management

5/3/05
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
24
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
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
25
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
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
26
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.
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
27
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 wayhandshakes. 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.
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
28
Recommended Implementation to
Secure VoIP Media Stream
 Support
for SRTP
 AES – Counter Mode Encryption
 Support for MIKEY
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
29
Conclusion

VoIP security is complex




Technologies are in place to secure VoIP



Numerous protocols
NAT/firewall traversal issues
QoS issues
Solutions we’ve discussed
However, no “standard” approach is being used
Current VoIP providers do not secure calls


5/3/05
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
30
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.
5/3/05
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
31
References










5/3/05
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 2004 RFC 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 RealTime 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
Hakan Evecek and Brett Wilson - UCCS
CS691 Spring '05
32