RE: [Geopriv] RE: Strawman Proposal

"Dawson, Martin" <Martin.Dawson@andrew.com> Tue, 13 March 2007 23:34 UTC

Return-path: <geopriv-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRGVX-0008NA-GR; Tue, 13 Mar 2007 19:34:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRGVV-00086B-LF for geopriv@ietf.org; Tue, 13 Mar 2007 19:34:17 -0400
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRGVU-0004VQ-9M for geopriv@ietf.org; Tue, 13 Mar 2007 19:34:17 -0400
X-SEF-Processed: 5_0_0_910__2007_03_13_18_40_12
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 13 Mar 2007 18:40:12 -0500
Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 18:34:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Geopriv] RE: Strawman Proposal
Date: Tue, 13 Mar 2007 18:29:39 -0500
Message-ID: <EB921991A86A974C80EAFA46AD428E1E026CCD45@aopex4.andrew.com>
In-Reply-To: <03B0FD26-7F5F-4DDB-A177-E58930DFF0B0@cs.columbia.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] RE: Strawman Proposal
Thread-Index: AcdltPunGLJVSmIERrCfeRQkXF90ogAEdamg
From: "Dawson, Martin" <Martin.Dawson@andrew.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>, "Winterbottom, James" <James.Winterbottom@andrew.com>
X-OriginalArrivalTime: 13 Mar 2007 23:34:14.0589 (UTC) FILETIME=[1C4AFED0:01C765C8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: GEOPRIV <geopriv@ietf.org>, Marc Linsner <mlinsner@cisco.com>
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Errors-To: geopriv-bounces@ietf.org

The word "conflates" has been getting a good airing lately, so I'll give
it another shake.

The problem I have with this thread is that it is conflating the process
of subscriber identity and location.

One requirement that hasn't come out of NENA in this forum is that the
subscriber identity be delivered with some kind of strong credentials.
The reasons for this are at least twofold.

Firstly, the requirements were about location - so why would subscriber
identity turn up at all?

Secondly, one of the things that emergency services don't concern
themselves with in responding to callers is whether you really are the
individual they claim to be. Anonymous emergency calling via public
payphones, SIMless mobiles, and any other point a caller can lay their
hands on a device is an accepted feature of the service.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] 
Sent: Wednesday, 14 March 2007 8:17 AM
To: Winterbottom, James
Cc: Hannes Tschofenig; GEOPRIV; Dawson, Martin; Marc Linsner
Subject: Re: [Geopriv] RE: Strawman Proposal


On Mar 13, 2007, at 4:51 PM, Winterbottom, James wrote:

> Hi Hannes,
>
>
>> * We don't do Location Signing at all.
>> * Access networks distribute location information to the end host  
>> at a
>> granularity that allows location based routing (unsigned). For most
>> countries this is in fact trivial.
>
>
> [AJW] My discussions with carriers and infrastructure providers  
> seems to
> suggest that obtaining location information to provide to end hosts is
> going to be far from trivial. When confronted with this hurdle I am  
> not
> so sure that adding signing is that much more work.

I agree with Hannes that location granularity matters. Having a  
single LO for the whole DSLAM (or DHCP server) that says "XYZ County"  
is a whole lot easier than tracking the wiring panel changes as lines  
get moved.

Signing is not the big deal - getting valid CA-certified signatures  
is. We all know how many web servers have bogus, expired or self- 
signed certificates, and not just Joe's Barber Shop and Delicatessen.

Take a large campus with thousands of offices. Unless you have a  
fairly elaborate delegation mechanism, somebody externally will have  
to sign for each and every room. This means that the organization has  
to operate a CA that is trusted by the proposed VESA entity, for  
example. We can't even get delegation to work within Internet2 and  
Columbia.




>
> [AJW] It is not clear to me how authenticating millions of users and
> their multitude of identity mechanisms is any less daunting than
>

We have such a mechanism, e.g., within IMS, namely P-Asserted-ID,  
which is very widely deployed, from what I can tell. Or the SIP  
identity mechanism, although that seems to just start getting  
traction. The PSAP wouldn't care whether and how the VSP verified the  
customer identity; it just gets a single client cert from the VSP in  
a TLS connection.

You probably missed the discussion on this years ago, but your  
concern and the perceived difficulties of a global PKI motivated the  
current mechanism, as it only requires what customers must have  
already, namely a shared secret with their VSP, and web-style cross- 
provider trust with a single cert  for each provider.


> providing accreditation to potentially thousands of access network
> providers. But perhaps I am missing the point. That said, if you  
> couple
> this with signed location then you have the whole gamut. See location
> dependability draft
> http://tools.ietf.org/html/draft-thomson-geopriv-location- 
> dependability-
> 00
>
>>
>> PS: I also believe that the PSAP operator would accept calls that
> don't
>> have any location attached to it. How many calls today have location
>> information available? Do we have some statistics about it?
>>
>
> [AJW] All emergency calls in the world have some degree of location
> provided (inferred), though in some cases this may not be  
> fantastically
> accurate, country level. In the United States for wireline it is based
> on the calling line ID, and either an ESRD (roughly representing a  
> cell)
> or an ESRK (representing a rough calling area) for wireless.
>
> Perhaps, like some other working groups we need to make the  
> distinction
> between support and implement. I am asking that the requirements  
> include
> support for it, I think that implementation will be something that
> jurisdictions have the option to do or not.

This doesn't quite work, given that phones need to work universally.  
I don't want to buy a phone in Prague, say, that suddenly can't make  
an emergency call in New York city.

Henning

------------------------------------------------------------------------------------------------
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://www1.ietf.org/mailman/listinfo/geopriv