RE: [Geopriv] RE: Strawman Proposal

["Dawson, Martin" <[e-mail]>]

		Hi Hannes,
		 
		My further comments below.
		 
		Cheers,
		Martin

________________________________

		From: Hannes Tschofenig [mailto:[e-mail]]
		Sent: Wed 3/14/2007 7:05 PM
		To: Dawson, Martin
		Cc: Richard Barnes; Henning Schulzrinne; GEOPRIV; Marc Linsner
		Subject: Re: [Geopriv] RE: Strawman Proposal
		
		

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

[MCD] I think we are saying the same thing


>  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] I could go on about how an ESRK actually is a location reference or that the cypher mechanisms used to identify the SUPL server are examples of these things but there's no real point because we've already established that the Internet service model is what introduces the specific issues - and these didn't exist in the same sense for cellular.

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

[MCD] Imagine a VPC (or a PSAP if that simplifies the model) receives a location reference as part of a call. Now it is going to go to the URI indicated by that reference. How is it going to know that the LIS serving that URI is trusted? I think the answer is that it needs to be certified by some recognized authority. Finally, since the dereferencer may still not be the ultimate consumer of the location object, I'd still prefer to keep the option of getting a signed LO via this interface as well.

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


[MCD] I wish. Unfortunately it's enough of a challenge to get travel funding just for James.


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




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