VoIP Security – More than
Encryption and PKI
Henning Schulzrinne
(with Kumar Srivastava, Andrea Forte, Takehiro Kawata, Sangho Shin, Xiaotao Wu)
Dept. of Computer Science -- Columbia University
VoIP Security Workshop
Globecom 2004 -- Dallas, Texas
December 3, 2004
Evolution of VoIP
“how can I make it
stop ringing?”
long-distance calling,
ca. 1930
“amazing – the
phone rings”
1996-2000
“does it do
call transfer?”
going beyond
the black phone
catching up
with the digital PBX
2000-2003
2004-
Overview

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
different?

Hardware end systems with limited resources:





Communication associations with strangers




VPN-style models don’t work
Cannot pre-negotiate secrets
ACLs don’t work
Mobile users



modest stable storage (flash)
modest computational capabilities
very basic UI (few buttons, small screen)
limited interfaces (e.g., no USB)
temporary device users
session and profile mobility
Privacy implications

Emergency calling vs. IM/presence privacy
Security issues: other threats

“bluebugging”



phishing


= turn on microphone or camera via virus-inserted
remote control
 provide user-observable activity indications
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 architecture
hop-by-hop
trust
end-to-end
domain
reputation
social
networks
personal
reputation
authenticated
identity body
asserted
identity
speaker recognition
face recognition
TLS
Digest
authentication
S/MIME
builds on
identity
conveyed in
signaling
controls
media
S/RTP
SIP 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


mixture of originator-signed and proxy-modifiable header
information


allow inspection by designated proxy
Via and Record-Route vs. To, From, Subject
middle-to-end security

signing of middle-inserted information
DOS attack prevention
port filtering (SIP only)
address-based rate limiting
return routability
user
authentication
UDP: SIP
TCP: SYN attack precautions needed
SCTP: built-in
Denial-of-service attacks –
signaling

attack targets:







DNS for mapping
SIP proxies
SIP end systems at PSAP
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

types of attacks:




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)
TLS

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
Digest
home.com
TLS performance
TLS performance
Key Size vs Time taken to initiate, setup and complete a SSL connection
1800
1600
Time (milliseconds)
1400
1200
1000
800
600
400
200
0
1024
2048
4096
Key siz e ( b it s)
Time taken to send connection request to server
Time taken to accept connection request from client
Time taken to send connection accept to client over network
TLS performance
Key Size Vs Total time taken to set up a SSL connection
1800
1600
1400
Time (Milliseconds)
1200
1000
800
600
400
200
0
1024
2048
4096
Key Size (Bits)
Total time taken to setup SSL connection at the client
Total time taken to setup SSL connection at the server
GEOPRIV and SIMPLE
architectures
rule
maker
DHCP
XCAP
(rules)
target
presentity
caller
publication
interface
PUBLISH
INVITE
location
server
presence
agent
notification
interface
location
recipient
GEOPRIV
watcher
SIP
presence
SUBSCRIBE
NOTIFY
INVITE
callee
SIP
call
Privacy


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 relationships
common policy
geopriv-specific
presence-specific
RPID
future
CIPID
Privacy rules

Conditions





Actions


identity, sphere, validity
time of day
current location
identity as <uri> or
<domain> + <except>
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 security

In real life, physical proximity
grants privileges


Extend notion to local multimedia
resources


we don’t require passwords for
light switches and video
projectors
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 creation



Tailor a shared infrastructure to individual users
traditionally, only vendors (and sometimes carriers)
learn from web models
end user
network
servers
programmer,
carrier
SIP servlets,
sip-cgi
end system
VoiceXML
VoiceXML (voice),
LESS
CPL
LESS: simplicity


Generality (few and simple concepts)
Uniformity (few and simple rules)






Trigger rule
Switch rule
Action rule
Modifier rule
modifiers
trigger
switches
actions
Familiarity (easy for user to understand)
Analyzability (simple to analyze)
LESS: Safety

Type safety



Control flow safety



No direct memory access
LESS engine safety


No loop and recursion
One trigger appear only once, no feature interaction for a defined
script
Memory access


Strong typing in XML schema
Static type checking
Ensure safe resource usage
Easy safety checking

Any valid LESS scripts can be converted into graphical
representation of decision trees.
LESS snapshot
incoming call
<less>
If the call from my boss
<incoming>
<address-switch>
<address is=“sip:[email protected]">
Turn off the stereo
<device:turnoff
device=“sip:[email protected]”/>
<media media=“audio”>
<accept/>
Accept the call with only audio
</media>
</address>
</address-switch>
</incoming>
</less>
trigger, switch, modifier, action
SIP unsolicited calls and
messages

Possibly at least as large a
problem






more annoying (ring, popup)
Bayesian content filtering
unlikely to work
 identity-based filtering
PKI for every user
unrealistic
Spammers will use throwaway addresses
Use two-stage
authentication

mutual
PK authentication (TLS)
SIP identity work
Digest
home.com
Domain 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


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: Employees, students, bank customers
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 service
Carol
has sent
IM to
David
has sent
email to
Emily
Frank
is this a spammer?
Alice
Bob
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
Conclusion


VoIP security is a systems problem, not a
protocol problem
Standardized solutions for basic security
requirements available


Emerging two-level identity assertion


but deployment lagging
may be applicable to email and other systems as
well
In progress: integration with SAML, federated
identity management