Re: [secdir] Review of draft-ietf-geopriv-lbyr-requirements-07

"Roger Marshall" <RMarshall@telecomsys.com> Wed, 02 September 2009 21:03 UTC

Return-Path: <RMarshall@telecomsys.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 D891D28C234; Wed, 2 Sep 2009 14:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Level:
X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, MANGLED_LOAN=2.3]
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 TZY9cyxEdZSu; Wed, 2 Sep 2009 14:03:13 -0700 (PDT)
Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id BEC9728C1EE; Wed, 2 Sep 2009 14:03:12 -0700 (PDT)
Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id <T90875c4da80a200c4916d0@sea-mimesweep-1.telecomsys.com>; Wed, 2 Sep 2009 13:31:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 2 Sep 2009 13:30:43 -0700
Message-ID: <8C837214C95C864C9F34F3635C2A65750E311223@SEA-EXCHVS-2.telecomsys.com>
In-Reply-To: <200906090451.n594pGcD012946@localhost.localdomain>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-geopriv-lbyr-requirements-07
Thread-Index: AcnovhlxmLq7CazJTqGcNIVi5D6NQhCdYgcg
References: <200906090451.n594pGcD012946@localhost.localdomain>
From: "Roger Marshall" <RMarshall@telecomsys.com>
To: "Hilarie Orman" <ho@alum.mit.edu>, <secdir@ietf.org>
X-Mailman-Approved-At: Wed, 02 Sep 2009 22:54:29 -0700
Cc: fluffy@cisco.com, acooper@cdt.org, iesg@ietf.org, Lisa.Dusseault@messagingarchitects.com
Subject: Re: [secdir] Review of draft-ietf-geopriv-lbyr-requirements-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 02 Sep 2009 21:03:14 -0000

Hilarie:

Thank you for your comments.  I apologize for the long delay in getting
these processed.

Please see my responses to your comments, inline.

-roger marshall. 

> -----Original Message-----
> From: Hilarie Orman [mailto:ho@alum.mit.edu] 
> Sent: Monday, June 08, 2009 9:51 PM
> To: secdir@ietf.org
> Cc: iesg@ietf.org; Roger Marshall; rbarnes@bbn.com; 
> acooper@cdt.org; fluffy@cisco.com; 
> Lisa.Dusseault@messagingarchitects.com
> Subject: Review of draft-ietf-geopriv-lbyr-requirements-07
> 
> 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.

[RM- it is true that requirement D3 (restated below) states the required
form that gets dereferenced, but the reference you cite above has to do
with the term "LbyV", defined more-or-less in RFC 4119, and provided
here for background in contrast to LbyR.  Therefore, I'm not sure that
it should be more closely tied to "LbyR".  

"D3.  Dereferenced Location Form:  The value returned by the
      dereference protocol MUST contain a well-formed PIDF-LO document."

The requirement(s) that LbyV MUST be in PIDF-LO form, however it is
implied or stated elsewhere.  As a way forward, I'm hoping that changing
the following to remove the "such as...", making the RFC 3693 "LO"
reference a more explicit "PIDF-LO", and contrasting LbyV with LbyR,
will be sufficient.

Change from (Cf):
   Location-by-Value (LbyV):  Using location information in the form of
      a location object (LO), such as a PIDF-LO.
Change to (Ct):
   Location-by-Value (LbyV):  Using location information directly within
signaling, in the form of
      a location object (PIDF-LO), an alternative approach to using
LbyR.
/]

> 
> ---
> 
> 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.

[RM- agree with your comment.  Changed throughout, as noted below:

Introduction -
Cf:
such as whether a Target is mobile 
and whether a mobile device needs to be located 
Ct:
such as whether a Target is mobile 
and whether this mobile target needs to be located 


After Figure 1 -
Cf:
1. The Target (a Device)
Ct:
1. The Target (an end device)


Under "Location URI Authorization", under scenario 4.,
Cf:
the location URI is confidential 
information shared between the LIS/LS, the Device 
Ct:
the location URI is confidential 
information shared between the LIS/LS, the Target


"Location URI Authorization"
Cf:
Construction of a location URI in such a 
way as to not reveal any domain, user, or device specific information
Ct:
Construction of a location URI in such a 
way as to not reveal any domain, user, or target specific information


"Requirements for a Location Configuration Protocol"
Cf:
C5. User Identity Protection:  The location URI MUST NOT 
contain information that identifies the user or target (e.g., device).
Examples 
include phone extensions, badge numbers, first or last names.
Ct:
C5. Target Identity Protection:  The location URI MUST NOT 
contain information that identifies the target (e.g., domain, user,
device). Examples 
include phone extensions, badge numbers, first or last names.


"Location URI Authorization", changing title from "user" to "Target",
Cf:
2. No user specific information: By default, a location URI 
MUST NOT reveal any information about the Target other than location 
information.  This is true for the URI itself, (or in the document
acquired by 
dereferencing), unless policy explicitly permits otherwise.
Ct:
2. No Target specific information: By default, a location URI 
MUST NOT reveal any information about the Target, (e.g., domain, user,
or device), other than location 
information.  This is true for the URI itself, (or in the document
acquired by 
dereferencing), unless policy explicitly permits otherwise.


"Location URI Construction"
Cf:
Construction of a location URI in such a 
way as to not reveal any domain, user, or target specific information
Ct:
Construction of a location URI in such a 
way as to not reveal any target specific information, (e.g., domain,
user, or device),

/]

> 
> ---
> 
> "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.

[RM - Though the wg agrees that there is no security-thru-obscurity, the

wg felt strongly that a certain level of blurring of the location URI 
would be a generally good practice for systems to employ.  I've added 
one example to the Motivation statement, in hopes that this does a 
little better job in explaining and justifying this kind of default 
requirement.

"C8. Location URI Not guessable:",
Cf:
Motivation: Location URIs should be constructed in such a way that an 
adversary cannot guess them and dereference them without having ever 
obtained them from the Target.
Ct:
Motivation: Location URIs should be constructed in such a way that an 
adversary cannot guess them and dereference them without having ever 
obtained them from the Target.  An example location URI presented as 
"john.doe@domain.com".com", might make it possible for someone to also 
easily guess the URI relating the location of a "jane.doe@domain.com".com".

/]

> 
> ---
> 
> "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?


[RM - This is a good catch.  Yes, I believe it should say "Target",
since 
This is a "C", or Configuration protocol requirement.  See the proposed
change, below:

Cf:
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.

Motivation:  The client requesting a location URI may request a location
URI 
which has a 'one-time-use' only characteristic, as opposed to a location
URI 
having multiple reuse capability.

Ct:
C6. Reuse indicator: There SHOULD be a way to allow a 
TARGET to control whether a location URI can be resolved once only, or
multiple 
times.

Motivation:  The Target requesting a location URI may request a location
URI 
which has a 'one-time-use' only characteristic, as opposed to a location
URI 
having multiple reuse capability.


Note: This also leads to other uses of client for Target within the
Location 
Configuration context.  In light of the below proposed changes, the
document 
only retains the use of "client" in reference to the Location
Dereference Protocol.

Cf:
Location Configuration Protocol: A protocol which 
is used by a client to acquire either location or a location URI from a
location 
configuration server, based on information unique to the client.
Ct:
Location Configuration Protocol: A protocol which 
is used by a Target to acquire either location or a location URI from a
location 
configuration server, based on information unique to the Target.

Cf:
C3. Location URI cancellation: The location configuration 
protocol MUST support the ability to request a cancellation of a
specific 
location URI.

Motivation: If the client determines that in its best interest to
destroy the 
ability for a location URI to effectively be used to dereference a
location, then 
there should be a way to nullify the location URI.

Ct:
C3. Location URI cancellation: The location configuration 
protocol MUST support the ability to request a cancellation of a
specific 
location URI.

Motivation: If the Target determines that in its best interest to
destroy the 
ability for a location URI to effectively be used to dereference a
location, then 
there should be a way to nullify the location URI.

/]

> 
> Must the server return an error if a one-time URI is reused?  
> Or can it return the old information?

[RM - My take is that the server has implementation choice as to what
can be returned:

i. an error with old location
ii. an error with no location
iii. no error msg., only the old location

This allowance, (admittedly short of defining any new requirements in
this document), 
is adequately reflected in the following amended motivation sentence:

Cf:
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.

Motivation:  The client requesting a location URI may request a location
URI 
which has a 'one-time-use' only characteristic, as opposed to a location
URI 
having multiple reuse capability.

Ct:
C6. Reuse indicator: There SHOULD be a way to allow a 
Target to control whether a location URI can be resolved once only, or
multiple 
times.

Motivation:  The Target requesting a location URI may request a location
URI 
which has a 'one-time-use' only characteristic, as opposed to a location
URI 
having multiple reuse capability.  This would allow the server to return
an 
error with or without location during the subsequent dereference
operation.

/]

> 
> ---
> 
> 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.

[RM - I can see your point, and so have added some text, not as a
requirement, but to the 
Security section for reader consideration.  See the following:

A covert channel for protocol message exchange is an important 
consideration, given an example scenario where user A subscribes to
location 
information for user B, then every time A gets a location update an 
(external) observer of the subscription notification may know that B has
moved.  
One mitigation to this is to have periodic notification, so that user B
may appear 
to have moved, even when static.

/]

> 
> Hilarie
> 
> 

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.