Re: [Geopriv] RE: Strawman Proposal

[Hannes Tschofenig <[e-mail]>]

Hi Martin,


Dawson, Martin wrote:
> 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.
>   
I don't understand this sentence.

> The reasons for this are at least twofold.
>
> Firstly, the requirements were about location - so why would subscriber
> identity turn up at all?
>   
In the past a lot of discussions circled around the idea of putting the 
subscriber identity into the PIDF-LO (entity attribute) and then to tie 
it to subsequent authentication of the emergency caller to the PSAP to 
mitigate some replay attacks.

> 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.
>   
I don't know why you think that the true identity of the emergency 
caller is not relevant for emergency services.
The public payphone has been a source for misuse even. Some countries 
don't allow SIMless emergency calls exactly for the misuse purpose.

For the Internet, it is not even clear what "SIMless" emergency calls 
means. Does it mean "unauthenticated network access", emergency calls 
without authentication,  no authorization, etc?

Ciao
Hannes

> Cheers,
> Martin
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[e-mail]] 
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv