[secdir] Review of draft-ietf-geopriv-lbyr-requirements-07
"Hilarie Orman" <ho@alum.mit.edu> Tue, 09 June 2009 04:52 UTC
Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21883A6B30; Mon, 8 Jun 2009 21:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yeXloVEOAsV; Mon, 8 Jun 2009 21:52:24 -0700 (PDT)
Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id ED1193A6B75; Mon, 8 Jun 2009 21:52:23 -0700 (PDT)
Received: from mx01.mta.xmission.com ([166.70.13.211]) by out02.mta.xmission.com with esmtp (Exim 4.62) (envelope-from <hilarie@purplestreak.com>) id 1MDtK0-0001vP-GW; Mon, 08 Jun 2009 22:52:28 -0600
Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=localhost.localdomain) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1MDtJz-0007Kt-Pk; Mon, 08 Jun 2009 22:52:28 -0600
Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id n594pIKV012950; Mon, 8 Jun 2009 22:51:18 -0600
Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id n594pGcD012946; Mon, 8 Jun 2009 22:51:16 -0600
Date: Mon, 08 Jun 2009 22:51:16 -0600
Message-Id: <200906090451.n594pGcD012946@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: ho set sender to hilarie using -f
From: Hilarie Orman <ho@alum.mit.edu>
To: secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=no signature
X-SA-Exim-Connect-IP: 166.70.57.249
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ;secdir@ietf.org
X-Spam-Relay-Country:
X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000)
X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com)
Cc: fluffy@cisco.com, rmarshall@telecomsys.com, acooper@cdt.org, iesg@ietf.org, Lisa.Dusseault@messagingarchitects.com
Subject: [secdir] Review of draft-ietf-geopriv-lbyr-requirements-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 04:52:26 -0000
Requirements for a Location-by-Reference Mechanism draft-ietf-geopriv-lbyr-requirements-07 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft is about the requirements for using an indirect reference ("location by reference") for geolocation information. The geolocation protocol can return a URI for retrieving the information that would be conveyed if "location by value" were used. Much of the document is about ensuring privacy of location information. --- In section 2, terminology, "Location-by-Value (LbyV): Using location information in the form of a location object (LO), such as a PIDF-LO." This is copied from RFC3693, but it is my understanding that PIDF-LO is an absolute requirement for geopriv-lbyr, so a note to that effect would be helpful here. --- The document would be improved by consistently using the term "target" for the thing to be located, instead of the occasional "user" or "device". If it is important to distinguish them, one could say "target's user", for example. --- "Section 4, High Level Requirements, item C8, Location URI Not guessable." This is a required default behavior. I'm not sure why the URI shouldn't be guessable, given that the PIDF-LO information can be protected through mime security. A clarifying statement should be added. --- "C6. Reuse indicator: There SHOULD be a way to allow a client to control whether a location URI can be resolved once only, or multiple times." What is the point of one-time use? Why not just send the information directly, instead of a URI? One could overload the URI format and encode the encrypted location info in the URI itself. Is the "client" the target? Must the server return an error if a one-time URI is reused? Or can it return the old information? --- The covert channel of the protocol messages is not mentioned, but should be. If user A subscribes to location information for user B, then every time A gets a location update an observer may know that B has moved. There are mitigations, such as sending the information at regular time intervals, even if the target is stationary. Hilarie
- [secdir] Review of draft-ietf-geopriv-lbyr-requir… Hilarie Orman
- Re: [secdir] Review of draft-ietf-geopriv-lbyr-re… Roger Marshall