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

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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Eric Rescorla
> Sent: Thursday, 31 July 2008 10:31 AM
> To: geopriv@ietf.org
> Subject: [Geopriv] Security Considerations:draft-thomson-geopriv-held-
> measurements-02.txt
> 
> 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
> Geopriv@ietf.org
> https://www.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://www.ietf.org/mailman/listinfo/geopriv