Re: [Geopriv] draft-tschofenig-ecrit-trustworthy-location

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Sun May 03 2009 - 07:19:37 EDT

Hi Bernard,

  _____

From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
Of Bernard Aboba
Sent: 30 April, 2009 13:46
To: hannes.tschofenig@nsn.com; geopriv@ietf.org
Subject: Re: [Geopriv] draft-tschofenig-ecrit-trustworthy-location

I have read the document. Initially my intent was to write a review, but in
putting some thoughts on paper, it became apparent that a more coherent and
complete response was required, which may take a while to put together. So
in the meantime, here are a few reactions:

1. The material on threats covers some new ground. Although my initial
reaction was surprise that the threats had not been covered in earlier
threat model assessments, on reviewing those previous assessments, it would
appear that there is indeed threat model material in this document that does
not overlap with previous work. Strange given recent events (see
http://pcworld.about.com/od/hackers/Couple-swarmed-by-SWAT-team-af.htm).
 
Very interesting article. It fits well to the NENA document you cited;
Section 3.7 of NENA i2 says "The existing Emergency Services Network
provides a relatively high degree of security for correctness of
information, integrity, and authorization of access, authenticity/secrecy,
and accuracy of information."
 
2. The definition of "trustworthy" is a topic worthy of more discussion.
For example, NENA i2 Section 3.7 "attempts to outline the key security
concerns relating to location data". Do the authors agree or disagree with
NENA's take on this? Getting clarity on that seems important since the
usefulness of the proposed "solutions" will inevitably be judged according
to the statement of the problem.
 
I do not agree with the conclusions they came up with. Given that the NENA
specifications consider end devices outside the scope I wonder how relevant
many of these aspects are. Furthermore, given that the same group of people
always argues that they cannot update end points (for whatever reason) I
have my doubts that they have intentions to deploy whatever type of
solution.
 
Some more relevant text from the NENA i2 specification:
http://www.nena.org/sites/default/files/08-001_20051205.pdf
 
1. The source of the location is attributable to a specific trusted source.
Location is provided

by the access/voice service provider.

 

Associating location to a specific source is fine. Whether the source is
trustworthy or not is a policy question.

 

2. The location information is applicable to a specific point in time. The
location

information is either used to directly route the call (as may be the case
for wireless), or

indirectly via the calling number/ANI (as for wireline). It is always
retrieved at the time

of call receipt.

 

A PIDF-LO has a timestamp element. So, this is not necessarily new.

In many cases the location of the emergency caller changes over time and
hence you will most likely only see a very recent timestamp anyway.

 

3. The location information can be identified as belonging to a specific
end-point. This may

be a direct association as is the case with wireline, or it may be an
indirect association, as

is the case with ESRKs in wireless. The location information is known to
apply

specifically to the calling device; another device's location cannot be
misrepresented as

the calling device's location.

 

This aspect is a bit more challenging. A PIDF-LO has a deviceID element.
However, the question really is what can be done with this information by
the party that processes the PIDF-LO.
 
 
3. Each of the proposed "solutions" brings with it a set of operational
issues which require more discussion. For example, NENA i2 Section 3.7
describes a potential certificate hierarchy developed to enable "signing".
Having been involved in a number of previous efforts to design large scale
public certificate infrastructures (e.g. WiMAX Forum client & server
certificate hierarchies), the operational issues that can potentially be
encountered are considerable. Yet they may also appear in situations where
"Location by Reference" is used, since resolution will presumably require
validation of the LIS certificate, in addition to provisioning of any client
credentials required for de-referencing. IMHO, many of the issues involved
in provisioning of certificates are also present in provisioning of other
credentials (expiration, renewal, etc.) so it's not obvious that mass-scale
deployment of LbyR would be a cake-walk either.
 
I agree. That's indeed a good point to capture the operational aspects. They
interesting issue is also that they are likely to be different between the
different applications (e.g., generic location based service vs. emergency
service).
 

Overall, my take is that the document covers an important topic, but that
more work could be done in defining the problem as well as in evaluating
implications of the solutions.
Certainly true. I will try to add more text.
 
 
Ciao
Hannes
 

> Date: Tue, 28 Apr 2009 11:12:43 +0300
> From: hannes.tschofenig@nsn.com
> To: geopriv@ietf.org
> Subject: [Geopriv] draft-tschofenig-ecrit-trustworthy-location
>
> Hi all,
>
> At the last IETF meeting Henning and I had an agenda slot for the
> presentation of draft-tschofenig-ecrit-trustworthy-location.
> Unfortunately, due to lack of time we had to skip the presentation.
>
> Here are our presentation slides:
> http://www3.ietf.org/proceedings/09mar/slides/geopriv-9.pdf
>
> We got positive feedback from NENA folks but more feedback would be
> appreciated. Please take a brief look at the slide set and/or at the
> draft itself:
> http://tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location-01.
> txt
>
> Ciao
> Hannes
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Sun, 3 May 2009 14:19:37 +0300

This archive was generated by hypermail 2.1.8 : Sun May 03 2009 - 07:19:42 EDT