ecrit@ietf.org
[Top] [All Lists]

[Ecrit] Re: [Geopriv] Not-so-grand compromise on how to do endpoint cent

Subject: [Ecrit] Re: [Geopriv] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store
From: Henning Schulzrinne
Date: Sat, 14 Apr 2007 13:55:37 -0400
Given that location information will have to be handed around to back- up PSAPs and first responders, I don't think a public key mechanism works well. After all, with a public key, all possible legitimate recipients would have to share a single private key. This goes against all standard recommendations for designing secure systems. (Since location information may need to reach federal authorities, for example, you may end up with essentially one nationwide private key. Not good.)

I suspect that the desire to hide location information will primarily afflict a few very large incumbent service providers. I don't see why a hotel or enterprise would want to hide the location from their visitors or employees, say, as the likelihood of monetizing this information is zero.

Thus, a simple shared secret between PSAP and the restrictive access provider will probably be sufficient. This still has all kinds of failure possibilities, e.g., if there are backup PSAPs somewhere across the country during a major disaster, but maybe these carriers can check their money making desires during KatrinaBis and turn off the access controls, as there likely won't be too many pizza parlors willing to pay for location information during such times any way.

Henning

On Apr 13, 2007, at 10:45 AM, Hannes Tschofenig wrote:

Hi Alex,

In some sense an encrypted message is very similar to a location-by- reference to the end host -- it is opaque. There is, however, the problem of provisioning the keys to the PSAPs. When we also consider the case of location based applications that are also in scope of GEOPRIV then this approach will obviously not work.

So, the main question therefore is: Do we see a problem with the dereferencing step to resolve the reference to location information? So far, I haven't had the impression. This mechanism would only be justified in cases if there is a network connectivity problem between the Location Recipient and the LIS but not between the Target and the Location Recipient.

Ciao
Hannes

Alexander Mayrhofer wrote:
So, I think Barbara Stark first described this, and it needs some work,
but suppose that, as an option, an access network could supply:

1. A reference to location

2. The results of a LoST query on the location value (viz, PSAP URI and
local dialstring)


Hi,

Without wanting to stir anything up (and, granted, without having
followed the discussion very closely), a third option comes to my mind:

Location-by-value, encrypted by the access network with a public key
corresponding to the desired application of the location data?

eg. for emergency services:

- PSAPs supply a public key for location encryption within their
coverage area (would need to be one key per area, though)
- Access providers serving a certain area would encrypt location
information with that key
- Location information could be decrypted only by the PSAPs which the
corresponding private key

(hence, would be useless for Joe's Pizza Delivery Services, or <insert
favourite name here>'s location advertisement service)

I would definitely like to avoid any overengineering here, though - that
is just a very rough idea i would like to share. Especially for
emergency services though, i am a little scared about information not
readable in case of catastrophic situations (imagining the frustration
of a PSAP agent looking at an encrypted location while handling the
call...)

any comments appreciated (including flames  :).

Alex

_______________________________________________
Geopriv mailing list
Geopriv@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/geopriv




_______________________________________________
Geopriv mailing list
Geopriv@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/geopriv


_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit

<Prev in Thread] Current Thread [Next in Thread>