Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-02.txt

Alan DeKok <aland@deployingradius.com> Tue, 04 August 2015 19:54 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B633F1A8953 for <saag@ietfa.amsl.com>; Tue, 4 Aug 2015 12:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn_yceVCKR_l for <saag@ietfa.amsl.com>; Tue, 4 Aug 2015 12:54:27 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id D90171A895E for <saag@ietf.org>; Tue, 4 Aug 2015 12:54:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 05FDD22405AC; Tue, 4 Aug 2015 21:54:25 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV4-sg95Sy_k; Tue, 4 Aug 2015 21:54:24 +0200 (CEST)
Received: from [192.168.30.17] (LStLambert-656-1-273-101.w90-63.abo.wanadoo.fr [90.63.181.101]) by power.freeradius.org (Postfix) with ESMTPSA id 7956922402D3; Tue, 4 Aug 2015 21:54:24 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <tslsi808tm9.fsf@mit.edu>
Date: Tue, 04 Aug 2015 21:54:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C0CD3761-71A9-492A-86D2-0AE0357A0CAA@deployingradius.com>
References: <313da830.6be8.14ed8564467.Coremail.lilishan48@126.com> <m2mvyfh1re.wl%randy@psg.com> <55B8A692.8080409@cs.tcd.ie> <m2a8ufgpjn.wl%randy@psg.com> <55B8D49A.1010402@cs.tcd.ie> <m2y4hyg2za.wl%randy@psg.com> <DM2PR0301MB0655D564B5F697E14F5CF371A88B0@DM2PR0301MB0655.namprd03.prod.outlook.com> <4E607681-7B1F-4128-9F24-D98FE23AA958@deployingradius.com> <BLU181-W40A804FB089C688A209AC593880@phx.gbl> <85F31297-B08F-4A86-B9A0-8004FB78DD01@deployingradius.com> <tslsi808tm9.fsf@mit.edu>
To: Sam Hartman <hartmans-ietf@mit.edu>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/HOFrLknT10JWvpnMobp9xQvmM9k>
Cc: Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] New Version Notification for draft-cui-dhc-dhcpv6-encryption-02.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 19:54:28 -0000

On Aug 3, 2015, at 2:05 PM, Sam Hartman <hartmans-ietf@mit.edu> wrote:

> Bernard claims that using the EAP key hierarchy doesn't prove
> authorization to act as a DHCP server.
> 
> There's a sense in which this is true.

  It's all very true.  But not overly helpful.

  AAA servers have certificates with an OID that says "TLS Web Server Authentication".  Yet despite that lie (or perhaps because of it), clients use those certs for EAP / 802.1X authentication.

> However, there's another sense in which being involved in the EAP keying
> proves that the proposed DHCP server is part of the infrastructure.
> I think that provides better assurance by far than we have today.
> My hope is that we do not let the perfect solution here become the enemy
> of incremental improvement.

  I agree.

  If you trust the AAA server to authenticate you, then it's beneficial to have a trusted introduction to a DHCP server.  You might ignore that trust statement, but that's your decision.  *Not* having that trust statement means you're accepting DHCP packets from random systems on the local network.  Which seems worse to me.

  Alan DeKok.