Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 05 August 2015 21:17 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2F21AC3C1; Wed, 5 Aug 2015 14:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 aU6SdUfuRlI8; Wed, 5 Aug 2015 14:17:15 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id EF5661AC3BA; Wed, 5 Aug 2015 14:17:14 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 85A99F984; Wed, 5 Aug 2015 17:17:11 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 34AC51FF70; Wed, 5 Aug 2015 23:17:01 +0200 (CEST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Sri Gundavelli \(sgundave\)" <sgundave@cisco.com>, "Bernie Volz \(volz\)" <volz@cisco.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Catherine Meadows <catherine.meadows@nrl.navy.mil>
In-Reply-To: <D1DBA707.1CD95C%sgundave@cisco.com>
References: <D2D64A55-212E-4EED-8545-F0E3ACF8F0CD@nrl.navy.mil> <D1C53A5B.1CA8B1%sgundave@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1CB6B149@xmb-rcd-x04.cisco.com> <55A00090.6060303@cs.tcd.ie> <489D13FBFA9B3E41812EA89F188F018E1CB6B426@xmb-rcd-x04.cisco.com> <D1DBA707.1CD95C%sgundave@cisco.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Wed, 05 Aug 2015 17:17:01 -0400
Message-ID: <87bnelzb8y.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/xilx-f8BLRk_6donP7CmDUQwT1Q>
Cc: "draft-ietf-dhc-access-network-identifier.all@tools.ietf.org" <draft-ietf-dhc-access-network-identifier.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 05 Aug 2015 21:17:18 -0000

On Mon 2015-07-27 12:24:36 -0400, Sri Gundavelli (sgundave) wrote:

> "The information elements that this draft is exposing is the client’s
> access-network information. These pertains to the access network to
> which the client is attached, such as Access Technology Type (Ex:
> WLAN, Ethernet…etc), Access Point Identity (Name, BSSID), Operator
> Id/Realm. Exposing these information elements to an eavesdropper has
> no implication on the end-user security.

This last sentence seems like a bold claim.  Consider a large office
with 20 rooms, a dozen access points, a handful of DHCP relays, and one
DHCP server, with an attacker on the network near the server who wants
to attack any device located in a particular conference room (maybe
there's a meeting going on that they want to listen in on).  Doesn't
exposing the access network information allow such an attacker to target
their attack more effectively?  this seems to have an implication for
end-user security to me.

You imply as much with the next sentence:

> But, in deployments where this information is considered secure and
> when such threat cannot be mitigated using IPsec [RFC4301] or other
> security protocols, then the administrators have to consider disabling
> the capability specified in this document on the DHCP entities."

Maybe just drop the claim that exposing these elements has no
implication for end-user security and keep the rest of the guidance?

There are also potential privacy implications to transmitting this
information, in that it allows tracking of individual devices across
access points by anyone able to record/read the DHCP stream, and those
privacy implications have security consequences as well.  Want to know
when Jane has taken her mobile phone to the lunchroom, leaving her
desktop computer unattended?  Just listen in to the DHCP stream...

Regards,

            --dkg