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

Tero Kivinen <kivinen@iki.fi> Fri, 17 May 2013 18:47 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA20421F96E5; Fri, 17 May 2013 11:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EwVVQIbdPQq; Fri, 17 May 2013 11:47:12 -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 785BC21F9705; Fri, 17 May 2013 11:47:10 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r4HIl5JV016829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 May 2013 21:47:05 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4HIl3Q8024131; Fri, 17 May 2013 21:47:03 +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: <20886.31527.670959.767940@fireball.kivinen.iki.fi>
Date: Fri, 17 May 2013 21:47:03 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Leaf Yeh" <leaf.yeh.sdo@gmail.com>
In-Reply-To: <51967458.22d9440a.44f5.7843@mx.google.com>
References: <20885.20435.315856.407689@fireball.kivinen.iki.fi> <51967458.22d9440a.44f5.7843@mx.google.com>
X-Mailer: VM 7.19 under Emacs 24.3.1
X-Edit-Time: 19 min
X-Total-Time: 19 min
Cc: draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org, 'Tomek Mrugalski' <tomasz.mrugalski@gmail.com>, 'Ted Lemon' <Ted.Lemon@nominum.com>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [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: Fri, 17 May 2013 18:47:13 -0000

Leaf Yeh writes:
> Tero - 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...
> 
> I believe the DHCPv6 server does not really need the privacy information
> (eg. birth_date) for its address/prefix (or other parameters) assignment,
> and the relay in this case could just forward the possible VAS RADIUS
> attribute to the server.

I agree that it does not need those, but even as section 5 says that
"relay agent MAY include", i.e. it is not mandated to include all
vendor specific attributes (I assume VAS = vendor specific?), there is
guidance what options to include. 

> How about to add the following text in section 8,
> 'Network administrators should be aware that although RADIUS messages are
> encrypted, DHCPv6 messages can not be encrypted. It is possible that some
> VAS RADIUS attributes might contain the sensitive or confidential
> information. Network administrators are strongly advised to prevent
> including such information into DHCPv6 messages.'?

That addition text seems to be just what I was looking for. Perfect,
but better still spell out the VAS, as it is not currently used in
draft.

BTW, while reading the section 4.1. I noticed following text:

     New RADIUS attributes
   MAY be added to this list after the IETF Expert Review [RFC5226].

I do not think MAY is suitable there. The IANA allocation rules either
are or are not, there is no MAY in there...

Also this same text is also in the section 9, so it might be enough to
remove it from here, and fix the section 9 to say:

  The allocation policy of this 'RADIUS attributes permitted in DHCPv6
  RADIUS option' registry is Expert Review [RFC5226].

(Note, that Expert might not really be IETF Expert, it might also be
just for example RADIUS Expert in this case).

Also I do not think the SHOULD statement given to the Expert (again
better remove the IETF and talk about Expert or Designated Expert)
should just say that without capital letters. Implementors quite often
check all MUST/SHOULD etc to make sure they are done, and finding this
kind of text just causes extra work for them, and if you have skipped
some MUST/SHOULD you need to explain why you did not implement it...
:-)
-- 
kivinen@iki.fi