Re: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11
"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Fri, 17 May 2013 18:18 UTC
Return-Path: <leaf.yeh.sdo@gmail.com>
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 604E121F96EA; Fri, 17 May 2013 11:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 TRg9q+fMFf5g; Fri, 17 May 2013 11:18:02 -0700 (PDT)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 40B0821F9700; Fri, 17 May 2013 11:18:02 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id kp6so3798829pab.21 for <multiple recipients>; Fri, 17 May 2013 11:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=W2lZTZwTEyvkpfAoxFX3dafv82FylNRnRsuCyg7lZYM=; b=MWJydwtk5oyAs9rs+VRVivgKFXW87GIJI7TZlXpD0KLJtJCjw1UHRxHBuX7UgbVdT6 N4uXn9ujg2d3+fqL2rDmizmIX4og91o4zrDmOpB5jvoZSw6ZxyKlAtnlnLy2S9H2CHl1 kBzSPDM4Gg/o8xtDfLsUtI9tE61hRqq7k+i99h+fPGPpBlLTnfid0kekGwhsxLISRVmr tOafWE3pfRduhyTeLHzQHYFf7sAWF+DoOIoZOg/k+hBd9nPEk8qinlQ/aW2efyq4wRAv ZueASSf2SpvjSW+Z3E1aMs6XUBnQFy4TfMAcN2baLww3eXx4qbGHPLl0z8nm14mWtYQ1 8HIg==
X-Received: by 10.66.248.228 with SMTP id yp4mr49855108pac.158.1368814681623; Fri, 17 May 2013 11:18:01 -0700 (PDT)
Received: from PC ([221.223.164.6]) by mx.google.com with ESMTPSA id ov2sm12107303pbc.34.2013.05.17.11.17.58 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 17 May 2013 11:18:00 -0700 (PDT)
From: Leaf Yeh <leaf.yeh.sdo@gmail.com>
To: 'Tero Kivinen' <kivinen@iki.fi>, iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org
References: <20885.20435.315856.407689@fireball.kivinen.iki.fi>
In-Reply-To: <20885.20435.315856.407689@fireball.kivinen.iki.fi>
Date: Sat, 18 May 2013 02:17:45 +0800
Message-ID: <51967458.22d9440a.44f5.7843@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac5SfIdRl5ehIv75Q0eiMu1AI5br3wAmu9pw
Content-Language: zh-cn
X-Mailman-Approved-At: Sat, 18 May 2013 08:09:39 -0700
Cc: 'Tomek Mrugalski' <tomasz.mrugalski@gmail.com>, 'Ted Lemon' <Ted.Lemon@nominum.com>
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:18:08 -0000
Tero - 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 appropriate. Any suggested text on it? 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. 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.'? Best Regards, Leaf -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Friday, May 17, 2013 5:30 AM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org Subject: Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11 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 appropriate. 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... -- kivinen@iki.fi
- [secdir] Secdir review of draft-ietf-dhc-dhcpv6-r… Tero Kivinen
- Re: [secdir] Secdir review of draft-ietf-dhc-dhcp… Tero Kivinen
- Re: [secdir] Secdir review of draft-ietf-dhc-dhcp… Ted Lemon
- Re: [secdir] Secdir review of draft-ietf-dhc-dhcp… Leaf Yeh
- Re: [secdir] Secdir review of draft-ietf-dhc-dhcp… Leaf Yeh
- Re: [secdir] Secdir review of draft-ietf-dhc-dhcp… Tero Kivinen
- Re: [secdir] Secdir review of draft-ietf-dhc-dhcp… Leaf Yeh