Last Call Review of draft-ietf-geopriv-lbyr-requirements-
review-ietf-geopriv-lbyr-requirements-secdir-lc-orman-2009-06-16-00

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