Re: [Sipping-emergency] Comment about Charter [no privacy?]

Brian Rosen wrote:

> I would think that given the history in geopriv over this issue, that we 
> aren’t going to get IETF to publish an RFC where not reporting location 
> is incompliant with a spec; we have a sufficient number of people who 
> feel passionately that an individual cannot be COMPELLED to report 
> location.  This is quite easily dealt with by using SHOULD language.  
> The emergency call system can choose to accept such calls or not, as 
> local regulations dictate. 

It's a bit more complicated than that, as there are at least three 
reasons not to provide location:

(1) The calling end system (and elements along the call path) may not 
know the location; this is obviously going to be quite common, 
particularly in the early days. Having the PSAP refuse all such calls 
seems unwise.

(2) The caller may refuse to give his location for good or bad reasons.

(3) The caller may not be at the scene of the emergency or may report a 
non-emergency-related issue and have a legitimate interest not to report 
his location or identity. (I suspect quite a few crime tips are phoned 
into 911, even though they might not be emergencies as such.)

I don't think we need to deal with (3). A PSAP could simply tell the 
caller that the call location is recorded and provide an anonymous tip 
line number.

I don't think including "sorry, I wish I could provide my location, but 
I can't" is particularly useful since bad guys will have little 
compunction about fibbing.

In addition, "providing location" is not binary. I might decide or be 
able to provide location sufficient to route the call (e.g., town 
level), but not to dispatch a fire engine (house level).

I'm not sure what to do about this. In classical 911, this is easy since 
the system can compel you to provide location.

In practice, I don't think this is as big a problem. People routinely 
call 911 from payphones or non-phase-II cell phones today, where even 
knowing the location doesn't exactly help you to find malicious callers.

The best we can probably do is to provide degrees of assurance so that 
the responder can better tell if he should be suspicious of the call and 
maybe question the caller a bit more. ("What's the name of the cross 
street? How come it's dead quiet in the background when you're on 
Broadway and 42nd street?")

> 
>  
> 
> The most straightforward method of providing authentication would be to 
> have the location object signed by a trusted entity.  I’ve had a running 
> dialog with James Winterbottom and his co-authors on this subject; I 
> maintain it is not practical to always have a trusted entity, but let’s 
> say, for this discussion, that there is.  If only the location object 
> itself is signed, and no other identifying piece of information that 
> attaches an identity to the location, then you can assure that the 
> location report itself has not been modified, but you don’t know that 
> the object represents the location of the entity presenting it (you are 
> subject to a replay attack).   The only way to be assured that the 
> location object represents the entity presenting it would be to have a 
> credential or other identifier in the signed object that was verifiable 
> by the entity receiving the call as belonging to the entity placing the 
> call.  I have no idea what such a credential/identifier could be 
> because, as I will show, the entity that could reasonably sign the LO 
> doesn’t have any identity for the entity placing the call when it has to 
> sign the object; they are entirely disconnected from one another.  This 
> thread is about how to make sure that whatever identifier is used, it 
> can’t be used to specifically identify a person.  That still doesn’t 
> solve the problems of what entities could reasonably assert location 
> validation, and how any form of anonymous, but authenticated, location 
> could be provided.  I have no suggestions.
> 
>  
> 
> Brian

_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency