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

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

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.

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

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

Placement of SIP Proxy in the Access Network PSAP / Call Taker LIS (4) Mapping Server (5) Location + Service Identifier PSAP URI (3) Location (6) (1) (2) INVITE urn:service:sos To: urn:service:sos INVITE PSAP URI To: urn:service:sos <PIDF-LO Reference> 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)

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

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

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.

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?

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!