[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