Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04

Jeffrey Hutzelman <jhutz@cmu.edu> Sun, 07 December 2008 20:51 UTC

Return-Path: <secdir-bounces@ietf.org>
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EF33A69B6; Sun, 7 Dec 2008 12:51:43 -0800 (PST)
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 32DF23A69A2; Sun, 7 Dec 2008 12:51:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.187
X-Spam-Level:
X-Spam-Status: No, score=-5.187 tagged_above=-999 required=5 tests=[AWL=1.412, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 EBLYz0EVYaEh; Sun, 7 Dec 2008 12:51:41 -0800 (PST)
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 4D1D63A6906; Sun, 7 Dec 2008 12:51:41 -0800 (PST)
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mB7KpA2f025993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2008 15:51:11 -0500 (EST)
Date: Sun, 07 Dec 2008 15:51:10 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Cullen Jennings <fluffy@cisco.com>, Ralph Droms <rdroms@cisco.com>
Message-ID: <6C080E9C41171ADC1116AA58@atlantis.pc.cs.cmu.edu>
In-Reply-To: <200812071918.mB7JIkwI004440@grapenut.srv.cs.cmu.edu>
References: <alpine.BSF.1.10.0811260255330.4213@fledge.watson.org> <90AC45ED-BF49-46ED-A35A-14E1BF699959@cisco.com> <56DEB14D23377D001B19EFE5@p3.int.jck.com><493661F5.10705@piuha.net> <B111CDE5-E8D0-4C96-AD53-B8580274F949@cisco.com> <200812071918.mB7JIkwI004440@grapenut.srv.cs.cmu.edu>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Cc: "Richard Johnson (raj)" <raj@cisco.com>, IETF Discussion <ietf@ietf.org>, secdir@ietf.org, draft-raj-dhc-tftp-addr-option@tools.ietf.org, dhc Chairs <dhc-chairs@tools.ietf.org>, Samuel Weiler <weiler@watson.org>, Jari Arkko <jari.arkko@piuha.net>, IESG IESG <iesg@ietf.org>, John C Klensin <john-ietf@jck.com>
Subject: Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04
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/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

--On Sunday, December 07, 2008 12:18:37 PM -0700 Cullen Jennings 
<fluffy@cisco.com> wrote:

>
> I find the claim that attacks are easier to do with "VoIP Configuration
> Server Address" than the "TFTP Server Name" to be pretty dubious.

Me too.



> That said, I think this security discussion is going the wrong direction.
> What is common practice, and what I think this should suggest, is that
> DHCP can be spoofed in some cases. The correct thing to do is to secure
> the object that is retrieved via tftp.

I'm inclined to agree with this, in principle.
In practice, that requires either preconfiguration, which sort of defeats 
the point of using DHCP, or a closed system like firmware updates signed by 
a device manufacturer, where not only the network but also the user and 
DHCP server operator are untrusted.

If we're talking about an option which will only ever be used to tell 
phones where to download new firmware, then this is fine.  If we're talking 
about an option which will be used by network operators to provide 
configuration to phones (in order to avoid manual configuration), or in 
general to provide a TFTP server address for whatever is the next step in 
the boot process, then "secure the object" sounds like good advice but IMHO 
is less practical than "configure your network to prevent DHCP spoofing".

> There are ways to mitigate DHCP spoofing but
> discussion of those is outside scope of this draft.

I agree that discussion of how to mitigate DHCP spoofing is out of scope. 
However, I think recommending that operators do so is appropriate.


_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir