Security: Is the next generation emergency service infrastructure less secure?

1. Security: Is the next generation emergency service infrastructure less secure? 12th April 2007, SDO Emergency Services Workshop 2007 Hannes Tschofenig (moderator)

2. Panel Members • Richard Barnes • James Winterbottom • Stephen Edge • Hannes Tschofenig (moderator)

3. Bio’s • Richard Barnes Richard Barnes received a B.S. in Mathematics and Computer Science from the University of Virginia, and an M.S. in Mathematics the following year. His expertise is in applications of security technologies in a wide variety of areas. Before completing his degrees, he conducted cryptographic research for the U.S. Department of Defense, and since 2005, he has worked on BGP and VoIP security at BBN, a small research and development company. Since a few months before IETF 66 in July 2006, Mr. Barnes has participated in VoIP-relevant working groups in the IETF (especially ECRIT and GEOPRIV), and in the recent RTPSEC discussions. • James Winterbottom James Winterbottom has over 20 years experience in the telecommunications industry. James has had extensive experience in the specification, deployment and support of E911 and value added cellular location systems in the north America and throughout the world. James has been active in the IETF Geopriv and ECRIT working groups for several years and is the co- chair for the VoIP Location Working group in NENA. • Stephen Edge Stephen Edge coordinates Location Services standards at Qualcomm. He is a participant and contributor to location services and emergency call support in ATIS WTSC (former T1P1) and 3GPP since 1998 and to location services and emergency call support in OMA since 2005. • Hannes Tschofenig (moderator) Hannes Tschofenig received a University Diploma in Computer Science from University of Klagenfurt, Austria in 2001. He then joined the Siemens research labs and worked in the corporate technology research labs in Munich until 2006. Starting with April 2007 he is employed as a Senior Research Scientist at Nokia Siemens Networks. His primary research interests are in network security, with a focus on mobile communications. He is chairing the IETF Emergency Context Resolution with Internet Technologies (ecrit), IETF Diameter Maintenance and Extensions (dime) and the IETF Provisioning of Symmetric Keys (keyprov) working groups. He is author/co-author of a number of RFCs and various papers.

4. Overview • Fact: The chosen architecture impacts security. • Focus on PSAP resource exhaustion: • Attacks due to faked location • Attacks due to faked identity

5. Faked Location • Useful for “Real-Time Security Analysis” (ranking under heavy load) • Discussed solutions: • Placement of SIP Proxy in the Access Network • Location by Reference • Location Signing

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

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

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

9. Faked Identity • Useful for Post-Mortem analysis (if the identity can be linked to a real-world entity) • 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.

10. Questions • Do PSAP operators accept an emergency call with signed location but without an authenticated identity? • Do PSAP operators accept an authenticated emergency call without an signed location? • How large is this problem already today with bogus calls? • Via pay phones • Via uninitialized phones / Unauthenticated network access Are statistics available?

11. Is the next generation emergency service infrastructure less secure? Solutions could even provide better security than today’s networks. However, solutions raise a number of questions (particularly with respect to the deployment) There is no free lunch!