VoIP Security – More VoIP Security – More than Encryption and PKIthan Encryption and PKI

Henning Schulzrinne(with Kumar Srivastava, Andrea Forte, Takehiro Kawata, Sangho Shin, Xiaotao

Wu)

Dept. of Computer Science -- Columbia UniversityVoIP Security Workshop

Globecom 2004 -- Dallas, TexasDecember 3, 2004

Evolution of VoIPEvolution of VoIP

“amazing – thephone rings”

“does it docall transfer?”

“how can I make itstop ringing?”

1996-2000 2000-2003 2004-

catching upwith the digital PBX

long-distance calling,ca. 1930 going beyond

the black phone

OverviewOverview Primarily VoIP, but most applies to all real-

time, person-to-person communications IM, presence, event notification will be SIP-focused focused on protocol issues, not why vendors don’t

implement security Why is VoIP different? Basic protocol integrity Infrastructure protection User information privacy Safe service creation Spam, spit and other unsavory things

Why is VoIP (+IM) security Why is VoIP (+IM) security different?different? Hardware end systems with limited resources:

modest stable storage (flash) modest computational capabilities very basic UI (few buttons, small screen) limited interfaces (e.g., no USB)

Communication associations with strangers VPN-style models don’t work Cannot pre-negotiate secrets ACLs don’t work

Mobile users temporary device users session and profile mobility

Privacy implications Emergency calling vs. IM/presence privacy

Security issues: other Security issues: other threatsthreats “bluebugging”

= turn on microphone or camera via virus-inserted remote control

provide user-observable activity indications

phishing impersonate credit card company or bank

power drain attacks protocol or virus e.g., disable sleep mode or “off” button large-scale denial-of-service

A SIP-based security A SIP-based security architecturearchitecture

TLSDigest

authenticationsignaling S/MIME

media S/RTP

identityauthenticatedidentity body

assertedidentity

speaker recognitionface recognition

trust

builds on

conveyed in

controls

domainreputation

personalreputation

socialnetworks

hop-by-hop end-to-end

SIP and securitySIP and security Designed in 1996 modest security emphasis Easy to backfit:

channel security (primarily TLS) end-to-end body protection (initially PGP, now

S/MIME) Proven to be harder and uglier:

end-to-middle security allow inspection by designated proxy

mixture of originator-signed and proxy-modifiable header information

Via and Record-Route vs. To, From, Subject middle-to-end security

signing of middle-inserted information

DOS attack preventionDOS attack prevention

userauthentication

return routability

port filtering (SIP only)address-based rate limiting

UDP: SIPTCP: SYN attack precautions neededSCTP: built-in

Denial-of-service attacks – Denial-of-service attacks – signalingsignaling attack targets:

DNS for mapping SIP proxies SIP end systems at PSAP

types of attacks: amplification only if no

routability check, no TCP, no TLS

state exhaustion no state until return routability established

bandwidth exhaustion no defense except filters for repeats

one defense: big iron & fat pipe

danger of false positives

unclear: number of DOS attacks using spoofed IP addresses mostly for networks not

following RFC 2267 (“Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”)

limit impact of DOS: require return routability built-in mechanism for SIP

(“null authentication”) also provided by TLS allow filtering of attacker

IP addresses (pushback)

TLSTLS End-to-end

security S/MIME but PKI issues proxy inspection

of messages TLS as convenient

alternatives need only server

certificates allows inspection

for 911 services and CALEA

hop-by-hop

home.comDigest

TLS performanceTLS performance

TLS performanceTLS performanceKey Size vs Time taken to initiate, setup and complete a SSL connection

0

200

400

600

800

1000

1200

1400

1600

1800

1024 2048 4096

Key size (bits)

Tim

e (

milliseco

nd

s)

Time taken to send connection request to serverTime taken to accept connection request from clientTime taken to send connection accept to client over network

TLS performanceTLS performanceKey Size Vs Total time taken to set up a SSL connection

0

200

400

600

800

1000

1200

1400

1600

1800

1024 2048 4096

Key Size (Bits)

Tim

e (

Milliseco

nd

s)

Total time taken to setup SSL connection at the client Total time taken to setup SSL connection at the server

GEOPRIV and SIMPLE GEOPRIV and SIMPLE architecturesarchitectures

targetlocationserver

locationrecipient

rulemaker

presentity

caller

presenceagent

watcher

callee

GEOPRIV

SIPpresence

SIPcall

PUBLISHNOTIFY

SUBSCRIBE

INVITE

publicationinterface

notificationinterface

XCAP(rules)

INVITE

DHCP

PrivacyPrivacy All presence data,

particularly location, is highly sensitive

Basic location object (PIDF-LO) describes

distribution (binary) retention duration

Policy rules for more detailed access control

who can subscribe to my presence

who can see what when

<tuple id="sg89ae">

<status>

<gp:geopriv>

<gp:location-info>

<gml:location>

<gml:Point gml:id="point1“

srsName="epsg:4326">

<gml:coordinates>37:46:30N 122:25:10W

</gml:coordinates>

</gml:Point>

</gml:location>

</gp:location-info>

<gp:usage-rules>

<gp:retransmission-allowed>no

</gp:retransmission-allowed>

<gp:retention-expiry>2003-06-23T04:57:29Z

</gp:retention-expiry>

</gp:usage-rules>

</gp:geopriv>

</status>

<timestamp>2003-06-22T20:57:29Z</timestamp>

</tuple>

Privacy policy Privacy policy relationshipsrelationships

geopriv-specific presence-specific

common policy

RPID CIPID

future

Privacy rulesPrivacy rules Conditions

identity, sphere, validity

time of day current location identity as <uri> or

<domain> + <except>

Actions watcher confirmation

Transformations include information reduced accuracy

User gets maximum of permissions across all matching rules

Extendable to new presence data rich presence biological sensors mood sensors

Location-based securityLocation-based security In real life, physical proximity

grants privileges we don’t require passwords

for light switches and video projectors

Extend notion to local multimedia resources

e.g., networked cameras and displays

Examples: SkinPlex – touch and convey

RFID-like identifier display changing access

code on display background sound – have

device play back sound

1942

Service creationService creation

programmer, carrier

end user

network servers

SIP servlets, sip-cgi

CPL

end system VoiceXML VoiceXML (voice),LESS

Tailor a shared infrastructure to individual users traditionally, only vendors (and sometimes carriers) learn from web models

LESS: simplicityLESS: simplicity Generality (few and simple concepts) Uniformity (few and simple rules)

Trigger rule Switch rule Action rule Modifier rule

Familiarity (easy for user to understand)

Analyzability (simple to analyze)

switchestrigger actions

modifiers

LESS: SafetyLESS: Safety Type safety

Strong typing in XML schema Static type checking

Control flow safety No loop and recursion One trigger appear only once, no feature interaction for a

defined script Memory access

No direct memory access LESS engine safety

Ensure safe resource usage Easy safety checking

Any valid LESS scripts can be converted into graphical representation of decision trees.

LESS snapshotLESS snapshot<less> <incoming> <address-switch> <address is=“sip:myboss@abc.com"> <device:turnoff device=“sip:stereo_room1@abc.com”/> <media media=“audio”> <accept/> </media> </address> </address-switch> </incoming></less>

incoming call

If the call from my boss

Turn off the stereo

Accept the call with only audio

trigger, switch, modifier, action

SIP unsolicited calls and SIP unsolicited calls and messagesmessages

Possibly at least as large a problem

more annoying (ring, pop-up)

Bayesian content filtering unlikely to work

identity-based filtering

PKI for every user unrealistic

Spammers will use throw-away addresses

Use two-stage authentication

SIP identity work

home.comDigest

mutualPK authentication (TLS)

Domain ClassificationDomain Classification Classification of domains based on their identity instantiation and

maintenance procedures plus other domain policies. Admission controlled domains

Strict identity instantiation with long term relationships Example: Employees, students, bank customers

Bonded domains Membership possible only through posting of bonds tied to a expected

behavior Membership domains

No personal verification of new members but verifiable identification required such as a valid credit card and/or payment

Example: E-bay, phone and data carriers Open domains

No limit or background check on identity creation and usage Example: Hotmail

Open, rate limited domains Open but limits the number of messages per time unit and prevents account

creation by bots Example: Yahoo

Reputation serviceReputation service

Alice Bob

CarolDavid

Emily Frank

has sentemail to

has sentIM to

is this a spammer?

What else is left?What else is left? A random selection Higher-level service creation in end

systems The role of intermediaries

session-border controllers end-to-middle security session policies

Conferencing IETF XCON WG struggling with model and

complexity Application sharing (~ remote access)

pixel-based semantically-based

ConclusionConclusion VoIP security is a systems problem, not

a protocol problem Standardized solutions for basic security

requirements available but deployment lagging

Emerging two-level identity assertion may be applicable to email and other

systems as well In progress: integration with SAML,

federated identity management