[secdir] review of draft-ietf-geopriv-l7-lcp-ps-09.txt

Stephen Kent <kent@bbn.com> Thu, 09 July 2009 19:12 UTC

Return-Path: <kent@bbn.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 506C23A67DF for <secdir@core3.amsl.com>; Thu, 9 Jul 2009 12:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 RzGhoVsTw645 for <secdir@core3.amsl.com>; Thu, 9 Jul 2009 12:12:54 -0700 (PDT)
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 048443A6A87 for <secdir@core3.amsl.com>; Thu, 9 Jul 2009 12:12:54 -0700 (PDT)
Received: from dhcp89-089-096.bbn.com ([128.89.89.96]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1MOz3Y-0006yO-BO; Thu, 09 Jul 2009 15:13:20 -0400
Mime-Version: 1.0
Message-Id: <p06240809c67bf10d01a0@[128.89.89.96]>
Date: Thu, 09 Jul 2009 15:13:18 -0400
To: secdir@core3.amsl.com
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-964955696==_ma============"
Cc: hgs+ecrit@cs.columbia.edu, Hannes.Tschofenig@gmx.net
Subject: [secdir] review of draft-ietf-geopriv-l7-lcp-ps-09.txt
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: Thu, 09 Jul 2009 19:12:55 -0000

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

Draft-ietf-geopriv-l7-lcp-ps-09.txt is a problem statement and 
requirements and design decisions document dealing with the layer 7 
location configuration protocol (L7 LCP) being developed in the 
GEOPRIV WG. As stated in the abstract:

    This protocol aims to allow an end host to obtain
    location information, by value or by reference, from a Location
    Information Server (LIS) that is located in the access network.  The
    obtained location information can then be used for a variety of
    different protocols and purposes.

A protocol of this sort engenders significant privacy concerns. I was 
disappointed that the document does not do a good job of clearly 
stating these concerns and collecting them in one place, e.g., the 
Secruity Consideration section or the requirements section.

Section 3 of the document describes four types of network environments:
1.	DLS/cable nets and WiMax-like fixed access
2.	Airport, City, Campus Wireless Networks (e.g., 802.11/a/b/g and Wimax)
3.	3G
4.	Enterprise
At the top level, this seems to be an odd taxonomy, e.g., how are 
802.11 nets (2) different from enterprise nets (4) in general?  One 
has to read the detailed examples that follow to try to learn why 
these are meaningfully different environments re the L7 LCP. It 
doesn't help that the examples provided do not correspond directly to 
the four environments named above! This section could be improved in 
this regard.

Sections 4 & 5 document some of the issues that the L7 LCP design 
team has explored. There are some security-relevant observations in 
these sections, e.g.,  "The LIS discovery procedure raises deployment 
and security issues.  The access network needs to be designed to 
prevent man-in-the-middle adversaries from presenting themselves as a 
LIS to end hosts.  When an end host discovers a LIS, it needs to 
ensure [verify?] (and be able to ensure [verify?]) that the 
discovered entity is indeed an authorized LIS." Unfortunately, these 
are other comments are scattered throughout these sections and not 
collected in one place (anywhere in the document) where they are 
clearly identified as requirements.

Section 6 enumerates the requirements that the design team proposes 
for the L7 LCP. Unfortunately, several security-relevant observations 
that appear in sections 4 & 5 do not seem to appear as requirements 
in this section.

The Security Considerations section (7) is very brief and it does not 
capture many of the security-relevant "requirements" that were 
discussed in sections 4 & 5. Instead it notes that these are 
sprinkled throughout the document. I think it would be preferable if 
this info were collected here, especially because Sections 4 & 5 are 
not labeled as containing requirements, and Section 6 (which is the 
requirements list) does not seem to capture these security/privacy 
issues either. Finally, I note that the few security requirements 
listed in Section 7 are not quite accurate. For example, the client 
is required to be able to authenticate an LIS, but the real 
requirement would seem to be that the client can verify that the 
authenticated entity is an LIS!