270 likes | 403 Views
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.
E N D
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 “does it do call transfer?” going beyond the black phone “amazing – the phone rings” catching up with the digital PBX 1996-2000 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: • 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 threats • “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 architecture hop-by-hop end-to-end domain reputation social networks personal reputation trust builds on authenticated identity body asserted identity speaker recognition face recognition identity conveyed in TLS Digest authentication S/MIME signaling controls S/RTP media
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 • 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 prevention port filtering (SIP only) address-based rate limiting return routability user authentication UDP: SIP TCP: SYN attack precautions needed SCTP: built-in
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) Denial-of-service attacks – signaling
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 home.com Digest
GEOPRIV and SIMPLE architectures rule maker DHCP XCAP (rules) target location server location recipient notification interface publication interface GEOPRIV SUBSCRIBE presentity presence agent watcher SIP presence PUBLISH NOTIFY caller callee SIP call INVITE INVITE
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 future RPID CIPID
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 Privacy rules
Location-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 creation • Tailor a shared infrastructure to individual users • traditionally, only vendors (and sometimes carriers) • learn from web models
LESS: 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) modifiers trigger switches actions
LESS: 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 snapshot incoming call <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> If the call from my boss Turn off the stereo Accept the call with only audio trigger, switch, modifier, action
SIP unsolicited calls and messages • 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 mutual PK authentication (TLS) home.com Digest
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 • 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 service David Carol has sent IM to has sent email to Frank Emily is this a spammer? Bob Alice
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 • 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