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

From: Bernard Aboba ^lt;Bernard_Aboba@hotmail.com>
Date: Thu May 07 2009 - 22:43:32 EDT

Comments below.

 

From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Sunday, May 03, 2009 4:20 AM
To: 'Bernard Aboba'; Tschofenig, Hannes (NSN - FI/Espoo); geopriv@ietf.org
Subject: RE: [Geopriv] draft-tschofenig-ecrit-trustworthy-location

 

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

 

[BA] Some additional details on the attacks are provided here:

 <http://www.foxnews.com/story/0,2933,486444,00.html>
http://www.foxnews.com/story/0,2933,486444,00.html

 

"In a grisly sounding call to 911, Ellis was putting an Internet-based phone
service for the hearing-impaired to nefarious use." This would appear to
refer to a TDD and/or RFC 5194 device.

 

Other articles talk about different attack approaches:

 
<http://ezinearticles.com/?Man-Sends-SWAT-Team-to-Unsuspecting-Homes-in-Phon
e-Prank&id=1097404>
http://ezinearticles.com/?Man-Sends-SWAT-Team-to-Unsuspecting-Homes-in-Phone
-Prank&id=1097404

 

 

 
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.

 

[BA] In practice, associating location to a specific source may a "system
property", not a characteristic of the LCP . For example, a LIS might
obtain location information via a mechanism (such as LLDP-MED Notifications)
that is partially or wholly dependent on information supplied by the
endpoint (e.g. the Chassis-Id supplied in an endpoint LLDP-MED
announcement). In such a case, is the "source of location" really
attributable to the LIS, and can it be said to be trustworthy? If the LIS
cannot verify the location information (e.g. determine that the endpoint is
really where they say they are), then I'd probably say that it is not
trustworthy, regardless of whether the LCP supports security mechanisms
such as signing, location by reference, etc.

 

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.

 

[BA] There are a number of different identities here. Presumably they are
cryptographically bound together so that it is possible to verify that the
deviceID in the PIDF-LO is bound to the identity used in the location
request (e.g. the identity implicitly or explicitly present in the HELD
request) as well as to the SIP Identity. Without those bindings, it's not
clear to me how the recipient can determine whether the enclosed PIDF-LO
really belongs to the emergency call that it is receiving.

 

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

 

[BA] As an example, the certificate hierarchy referred to in NENA i2 Section
3.7 would seem to imply issuance of LIS certificates chaining to a VESA
trust anchor. The implication is that certificate issuance would need to be
carried out on a regional or even national scale, based on a (presumably
carefully thought through) certificate issuance policy.

 

Some of the same issues come up with respect to "Location by Reference".
Here it would seem that the PSAP would need to validate the LIS server
certificate, as well potentially providing its own credentials to
dereference the LbyR. Configuring a PSAP with credentials for all the LISes
in a region or nation is a pretty big job. Also, with LbyR, there is a
dependency on TLS implementations which potentially have some serious
certificate path validation bugs:

http://support.microsoft.com/kb/329115

http://www.linuxsecurity.com/content/view/147964

https://cert.belnet.be/belnetadvisories/cisco-security-advisory-ssltls-certi
ficate-and-ssh-public-key-validation-vulnerabil

 

 

 

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 Thu, 7 May 2009 19:43:32 -0700

This archive was generated by hypermail 2.1.8 : Thu May 07 2009 - 22:44:05 EDT