ECRIT WG IETF-75 Trustworthy Location Bernard Aboba draft-tschofenig-ecrit-trustworthy-location Bernard Aboba Wednesday July 29, 2009 Please join the Jabber room: ecrit@jabber.ietf.org

Some Recent Headlines The problem of “prank” emergency calls is http://www.networkworld.com/community/node/24714 http://www.usdoj.gov/usao/txn/PressRel09/weigman_swat_ple_pr.html http://www.pcworld.com/article/138591/couple_swarmed_by_swat_team_after_911_hack.html http://www.wired.com/threatlevel/2008/04/judge-throws-th/#previouspost http://www.youtube.com/watch?v=LYAoPyyWYjQ&feature=related The problem of “prank” emergency calls is substantial and quite serious.

Identity and Location Many (most?) “swatting” cases involve both identity spoofing and location spoofing. On the wired PSTN, caller-ID spoofing effectively enables location spoofing. However, trustworthiness of identity and location are independent issues. Examples: Emergency calls made over a wireless network providing trusted location but unauthenticated access Experience with unloaded and/or inactive SIM cards in Germany: http://www.ietf.org/mail-archive/web/ecrit/current/msg06378.html Situations where location is not available to the PSAP (e.g. Austria)

Additional Issues with VOIP Potential for authentication at multiple layers (link layer, voice) Popularity of anonymous/unauthenticated access (e.g. hot spots) Lack of relationship between link/network layer identity (e.g. IP addr, MAC addr, NAI) and SIP AoR Additional attack vectors

Threat Models External attacker Malicious infrastructure The attacker is located between the end host and the location server or between the end host and the PSAP. Malicious infrastructure The attacker gains control of the emergency call routing elements (the LIS, the LoST infrastructure or call routing elements) Malicious end host The end host acts maliciously, whether under the control of the owner or not (e.g. acting as a bot).

Location Spoofing Attacks Place shifting: the attacker claims to be at a location (either inside or outside the uncertainty band) that is significantly different from their own. Time shifting: the attacker claims to currently be at a previously visited location. Location theft: the attacker claims someone else’s location as their own. This can include collusion (e.g. location swapping).

NENA i2 Requirements for “Trustworthy Location” Attribution to a Specific Trusted Source Section 3.7: The i2 solution proposes a Location Information Server (LIS) be the source for distributing location information within an access network. Furthermore the validity, integrity and authenticity of this information are directly attributed to the LIS operator. Implications Where location depends on information contributed by parties trusted by neither the access, voice or LIS operator, this condition cannot be met. Trustworthiness is a property of a system, not a protocol.

Example LLDP-MED endpoint move detection notifications providing data to a LIS implementing HELD. Location data based on client LLDP announcements, not source IP or MAC addresses. Enables an end-run around return reachability PIDF-LO (even when signed!) cannot provide “trustworthy location” since location is attributable to the client, not the LIS!

Potential Solutions Location signing (Section 5.1) Location by reference (Section 5.2) Proxy adding location (Section 5.3)

Location Signing From NENA-i2 Section 3.7: The location object should be digitally signed. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose, VPC and ERDB operators should issue certs to LIS operators. The signature should include a timestamp. Where possible, the Location Object should be refreshed periodically, with the signature (and thus the timestamp) being refreshed as a consequence. Antispoofing mechanisms should be applied to the Location Reporting method.

LbyR Dereference Models Authorization by possession Anyone in possession of the LbyR can obtain location Incompatible with location hiding Authorization via Access Control Lists (ACLs) Only those enabled for access can obtain location

Operational Concerns Credential & ACL management Digital timestamping Are VPC and ERDB operators prepared to operate as Certificate Authorities? What are the pre-requisites for certificate issuance? How do PSAPs manage ACLs and LbyR credentials? Digital timestamping Are LIS operators required to support time synchronization? Is it possible for personnel to reset the clock? Anti-spoofing What mechanisms need to be put in place to enable “attribution to the LIS”? What prevents “cutting and pasting” of signed PIDF-LOs or LbyRs?

Some Closing Questions Is the NENA i2 notion of “attribution to the LIS” achievable in practice? If not, what is an alternative definition of “trustworthy location”? “Auditability after the fact”? Determination of “Prank call” probability with an acceptable rate of false positives?

Feedback?