RE: [Sipping-emergency] Comment about Charter [no privacy?]
"Brian Rosen" <br@brianrosen.net> Fri, 29 October 2004 12:39 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 IAA24566 for <sipping-emergency-web-archive@ietf.org>; Fri, 29 Oct 2004 08:39:12 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWGQ-0005tp-V7 for sipping-emergency-web-archive@ietf.org; Fri, 29 Oct 2004 08:53:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVat-0001pA-Eu; Fri, 29 Oct 2004 08:10:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNVYN-0006Sz-G8 for sipping-emergency@megatron.ietf.org; Fri, 29 Oct 2004 08:08:24 -0400
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 IAA22088 for <sipping-emergency@ietf.org>; Fri, 29 Oct 2004 08:08:21 -0400 (EDT)
Message-Id: <200410291208.IAA22088@ietf.org>
Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNVmT-0005Aq-Kd for sipping-emergency@ietf.org; Fri, 29 Oct 2004 08:23:08 -0400
Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.43) id 1CNVXD-0003F1-22; Fri, 29 Oct 2004 07:07:12 -0500
From: Brian Rosen <br@brianrosen.net>
To: 'Tschofenig Hannes' <hannes.tschofenig@siemens.com>, 'James Winterbottom' <winterb@nortelnetworks.com>, "'James M. Polk'" <jmpolk@cisco.com>, sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?]
Date: Fri, 29 Oct 2004 08:07:18 -0400
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcS9lCLO93tu8LpkQieTy+U0iRWBzQAF+TZA
In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04686938@mchp905a.mch.sbs.de>
X-PopBeforeSMTPSenders: br@brianrosen.net,brosen
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.6 (/)
X-Scan-Signature: b4c10eaa27436d806c79842272125a2a
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="===============1098094847=="
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 1.3 (+)
X-Scan-Signature: c6c6a408c8e09c950064e70d807ac007
This is a good point. This points out a common tension between groups seeking authenticity and groups seeking privacy. The emergency call authorities reasonably want to prevent forging of location, which could be used to direct responders away from something bad about to happen. Individuals do not want their location to be able to be tracked in some circumstances. In North America, the tension between privacy and location authenticity is solved with legislation: the privacy right is explicitly waived when an emergency call is placed. It would be interesting to know if this is not the case in other areas. This is a geopriv issue, but we might have to send some requirements to them over the issue. Recognize that automatic reporting of location is implemented because all too often the caller does not know where they are, or is unable to communicate where they are, to the call taker. When you make an emergency call, you MUST provide location, and in every jurisdiction, it would be a crime to falsely report your location. 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. 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 _____ From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Tschofenig Hannes Sent: Friday, October 29, 2004 4:14 AM To: 'James Winterbottom'; James M. Polk; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] hi james, every document will have to address both privacy and security considerations. the geopriv requirements draft gives a number of guidelines but more work is needed when you apply it to an actual using protocol (such as sip). the fact that you have pseudonyms is nice but still there are some places where user names show up. for example, end-to-end security mechanisms provide the recipient a way to authenticate you (and authorizate you based on your authenticated identity) but if you want to experience anonymity then the authorization functionality at the recipient is certainly more difficult. ciao hannes _____ From: James Winterbottom [mailto:winterb@nortelnetworks.com] Sent: Freitag, 29. Oktober 2004 08:32 To: James M. Polk; sipping-emergency@ietf.org Subject: RE: [Sipping-emergency] Comment about Charter [no privacy?] Hi James, Doesn't "draft-ietf-geopriv-pres-02" suggest that a location server/generator is able to transmit a location to a location recipient, be that the target itself, or someone else. I believe that this is also covered in RFC-3693 GeoPriv Requirements. In order to be able to transmit a location, one must first be able to determine it!!! For the purposes of transmitting location pseudonyms are also used, so I am not sure where the tying to a user name comes in. What was submitted by me is a set of requirements that the authors believe need to be satisfied in order to meet the needs of emergency service providers. There has been no discussion of not using or varying the existing GeoPriv rulesets. Cheers James -----Original Message----- From: sipping-emergency-bounces@ietf.org [mailto:sipping-emergency-bounces@ietf.org] Sent: Friday, 29 October 2004 3:07 PM To: sipping-emergency@ietf.org Subject: [Sipping-emergency] Comment about Charter [no privacy?] All In reading the charter for our new ECRIT BOF, I don't see mention of privacy concerns wrt the ability to track an endpoint based on some Loc Info Server (LIS) always knowing where that endpoint is (if nomadic or mobile), or tying a user(name) to a particular endpoint (regardless of what type it is). I thought privacy was agreed upon to be mentioned as a consideration? I know at least Jonathan and I brought it up, and I think I remember Jon agreeing to this consideration. We do not want to ignore the retention and distribution rules we so carefully built into the PIDF-LO cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ 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