Re: [Geopriv] RE: Strawman Proposal

[Hannes Tschofenig <[e-mail]>]

Hi Martin,

please find some comments below:

Dawson, Martin wrote:
> Comments inline.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]] 
> Sent: Wednesday, 14 March 2007 8:54 AM
> To: Richard Barnes
> Cc: Henning Schulzrinne; GEOPRIV; Dawson, Martin; Marc Linsner
> Subject: Re: [Geopriv] RE: Strawman Proposal
>
> We mentioned the idea of putting two PIDF-LOs into a SIP signaling 
> message, namely one for routing and another one for consumption at the
> PSAP.
> The one for routing does not need to provide a perfect precision, as we 
> know. For some countries it would be sufficient to use state granularity
>
> to hit the correct PSAP.
>
> I am also addressing those people who argue that "Operators will never 
> provide location information to the end host because they want to make 
> money with location-based applications. Hence, they can only use 
> location-by-reference".
>
> I don't want to create relationships between every VoIP provider and 
> every access network provider in the world because I believe that this 
> will do a lot of harm to the Internet. I am OK with a relationship 
> between access network provider and PSAPs even though I see a lot of 
> problems there as well.
>
> [[MCD]] 
> [[MCD]] Absolutely agree. It seems that IMS actually makes that
> assumption - using the traditional "roaming partner" model that assumes
> the voice service *is* the access service.

IMS assumes that the access provider is the VoIP provider. That's a bit 
different.

Both views are unrealistic (my personal opinion).


>  It misses the major point of
> using the Internet. Imagine being told you could only use your email or
> Internet banking from "partner" access providers.
>
> If we have to use a location-by-reference mechanism for these operators 
> then we don't need location signing.
>   
Today it, however, seems that the 3GPP does not even consider a 
location-by-reference nor a location signing approach.
They are just happy with their emergency service architecture as is.

> [[MCD]] 
> [[MCD]] No, I disagree. Signed location - even obtained via reference -
> should still have the characteristics identified by the requirements.
>   
Why would you want to protect location twice?
To me this looks like using HTTPS and S-HTTP together.

> Imagine a dereferencing done to an ISP LIS, but the location-determiner
> and signer is actually a DSL infrastructure operator. About the only
> characteristic that could probably be ignored is the temporal component.
> That is, since I'm only asking right now, I know that the location is
> being provided right now.
>   
I don't agree that this is a realistic threat scenario based on what I 
replied to James.

> I doubt that signed location information can be demanded for all 
> emergency service calls since we will even see calls with absolutely no 
> location information at all. Furthermore, we would have to tell the IEEE
>
> to go home since none of their solution does any sort of signing.
> [[MCD]] 
> [[MCD]] I doubt that it can to - especially in the short term. I see
> this as providing the tools that can begin to be applied now but which
> will really come into their own over the next ten years as the PSTN
> begins to drag its other foot into the grave.
>   
I hope you are going to be at the IEEE / ECRIT information sharing 
meeting in Prague.

Ciao
Hannes

> Ciao
> Hannes
>
>
> Richard Barnes wrote:
>   
>>> 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
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/geopriv
>>>
>>>
>>>       
>>
>> _______________________________________________
>> Geopriv mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/geopriv
>>     
>
>
> ------------------------------------------------------------------------------------------------
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv