RE: [Sipping-emergency] Comment about Charter [no privacy?]
"James Winterbottom" <winterb@nortelnetworks.com> Mon, 01 November 2004 23:01 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16656 for <sipping-emergency-web-archive@ietf.org>; Mon, 1 Nov 2004 18:01:33 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COlQ8-0007Yj-R2 for sipping-emergency-web-archive@ietf.org; Mon, 01 Nov 2004 18:17:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkj1-0005EZ-3t; Mon, 01 Nov 2004 17:32:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkSp-0003rN-3C for sipping-emergency@megatron.ietf.org; Mon, 01 Nov 2004 17:15:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11495 for <sipping-emergency@ietf.org>; Mon, 1 Nov 2004 17:15:45 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkhn-00060l-T9 for sipping-emergency@ietf.org; Mon, 01 Nov 2004 17:31:16 -0500
Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com [47.153.200.67]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA1MEif24309; Mon, 1 Nov 2004 16:14:45 -0600 (CST)
Received: by zctwc060.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id <VB3FN5T8>; Tue, 2 Nov 2004 09:14:44 +1100
Message-ID: <C0FA66CBDDF5D411B82E00508BE3A7220E18DC61@zctwc059.asiapac.nortel.com>
From: James Winterbottom <winterb@nortelnetworks.com>
To: "McCalmont, Patti" <PMcCalmont@Intrado.com>, Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?]
Date: Tue, 02 Nov 2004 09:14:36 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c
Cc: sipping-emergency@ietf.org
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: sipping-emergency.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0973114233=="
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300
Location today is required for call routing and emergency dispatch and so for the charter to be useful, it needs to satisfy the requirements of its users who in this case are largely the emergency service providers. -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] Sent: Tuesday, 2 November 2004 7:23 AM To: Henning Schulzrinne Cc: sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] A couple of comments, in line. Patti McCalmont -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, October 29, 2004 8:23 AM To: Brian Rosen Cc: 'James M. Polk'; sipping-emergency@ietf.org; 'Tschofenig Hannes' Subject: 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. <PLM> There needs to be location provided by some source to enable a PSAP to assist with the emergency request. Developing systems without the ability to provide location for an emergency call is unwise. (2) The caller may refuse to give his location for good or bad reasons. <PLM> In North America, this is not allowed. An area that supports E911 has all their callers in the ALI database (yes, there can be errors but there is a process to correct these). No one can opt out. A solution that compromises the current North American level of service would not be acceptable. (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.) <PLM> dialing 9-1-1 provides location so a user doesn't get a choice. 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. <PLM> Agreed. That's why location must be validated and delivered to the PSAP in conjunction with the call. 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. <PLM> But it can help, especially if there is an officer near the location when the PSAP receives the prank call. 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?") <PLM> Better to provide information within the record delivered to the PSAP on the "assurance" of the caller's location rather than needing to train all PSAPs to be more suspicious because the signaling interface has changed. Patti > > > > 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 _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency
_______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency
- RE: [Sipping-emergency] Comment about Charter [no… McCalmont, Patti
- [Sipping-emergency] Comment about Charter [no pri… James M. Polk
- RE: [Sipping-emergency] Comment about Charter [no… James Winterbottom
- RE: [Sipping-emergency] Comment about Charter [no… Tschofenig Hannes
- RE: [Sipping-emergency] Comment about Charter [no… Tschofenig Hannes
- RE: [Sipping-emergency] Comment about Charter [no… Brian Rosen
- RE: [Sipping-emergency] Comment about Charter [no… Tschofenig Hannes
- Re: [Sipping-emergency] Comment about Charter [no… Henning Schulzrinne
- RE: [Sipping-emergency] Comment about Charter [no… Marc Linsner
- RE: [Sipping-emergency] Comment about Charter [no… James M. Polk
- RE: [Sipping-emergency] Comment about Charter [no… James M. Polk
- RE: [Sipping-emergency] Comment about Charter [no… James Winterbottom