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:
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 at nsn.com
> To:
geopriv at 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 at ietf.org
>
https://www.ietf.org/mailman/listinfo/geopriv
