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

"Thomson, Martin" <Martin.Thomson@andrew.com> Fri, 01 August 2008 07:30 UTC

Return-Path: <geopriv-bounces@ietf.org>
X-Original-To: geopriv-archive@megatron.ietf.org
Delivered-To: ietfarch-geopriv-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9433A6ABC; Fri, 1 Aug 2008 00:30:22 -0700 (PDT)
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 387703A6ADD for <geopriv@core3.amsl.com>; Fri, 1 Aug 2008 00:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCvGpPAS13fP for <geopriv@core3.amsl.com>; Fri, 1 Aug 2008 00:30:20 -0700 (PDT)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 2F0D43A6AAD for <geopriv@ietf.org>; Fri, 1 Aug 2008 00:30:19 -0700 (PDT)
X-SEF-Processed: 5_0_0_910__2008_08_01_02_46_09
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 01 Aug 2008 02:46:09 -0500
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Aug 2008 02:30:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 01 Aug 2008 02:30:44 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF104A2EFD8@AHQEX1.andrew.com>
In-Reply-To: <20080801030018.B2624516084@kilo.rtfm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] Security Considerations:draft-thomson-geopriv-held-measurements-02.txt
Thread-Index: Acjzgrwu7EI7yQ0bS5qSzlpnq4Yj4AAJOKqA
References: <20080731093059.7EC9C502E93@kilo.rtfm.com><E51D5B15BFDEFD448F90BDD17D41CFF104A2ED39@AHQEX1.andrew.com> <20080801030018.B2624516084@kilo.rtfm.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Eric Rescorla <ekr@networkresonance.com>
X-OriginalArrivalTime: 01 Aug 2008 07:30:38.0810 (UTC) FILETIME=[7ED67BA0:01C8F3A8]
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] Security Considerations:draft-thomson-geopriv-held-measurements-02.txt
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

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

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]
> Sent: Friday, 1 August 2008 4:00 AM
> To: Thomson, Martin
> Cc: Eric Rescorla; geopriv@ietf.org
> Subject: Re: [Geopriv] Security Considerations:draft-thomson-geopriv-
> held-measurements-02.txt
> 
> 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
> 

------------------------------------------------------------------------------------------------
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