1 / 14

Protecting First-Level Responder Resources in an IP-based Emergency Services Architecture

Protecting First-Level Responder Resources in an IP-based Emergency Services Architecture. 13 th April 2007,

penha
Télécharger la présentation

Protecting First-Level Responder Resources in an IP-based Emergency Services Architecture

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. Protecting First-Level Responder Resources in anIP-based Emergency Services Architecture 13th April 2007, THE FIRST INTERNATIONAL WORKSHOP ON RESEARCH CHALLENGES IN NEXT GENERATION NETWORKS FOR FIRSTRESPONDERS AND CRITICAL INFRASTRUCTURES’; IN CONJUNCTION WITH IEEE IPCCC 2007, NEW ORLEANS, LOUISIANA, APRIL 11-13. Hannes Tschofenig, Henning Schulzrinne, Murugaraj Shanmugam, Andrew Newton

  2. Scope • Citizen-to-Authority Emergency Services

  3. Threat Models (1) • External adversary model: The target, e.g., an emergency caller whose location is going to be communicated, is honest and the adversary may be located between the target and the location server or between the target and the PSAP. None of the emergency service infrastructure elements act maliciously.

  4. Threat Models (2) • Malicious emergency infrastructure adversary model:The emergency call routing elements, such as the location server, the LoST infrastructure or call routing elements, are malicious.

  5. Threat Models (3) • Malicious target adversary model: The target itself acts maliciously. This adversary model is in the main focus of the subsequent solution approaches.

  6. Overview • The chosen architecture impacts security. • Focus on PSAP resource exhaustion: • Location Spoofing • Call Identity Spoofing

  7. Location SpoofingThreats • Place Shifting: Trudy, the adversary, pretends to be at an arbitrary location. • Time Shifting: Trudy pretends to be at a location she was a while ago. • Location Theft: Trudy observes Alice’s location and replays it as her own. • Location Swapping: Trudy and Malory, located in different locations, can collude and swap location information and pretend to be in each other’s location.

  8. Location SpoofingSolution Approaches • Placement of SIP Proxy in the Access Network • Location by Reference • Location Signing

  9. PSAP / Call Taker Placement of SIP Proxy in the Access Network LIS Mapping Server (5) (4) PSAP URI Location + Service Identifier (3) Location (6) INVITE PSAP URI To: urn:service:sos <PIDF-LO Reference> (1) (2) INVITE urn:service:sos To: urn:service:sos dial dialstring SOS caller SIP proxy • Deployment challenge • Security between SIP Proxy & PSAP: Increased number of proxies => trust problems • Does not help with the identity aspect (unless an IMS like system is used)

  10. (2) Request Location Reference (3) Reference PSAP / Call Taker (4) dial dialstring Location Reference • SIP Proxy does not need to be in the access network • PSAP contacts LIS and authenticates him. • Increased number of LIS => trust problems (8) Dereference LIS (7) INVITE PSAP URI To: urn:service:sos <Reference> INVITE PSAP URI To: urn:service:sos <Reference> SOS caller (6) (5) SIP proxy

  11. (2) Request Signed Location (3) Signed Location PSAP / Call Taker (4) dial dialstring Location Signing • SIP Proxy does not need to be in the access network • PSAP verifies signed location object • Solution technically more challenging LIS INVITE PSAP URI To: urn:service:sos <Reference> INVITE PSAP URI To: urn:service:sos <Reference> SOS caller (6) (5) SIP proxy

  12. Identity Spoofing • Solution to Identity Spoofing: Authenticated Emergency Calls • Authenticated identity useful for Post-Mortem analysis (if the identity can be linked to a real-world entity) • Two types of identities: • Authentication at the ISP/ASP • Authentication at the VSP • Identities can appear in various flavors: • P-Asserted Identity • SIP Identity / SIP SAML • End-to-End Security • Ease of deployment: Provider asserted identity • Does not work nicely with unauthenticated networks* * If unauthenticated also refers to unauthenticated SIP emergency calls rather than plain unauthenticated network access.

  13. Summary

  14. Conclusion • Various solution proposals have been discussed for some time. • Unfortunately, a proper model for evaluation is missing to determine the tradeoff between complexity vs. benefits. • Input from the research community is appreciated. • Join the ECRIT & GEOPRIV mailing list: http://www.ietf.org/html.charters/ecrit-charter.html http://www.ietf.org/html.charters/geopriv-charter.html

More Related