Subject: [Geopriv] Security Considerations: draft-thomson-geopriv-held-measurements-02.txt

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Jul 2008 02:30:58 -0700

So, as I mentioned on Jabber earlier, the premise of the current
LCP is that the Device is identified by IP addr, which is hopefully
somewhat hard to spoof (see previous discussions on that). To
the extent to which the LIS determines location based on information
which is unverifiably provided by the Device then that seems
to have (at least) two implications:

- It potentially allows a Device to lie about its position to 
  others via location information provided by the LIS.
- It potentially allows a Device to find out where other devices
  other than itself if it can determine their measurement info,
  which isn't obviously private otherwise.

The security considerations section appears below in its entirety.
It does not appear to me to address either issue.

   Location-related measurement data are provided by the Device for the
   sole purpose of generating more accurate location information.  The
   LIS SHOULD NOT retain location-related measurement data for any
   longer than is necessary to generate location information.

   A LIS MUST NOT reveal location-related measurement data to any other
   entity unless given explicit permission by the Device.  This document
   does not include any means to indicate such permission.

   A Device is able to explicitly limit the time that a LIS stores
   measurement data by adding an expiry time to the measurement data,
   see Section 4.1.2.

I should note that this isn't just a matter of documenting these
issues. It's not clear to me that there are actually good solutions
for these issues.

-Ekr

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 31 Jul 2008 09:02:30 -0500

Hi Ekr,

I have text on this topic, but I'm not sure why this never made it in.  I'll seek it out and update the draft.  Until that time, I'd like your feedback on the following ideas.  I will put text to this effect into the draft when I get the opportunity.

For the purposes of outright lying, some elements of information can be directly verified by the LIS.  For these pieces of information, the device provides value only by reducing the overall effort expended by the LIS in generating location information.  The LIS is able to authenticate this information by acquiring the information using its own means.  In many cases checking that the information is correct is far less costly than generating it in the first place.  This is certainly true for the scenarios my company has been looking at in the past 18 months.  Even if this is not the case, the LIS can check on random requests and the check can be made parallel to the continuing processing of the request.

The other case is obviously far more interesting.  There are parts of the measurement information that cannot be validated by the LIS are quite clearly open to lying.  However, you need to look at the goals of this draft.  The point is to make available, to the LIS, information that can be used to improve the accuracy of the information that it provides.  We have to assume that the LIS is able to determine the location of the device using some means, however coarse that is.  The impact of a lie on the final result that is produced can be constrained.  If for instance a device lies about its RTT measurements for WiMAX in such a way that the LIS is still able to use them, the result that is produced can be no further from the real location of the device than the uncertainty on the location information that the LIS is able to determine on its own.

With this view in mind, it's easier to understand the impact of the lie.  The LIS is able to take the spoofed measurement information and either check it entirely, or it is able to constrain the impact of the lie.

We have product that implements these mechanisms already in the cellular wireless space.  Our SMLC, SAS and SUPL servers do this for A-GPS.  We use the cell-based location to check the A-GPS location information.  If the A-GPS position differs excessively from the cell-based one we are able to reject (or just log) the result.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eric Rescorla
> Sent: Thursday, 31 July 2008 10:31 AM
> To: [email-masked]
> Subject: [Geopriv] Security Considerations:draft-thomson-geopriv-held-
> measurements-02.txt
> 

------------------------------------------------------------------------------------------------
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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 31 Jul 2008 13:27:21 -0600

"explicit permission by the Device"? Perhaps preferences as explicitly 
stated by the human that owns and uses the device. I would hope that the 
human can opt in or not as to how their location info is shared.

Carl

----- Original Message ----- 
From: "Eric Rescorla" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 31, 2008 3:30 AM
Subject: [Geopriv] Security 
Considerations:draft-thomson-geopriv-held-measurements-02.txt

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Jul 2008 20:00:17 -0700

At Thu, 31 Jul 2008 09:02:30 -0500,
Thomson, Martin wrote:
> For the purposes of outright lying, some elements of information can
> be directly verified by the LIS.  For these pieces of information,
> the device provides value only by reducing the overall effort
> expended by the LIS in generating location information.  The LIS is
> able to authenticate this information by acquiring the information
> using its own means.  In many cases checking that the information is
> correct is far less costly than generating it in the first place.
> This is certainly true for the scenarios my company has been looking
> at in the past 18 months.  Even if this is not the case, the LIS can
> check on random requests and the check can be made parallel to the
> continuing processing of the request.

Hmm... So, say the check comes up mismatched. What then?  Random
checks only works well if it's coupled with some sort of punishment...

> The other case is obviously far more interesting.  There are parts
> of the measurement information that cannot be validated by the LIS
> are quite clearly open to lying.  However, you need to look at the
> goals of this draft.  The point is to make available, to the LIS,
> information that can be used to improve the accuracy of the
> information that it provides.  We have to assume that the LIS is
> able to determine the location of the device using some means,
> however coarse that is.  The impact of a lie on the final result
> that is produced can be constrained.  If for instance a device lies
> about its RTT measurements for WiMAX in such a way that the LIS is
> still able to use them, the result that is produced can be no
> further from the real location of the device than the uncertainty on
> the location information that the LIS is able to determine on its
> own.
> 
> With this view in mind, it's easier to understand the impact of the
> lie.  The LIS is able to take the spoofed measurement information
> and either check it entirely, or it is able to constrain the impact
> of the lie.
> 
> We have product that implements these mechanisms already in the
> cellular wireless space.  Our SMLC, SAS and SUPL servers do this for
> A-GPS.  We use the cell-based location to check the A-GPS location
> information.  If the A-GPS position differs excessively from the
> cell-based one we are able to reject (or just log) the result.

Well, I see your point here, but if the relying party cares
about positions within the margin of error, then lying becomes
serious.

And of course, this doesn't address the privacy issues...

-Ekr

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 1 Aug 2008 02:30:44 -0500

The point on random checks probably needs consideration.

I think that on the point of depending on the more accurate location information, perhaps that is something to be explored in one of the many location trust documents.  I'd be happy to explore it further in here as well.

What do you see as the privacy issues beyond what is already discussed in the draft?

Cheers,
Martin

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Friday, 1 August 2008 4:00 AM
> To: Thomson, Martin
> Cc: Eric Rescorla; [email-masked]
> Subject: Re: [Geopriv] Security Considerations:draft-thomson-geopriv-
> held-measurements-02.txt
>