Re: [Geopriv] RE: Strawman Proposal

[Hannes Tschofenig <[e-mail]>]

Hi James,

The TLS server-side authentication would identify the ISP in this 
scenario and the PIDF-LO would contain a provided 'provided-by' element 
that contains the identity of the RANP. Unless you suddenly assume that 
the RANP might be the adversary and that there is no trust relationship 
between the ISP and RNAP everything just works fine. In previous 
discussions with LIS-to-LIS communication we just made these assumptions.

I see no problem.

Ciao
Hannes


Winterbottom, James wrote:
> Let me put a very real case out there, and see if it can be overcome
> just using location by reference and no signing.
>
> I have two entities that are required to provide my access network. And
> ISP and a region access network provider (RANP). The ISP cannot
> determine location, yet any location reference will point to him, in LIS
> terms it is a gateway LIS. The ISP must get location from the RANP. When
> location is requested from the ISP by a reference, the ISP presents its
> own certificate to the LR, yet it is not the ultimate source of the
> location information. How does a certificate from the ISP link back to
> location being provided by the RANP in this case?
>
> I guess I don't see a certificate used to establish a TLS session with a
> LIS as being the necessarily of the same stock as a certificate used to
> sign a location. But maybe it is just me.
>
>
>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]]
>> Sent: Wednesday, 14 March 2007 8:54 AM
>> To: Richard Barnes
>> Cc: GEOPRIV; Dawson, Martin; Marc Linsner; Henning Schulzrinne
>> 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.
>>
>> If we have to use a location-by-reference mechanism for these
>>     
> operators
>   
>> then we don't need location signing.
>>
>> 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.
>>
>> 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
>>>       
>> _______________________________________________
>> 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