1 / 27

VoIP Security – More than Encryption and PKI

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.

guy-pruitt
Télécharger la présentation

VoIP Security – More than Encryption and PKI

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

  11. TLS performance

  12. TLS performance

  13. TLS performance

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

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

  16. Privacy policy relationships common policy geopriv-specific presence-specific future RPID CIPID

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

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

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

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

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

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

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

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

  25. Reputation service David Carol has sent IM to has sent email to Frank Emily is this a spammer? Bob Alice

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

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

More Related