[secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11

Tero Kivinen <kivinen@iki.fi> Thu, 16 May 2013 21:30 UTC

Return-Path: <kivinen@iki.fi>
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 4E21321F86BB; Thu, 16 May 2013 14:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cAPRypA+xbMv; Thu, 16 May 2013 14:30:18 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 558EA11E80CC; Thu, 16 May 2013 14:29:57 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r4GLTtCT017505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 May 2013 00:29:55 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4GLTt0J019673; Fri, 17 May 2013 00:29:55 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <20885.20435.315856.407689@fireball.kivinen.iki.fi>
Date: Fri, 17 May 2013 00:29:55 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org
X-Mailer: VM 7.19 under Emacs 24.3.1
X-Edit-Time: 15 min
X-Total-Time: 14 min
Subject: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11
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: Thu, 16 May 2013 21:30:22 -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 document specifies a way how the NAS / DHCPv6 relay agent can
take some data it received from the radius server and send it for the
DHCPv6 server. The data includes things like Delegated-IPv6-Prefix,
DNS-Server-IPv6-Address, Delegated-IPv6-Prefix-Pool etc.

In addition to those the IANA registry specifying which options should
forwarded includes Vendor-Specific. 

The connection between the NAS / DHCPv6 relay agent and Radius server
might be protected (encrypted with IPsec), but the connection between
DHCPv6 relay agent and the DHCPv6 server does not have that
possibility (as far as I understand things).

For most of the values forwarded that does not matter, as they are
public to the network anyways, and as
draft-ietf-dhc-dhcpv6-radius-opt-11 says the NAS is trusted network
component. For the Vendor specific that might not be true. It might be
that the vendor specific options returned from the RADIUS server
contains something that might not be public, and as the NAS / DHCPv6
relay agent does not have to select which parts of that to forward (it
will forward all of them), that might leak that vendor specific
information to the network even when the connection between NAS and
the RADIUS server was protected.

I have no idea whether someone might use vendor specific radius
options in such way that this might cause problems, but perhaps adding
note about this to the security considerations section might be

As an (bad) example of that such practice could be that some ISP
somewhere decides to add bithdate of the customer as vendor specific
option to radius, so they can filter out the web sites which are
allowed to be accessed from that client, and as that information has
privacy concerns, they make sure that the connection between NAS and
radius server is encypted. Now when this protocol is deployed those
options gets relayed to the DHCPv6 server in clear, which might not be
what the ISP expected...