[secdir] secdir review of draft-ietf-geopriv-res-gw-lis-discovery-05

Catherine A Meadows <catherine.meadows@nrl.navy.mil> Sun, 28 July 2013 16:39 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1A9D421F9C6E; Sun, 28 Jul 2013 09:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Pr7cptU3OynK; Sun, 28 Jul 2013 09:38:55 -0700 (PDT)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil []) by ietfa.amsl.com (Postfix) with ESMTP id 20A0421F9C6C; Sun, 28 Jul 2013 09:38:53 -0700 (PDT)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net []) by fw5540.nrl.navy.mil (8.14.4/8.13.6) with ESMTP id r6SGcqJ0016769; Sun, 28 Jul 2013 12:38:53 -0400
Received: from chacs.nrl.navy.mil (sun1 []) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id r6SGcpvI017500; Sun, 28 Jul 2013 12:38:51 -0400 (EDT)
Received: (from [IPv6:::1] []) by chacs.nrl.navy.mil (SMSSMTP with SMTP id M2013072812385003773 ; Sun, 28 Jul 2013 12:38:51 -0400
From: Catherine A Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sun, 28 Jul 2013 12:38:50 -0400
Message-Id: <9D29BF1C-6867-4379-8843-975D9BD5F906@nrl.navy.mil>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-geopriv-res-gw-lis-discovery.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [secdir] secdir review of draft-ietf-geopriv-res-gw-lis-discovery-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 28 Jul 2013 16:39:06 -0000

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.

This draft describes a method in which a device can discover a Location Information Server when a residential
gateway is present that does not support such discovery.  Normally such discovery is done by the device via an option is DHCP (described in  RFC5389  ), but
this will not be possible if the gateway does not support this option in  DHCP.

In both the DHCP-supported protocol and the protocol covered in this draft the device provides a domain name
to a DNS server, which uses it to discover the appropriate LIS.  In the DHCP-supported protocol the device uses the access network domain name DHCP options as the preferred
source of domain names.  This draft provides ways in which the device can determine likely candidates for domain names if the DHCP option is not supported.

The main security considerations for both the protocol described in this draft and RFC 5986 arise from the fact
that communication with the DNS server is not authenticated.  This is noted and discussed in the security considerations

I have a couple of questions.  The authors mention that RFC 5986 is the preferred method whenever it is supported.  I believe that this is because it is more accurate.  First question: am I correct in believing this?  Secondly, is there any way an attacker could a) cause
a device to identify the wrong domain name and b) if a device identifies an incorrect domain name (whether or not the
attacker can cause this to happen) is there anyway an attacker can exploit that?

Question 2a) may be difficult to answer because the draft does not mandate any particular solution. Indeed it cannot, because the solution used will depend on what is supported locally.  But if the answers to questions 1 and  2b) are "yes"
it might be worthwhile to point this out in the security considerations section as an additional reason to use the
solution  given in  RFC5389 whenever it is available.

Cathy Meadows