Subject: [Ecrit] [ecrit] #8: Solutions

From: "ecrit issue tracker" <[email-masked]>
Date: Wed, 27 Jul 2011 13:24:32 -0000

#8: Solutions

 The draft currently does not make recommendations. It should.

 Find below some suggestions fro list discussion.

 Martin said:

 The cut and paste attack you refer to, nevertheless, still relies
 on the attacker having some sort of physical presence (themselves or
 from a proxy) at the location to be spoofed. This raises the bar very
 many notches from just being able to “make one up”.

 As we are both saying, this sort of information has major utility
 when it comes to the PSAP being able to apply effective policy to
 the incoming call. Location information would not have to be very
 old before it is considered suspicious or even not acceptable.
 Not that we currently have a specification for signing location –
 unless I missed something. There was a good draft a number of
 years ago that didn’t progress. Currently, to my knowledge,
 all we have is location URI (which is a deferred way to get l
 ocation assurance – with much the same properties as signing anyway).

 I’m interested in just how easily/routinely the IP spoofing
 that is regularly referred to can actually be done. As you
 say, getting yourself in the path between the actual
 location and the ISP doesn’t seem like such an easy thing.

 You’re right on the accountability thing. Also, going back to
 conventional circuit service cellular, there is good evidence
 in the difference in abuse levels related to SIMless phone use
 between places that have good mobile location and those that don’t.

 Bernard said:

 If the PIDF-LO isn't signed, you can just make one up.

 Even if it is signed, for IP address spoofing with HELD, it is possible to
 obtain a PIDF-LO for another IP address if you are on the path from the
 fake source address to the LIS.   Possible, but not easy.

 However, it is not necessary to spoof an IP address to obtain a (signed)
 PIDF-LO that can be (falsely) conveyed.

 You can have someone else obtain the (signed) PIDF-LO and give it to you
 to convey within SIP ('cut and paste'), or you can obtain a PIDF-LO,
 change your location and then convey it later (time-shifting).

 Even if the PIDF-LO is signed, and SIP uses RFC 4474, the 'cut and paste'
 attack still works, if the identity in the PIDF-LO is unlinkable to the
 SIP identity (e.g. From field).

 The time-shifting attack will work as long as the PIDF-LO timestamp is
 within the window checked by the PSAP.

 While the PSAP may not want to necessarily reject the incoming call, there
 is information that can be used in determining the "swatting" potential:

 1. Checking the 'timestamp' field in the PIDF-LO against the SIP timestamp
 or the time at the PSAP;
 2. Checking fields in the PIDF-LO (such as 'contact') against the identity
 in the SIP From: field;
 3. Whether the PIDF-LO is signed;
 4. Checking aspects of the signing certificate (e.g. altSubjectName);
 5. Whether SIP uses RFC 4474;

 As was noted in the discussion, this is not only about 'trustworthy
 location' but also about accountability.
 If attackers feel confident that they will be held accountable (many are
 caught now, after all), they will be less likely to attempt these attacks.

 We have seen this quite often with unauthenticated/unauthorized calling;
 move from no SIM to a registered SIM (albeit with no balance) and voila,
 attacks decline.

 Marc aid:

 I believe the point was that IP address spoofing coupled with a stolen uri
 from the used IP address is location spoofing to a PSAP.

 BTW, current PSTN location mechanisms are in fact LbyR via a recognized
 operator.

 Martin said:

 Regulators wrestle with assumptions about interconnected VoIP providers
 but that's a PSTN hangover and not a basis for long term policy -
 especially relying on something as tenuous as whether such VoIP providers
 only hand out subscriptions to users with identity-verified credit cards.

 John Lange said:

 You would just sign up for, or hack into a VOIP service which allows
 you to set your own outbound caller ID. Or possible a corporate VOIP
 server that is vulnerable.

 Then, just to be on the safe side, use whatever method you can to hide
 your IP address when placing the call, such as a Wifi hotspot or
 similar.

 Hiding your IP address is probably optional because I've not seen much
 interest on the part of the Telco's to track down calls from "fake"
 numbers despite the rampant fraud and nuisance they regularly cause.

 Richard said:

 The only obvious approaches that occur to me are CLI spoofing and lying
 on a VoIP provider's registration form (coincidentally, the same things
 that Wikipedia suggests). But in the case I mention below, they say that
 the call was from "a non-valid number".

 The ECRIT equivalent of CLI spoofing is IP address spoofing
 when the LIS is locating based on IP address). So it might be worth
 referring to BCP 38 somewhere.

 http://www.seattlepi.com/default/article/Teen-who-hacked-California-911
 -system-pleads-1268326.php
 http://www.heraldnet.com/article/20071016/NEWS01/71016015
 http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/
 http://www.fbi.gov/news/stories/2008/february/swatting020408
 http://www.smh.com.au/technology/technology-news/prank-draws-30-police-
 and-swat-to-womans-house-20110726-1hxqm.html

-- 
---------------------------------------+------------------------------------
 Reporter:  Bernard_Aboba@…            |       Owner:  draft-ietf-ecrit-trustworthy-location@…             
     Type:  defect                     |      Status:  new                                                 
 Priority:  major                      |   Milestone:  milestone1                                          
Component:  trustworthy-location       |     Version:  2.0                                                 
 Severity:  Active WG Document         |    Keywords:                                                      
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/ecrit/trac/ticket/8>
ecrit <http://tools.ietf.org/ecrit/>