RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

The only item of substance I see in the below post is the "John Q Public" paragraph. The rest of it is still focussed on the use of signed location in real time by the actual dispatcher as some kind of attack filter - it's not the point, and any filtering that relies on human interaction is too late. Signed location facilitates automatic policy application and identifies the location source for later follow-up to support, among other things, continuous improvement. The very good point raised is effectively "what about these self-locating devices?" The classic example is a device with autonomous GPS and it's as good an example as any. The location dependability requirement from NENA is what led to the "assertion mechanism" being defined for HELD for just this purpose. We don't want to rule out such capabilities since the GPS location may indeed be more accurate than the LIS can determine. A credible scenario for this is a wireless WAN (WiMAX or whatever) that can only do a cell-coverage type location determination where the GPS value is a more precise location within this coverage area. The assertion mechanism permits the device to submit its own opinion of the location as part of the request. The LIS can apply the assertion test and, if it passes, this location is returned as the actual result. If it fails, then the LIS returns its opinion of the location. This provides the simple function of permitting the device to test its own location determination against that provided by the network. However, it becomes especially useful when used in conjunction with a signed location request. Then the result is a signed location either way - and it will be the device determined location or the LIS determined location depending on the result of the assertion test. This has some other nice benefits, such as the fact that the device can do the same thing when it moves to a wired DSL connection, for example, but this time it can get the preferable civic address form when that LIS applies its assertion test. Beyond simple assertion, HELD also has support for more sophisticated device capabilities - via the device capability exchange mechanism. This allows a suitably qualified LIS to, for example, determine that a device supports SUPL and to bootstrap a SUPL session for the exchange of GPS assistance data, and pseudo-range measurements for network hybrid location determination. Cheers, Martin -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, 1 March 2007 5:50 AM To: 'Brian Rosen' Cc: 'GEOPRIV' Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) Brian, As we've discussed previously..... You are correct in that *requesting* a digital signature on location objects will expose the 10 year old with a handheld spoofing their location. But it will not stop the 14 year old miscreant with a Linux machine. One basic fact is the use of signatures will actually attract the miscreant while at the same time stop a dispatch based on the 10 year olds spoofed location. But any dispatcher that has been on the job more than 2 hours will be able to thwart the 10 year old regardless of signatures, while the miscreant will appear trustworthy. What you are doing by accepting calls with and without signatures is exposing part of the call taker's algorithm for detecting suspicious callers. Hence, you are creating a rich(er) attack vector. In addition you are creating machinery that risks classifying legitimate callers as suspicious resulting in a lower grade of service for John Q. Public. "Sorry, Mr. John Q. Public's estate, due to your calling device performing self location determination and our policy of not dispatching to un-signed location objects when busy, even though you were actually at the reported location, we didn't dispatch. Instead our responders were sent to the corner of 1st & Main where there was no emergency, but that call was more trustworthy due to a valid-at-moment signature on the location object." I still claim the call taker (human element) is in the best position to determine suspicious callers and that exposing the algorithm they use in that determination process is nothing more than hanging a sign on the locked door of your house telling all which room your money is stored and how much is there. There is much to be said about security via obscurity. Again, signatures have value, but I still claim they don't deliver what has been promised in this context. Expectations, good and bad, need to align with capabilities and ROI. I've yet to hear the community accept a lower grade of service for the good guys via a very expensive partial solution to thwart the bad guys. -Marc- > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, February 27, 2007 8:01 AM > To: 'Marc Linsner'; 'Dawson, Martin' > Cc: 'GEOPRIV' > Subject: RE: > [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitals > ignatures) > > Marc > > One of the security tenants we live with is that nearly all > security mechanisms can be breached if the attacker is > skilled enough, or spends enough money. The attack I want to > prevent is a script kiddie sending cops on a wild goose > chase. They do this now with pay phones. With VoIP, we make > it MUCH easier to mount this attack. I want to get the cost > of the attack high enough that it takes a major organized > effort costing significant sums. > > Signatures do that. > > It IS possible to spoof ANI today. It's much easier now than > it was even a > couple years ago, which is a problem to the emergency call > system. Until > we "broke" ANI, PSAPs were pretty immune to spoof of location > except from highly organized and well financed groups or very > highly skilled hackers. > With IP endpoints, we have lowered the bar to trivial spoof > far too low. We need to raise it, and signatures will raise > it. We can argue how high the bar gets raised, but without > signatures, pretty much anyone who can program can cause an > emergency call to appear like it comes from anywhere they > want it to. That bar is too low. > > I'm happy to discuss alternate ways to prevent trivial > forgery of location. > I'm not at all happy to drop signatures as a viable way to do > that unless you can show that a trivial attack works in the > presence of a signature requirement. > > It is a fact that PSAPs believe what they are told. > Regardless of what the automatic mechanisms say about > location, they go where the caller tells them to go. > However, they do know how to handle suspicious calls. They > do know how to back track. They know how to send back up > units. Suspicion is something they know how to deal with. > > Brian > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Monday, February 26, 2007 11:20 PM > > To: 'Dawson, Martin' > > Cc: 'GEOPRIV' > > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF- > > LOdigitalsignatures) > > > > Martin, > > > > In-line... > > > > > > > > > > Properly applied signature security means that each call needs to > > > come from a corresponding physical presence in the area > of coverage > > > of the PSAP. > > > > This statement is incorrect. A LO, signed or not, is a stand alone > > piece of data that can be launched from *anywhere*. > > > > -Marc- > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 28 Feb 2007 20:03:07 -0600