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 He then joined the Siemens research labs and worked in the corporate technology research labs in Munich until 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. 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)

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

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

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!