2. Architectural Considerations for GEOPRIV/ECRIT Presentation given by Hannes Tschofenig

3. Acknowledgements I would like to thank the Geopriv/ECRIT interim meeting participants for their time to discuss the topics presented in this slide set. In particular i would like to thank Henning Schulzrinne, Ted Hardie, Andy Newton, Allison Mankin and Jon Peterson. The interim meeting minutes can be found at: http://www.ietf-ecrit.org/Interim2005/ECRIT-Meeting-Minutes.txt

4. Background A lot of discussions at the Geopriv/ECRIT Interim Meeting (New York, May 2005): Denial of service prevention for Emergency Services Threat: End host lies about location information or replays it. Send emergency personnel to arbitrary place from everywhere in the world. Aspect has architectural relevance

5. Architectural Considerations (1/2) Network driven Approach Determine PSAP extract location+identity+… determine language determine media PSAP Phone 911 Contact PSAP 48° 49' N 2° 29' E  Paris fire department Distributed Directory Query / Response Protocol Fetch Location Assumption: Network intermediary is able to obtain location of end host. SIP Proxy

6. Architectural Considerations (2/2) End-Host driven Approach extract user location+identity+… determine language determine media PSAP Contact PSAP 48° 49' N 2° 29' E  Paris fire department Distributed Directory Query / Response Protocol determine PSAP location Phone Fetch Location

7. Observations Approach (1) requires that the network intermediary knows the end hosts location Some architectures separate between — Network Access Provider, — Internet Service Provider and the — Application Service Provider Application Service Providers often do not have the location of the end host. Location information obtained by an end host via GPS or from the network using DHCP is not cryptographically protected.

8. Denial of Service Threat (1/2) Adversary places an emergency call and attaches the wrong location information. Constraints: — Authentication and authorization for network access or emergency call cannot be mandated. Why to worry since this is already possible in today’s network? Not quite since you can use a public phone but you attach arbitrary location information. Additionally, non-voice calls should be also supported.

9. Goals Determine quality of emergency call in real-time (for ranking) [does not mean that the call is malicious if various security checks cannot be performed] Catch adversary (later; non real-time)

10. How to trace back the adversary? Depends how the adversary placed the emergency call: Authenticate emergency caller to PSAP: — Might require a public key infrastructure — Deployment concerns — Performance concerns Asserted identities: — Works with approach (1) (P-Asserted-ID) and — with approach (2) if you have a separate identity provider (SAML like scheme) IP address: — IP traceback mechanisms

11. How to determine trustworthiness of provided information? Information received by the PSAP should be correct. — At least not intentionally incorrect = modified by adversary. — Entity signing information is held responsible for it. Assumption: — Network access provider / internet service provider signs location information — Easier to setup public key infrastructure for usage between network access provider/ internet service provider and PSAP PSAP performs the following steps when receiving an emergency call: — path validation — digital signature verification — determine degree of trustworthiness into the network access provider and internet service provider Location signing and verifying is not a binary decision (location, signer, etc. plays a role)

12. How to determine trustworthiness of provided information? Challenges (1/2) Signing location information by the network access provider or internet service provider does not directly identify the end host (and the user) With typical network access authentication the user is not known to a visited network provider (although it could potentially be revealed in cooperation with the user’s home network). In some cases even with network access authentication the user cannot be traced back (e.g., pre-paid cards in some countries). Without network access authentication no information about the user is known. If some providers do not support location signing then the benefit it decreased.

13. How to determine trustworthiness of provided information? Challenges (2/2) Replay of signed location information is possible particularly if end hosts cooperate to mount an attack. How to prevent possible replays: — Bind it to the signaling session Easier with approach (1). (e.g., SIP: From, Contact, Date, Call- ID, etc.) — If asserted location is requested before starting the signaling session then replay protection is more difficult. Which field can you use? IP address (might not be reliable source if the end host is behind a NAT) Timestamp

14. Conclusion There are some basic assumptions that require further investigations. We need PSAP operators us to tell what they want! What is more important? — Asserted Location — Authenticated Identity Do you accept an emergency call* with asserted location but without an authenticated identity? Do you accept an authenticated emergency call* without an asserted location? Emergency specific authentication and authorization might be useful (=> new credentials required) * if the PSAP is under denial of service

15. Open Issues Is is sufficient for PSAP to verify that it was signed by a “known” entity? How large is the number of network or internet service providers? — Has an impact on likelyhood of trusting someone’s asserted location. What is the identity that is used in the certificates? (RFC 3770?) Is it possible to get another host’s location being signed? Can a provider be held responsible for something? OR Are network operators and internet service providers excited?