ECRIT WG IETF-75 Trustworthy Location draft-tschofenig-ecrit-trustworthy-location Bernard Aboba Wednesday July 29, 2009 Please join the Jabber room: ecrit@jabber. ietf. org
Some Recent Headlines http: //www. networkworld. com/community/node/24714 http: //www. usdoj. gov/usao/txn/Press. Rel 09/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=LYAo. Pyy. WYj. Q&feature=related The problem of “prank” emergency calls is substantial and quite serious.
Identity and Location l Many (most? ) “swatting” cases involve both identity spoofing and location spoofing. l l On the wired PSTN, caller-ID spoofing effectively enables location spoofing. However, trustworthiness of identity and location are independent issues. Examples: l Emergency calls made over a wireless network providing trusted location but unauthenticated access l l l Experience with unloaded and/or inactive SIM cards in Germany: http: //www. ietf. org/mail-archive/web/ecrit/current/msg 06378. html Situations where location is not available to the PSAP (e. g. Austria)
Additional Issues with VOIP l l 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 Ao. R Additional attack vectors
Threat Models l External attacker l l Malicious infrastructure l l The attacker is located between the end host and the location server or between the end host and the PSAP. The attacker gains control of the emergency call routing elements (the LIS, the Lo. ST infrastructure or call routing elements) Malicious end host l The end host acts maliciously, whether under the control of the owner or not (e. g. acting as a bot).
Location Spoofing Attacks l l l 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 i 2 Requirements for “Trustworthy Location” l Attribution to a Specific Trusted Source l l Section 3. 7: The i 2 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 l l 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 l LLDP-MED endpoint move detection notifications providing data to a LIS implementing HELD. l l l 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 l l l Location signing (Section 5. 1) Location by reference (Section 5. 2) Proxy adding location (Section 5. 3)
Location Signing l From NENA-i 2 Section 3. 7: 1. 2. 3. 4. 5. 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.
Lby. R Dereference Models l Authorization by possession l l l Anyone in possession of the Lby. R can obtain location Incompatible with location hiding Authorization via Access Control Lists (ACLs) l Only those enabled for access can obtain location
Operational Concerns l Credential & ACL management l l Digital timestamping l l l 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 Lby. R credentials? Are LIS operators required to support time synchronization? Is it possible for personnel to reset the clock? Anti-spoofing l What mechanisms need to be put in place to enable “attribution to the LIS”? l What prevents “cutting and pasting” of signed PIDF-LOs or Lby. Rs?
Some Closing Questions l l Is the NENA i 2 notion of “attribution to the LIS” achievable in practice? If not, what is an alternative definition of “trustworthy location”? l l “Auditability after the fact”? Determination of “Prank call” probability with an acceptable rate of false positives?
Feedback?
Скачать презентацию ECRIT WG IETF-75 Trustworthy Location draft-tschofenig-ecrit-trustworthy-location Bernard Aboba
1888ef5b22062dc022fcd546474bfd99.ppt