Re: [Geopriv] RE: Strawman Proposal

Richard Barnes <rbarnes@bbn.com> Tue, 13 March 2007 21:25 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 1HREUo-0004mm-2G; Tue, 13 Mar 2007 17:25:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREUl-0004mb-Vm for geopriv@ietf.org; Tue, 13 Mar 2007 17:25:23 -0400
Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HREUk-0007Zw-LI for geopriv@ietf.org; Tue, 13 Mar 2007 17:25:23 -0400
Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <rbarnes@bbn.com>) id 1HREUh-0006nI-60; Tue, 13 Mar 2007 17:25:20 -0400
Message-ID: <45F716BE.6080407@bbn.com>
Date: Tue, 13 Mar 2007 17:25:18 -0400
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Geopriv] RE: Strawman Proposal
References: <E51D5B15BFDEFD448F90BDD17D41CFF102957DA6@AHQEX1.andrew.com> <03B0FD26-7F5F-4DDB-A177-E58930DFF0B0@cs.columbia.edu>
In-Reply-To: <03B0FD26-7F5F-4DDB-A177-E58930DFF0B0@cs.columbia.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: GEOPRIV <geopriv@ietf.org>, "Dawson, Martin" <Martin.Dawson@andrew.com>, 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

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

Location granularity and certification granularity are two orthogonal 
issues.  If there's one server that knows the geography of the whole 
Columbia campus, then there's only one certificate to manage.  If you 
have one per building, then you have might a few more, or you might have 
each server reach back to a central signing server for a signature.

--RB

> 
> 
> 
> 
>>
>> [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
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 



_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv