Re: [CGA-EXT] FW: New Version Notification for draft-ietf-csi-dhcpv6-cga-ps-02
Sheng Jiang <shengjiang@huawei.com> Tue, 29 June 2010 01:24 UTC
Return-Path: <shengjiang@huawei.com>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E4B3A6A1B for <cga-ext@core3.amsl.com>; Mon, 28 Jun 2010 18:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.223
X-Spam-Level: *
X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXjjYcTPvLB4 for <cga-ext@core3.amsl.com>; Mon, 28 Jun 2010 18:23:59 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BDC9E3A6A0E for <cga-ext@ietf.org>; Mon, 28 Jun 2010 18:23:58 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4R00C9C57Y87@szxga03-in.huawei.com> for cga-ext@ietf.org; Tue, 29 Jun 2010 09:23:58 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4R0082O57YSS@szxga03-in.huawei.com> for cga-ext@ietf.org; Tue, 29 Jun 2010 09:23:58 +0800 (CST)
Received: from j66104a ([10.110.98.171]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4R008WQ57YFM@szxml04-in.huawei.com> for cga-ext@ietf.org; Tue, 29 Jun 2010 09:23:58 +0800 (CST)
Date: Tue, 29 Jun 2010 09:23:58 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <AANLkTimvpbOjgWpIESxRgVLcD1XN4oJRUlmiafdGMCtr@mail.gmail.com>
To: 'Jean-Michel Combes' <jeanmichel.combes@gmail.com>
Message-id: <002401cb1729$bfa01af0$ab626e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Thread-index: AcsA54sFgZK5puylTVuNEEAorTPlqgWQe2Tg
Cc: cga-ext@ietf.org
Subject: Re: [CGA-EXT] FW: New Version Notification for draft-ietf-csi-dhcpv6-cga-ps-02
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2010 01:24:00 -0000
Hi, Jean, Thanks so much for your comments. It does help us to improve our draft. All your comments have been addressed in the new 03 version. http://tools.ietf.org/html/draft-ietf-csi-dhcpv6-cga-ps-03 Sorry for taking so long to react. I was in travels for a couple of assignment. Best regards, Sheng > -----Original Message----- > From: Jean-Michel Combes [mailto:jeanmichel.combes@gmail.com] > Sent: Tuesday, June 01, 2010 1:35 AM > To: Sheng Jiang > Cc: cga-ext@ietf.org > Subject: Re: [CGA-EXT] FW: New Version Notification for > draft-ietf-csi-dhcpv6-cga-ps-02 > > Hi Sheng, > > please, find a review of your document: > > > DHCPv6 and CGA Interaction: Problem Statement > > draft-ietf-csi-dhcpv6-cga-ps-02.txt > > > [snip] > > 1. Introduction > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] > can assign addresses statefully. Although there are other ways to > assign IPv6 addresses [RFC4862, RFC4339], DHCPv6 is still > useful when > > <JMC> > I don't understand why RFC4339 is referenced because RFC4339 > describes main ways to get the IP address of a DNS server. > Now, IMHO, you may mention RFC5739. > <JMC> > > an administrator requires more control over address assignments to > hosts. DHCPv6 can also be used to distribute other network > configuration information. > > [snip] > > 2. Coexistence of DHCPv6 and CGA > > CGAs can be used with IPv6 Stateless Address Configuration > [RFC4862]. > The public key system associated with the CGA address provides > message origin validation and integrity protection without the need > for negotiation and transportation of key materials. > > The current CGA specifications do not mandate which device > generates > a CGA address. In many cases, a CGA address is generated by the > associated key pair owner, which normally is also the host > that will > use the CGA address. However, in a DHCPv6-managed network, hosts > should obtain IPv6 addresses only from a DHCPv6 server. This > > <JMC> > s/hosts should obtain IPv6 addresses/hosts should use IPv6 > global addresses The reason is because nothing prevents an > node generating an IPv6 address which is already the case > with Link Local addresses. > <JMC> > > difference of roles needs to be carefully considered if there is a > requirement to use CGAs in DHCPv6-managed environments. > > [snip] > > 4. What CGA can do for DHCPv6 > > [snip] > > Using CGAs in DHCPv6 protocol can efficiently improve the > security of > DHCPv6, because the address of a DHCPv6 message sender > (which can be > a DHCPv6 server, a reply agent or a client) can be verified by a > receiver. The usage of CGA can efficiently avoid the abovementioned > attacks. It improves the communication security of DHCPv6 > > <JMC> > "The usage of CGA can efficiently avoid the abovementioned attacks." > IMHO, it is not correct: the use of CGA allows to check that > the IP source address is really owned by the sender and the > integrity of the sent data if they are signed with the > private key associated to the public key used to generate the > CGA. Nothing prevents a 'rogue' DHCPv6 server/relay > generating its own CGA and send erroneous information (as > mentioned in the text about the attacks). > The missing point here, but which is mentioned in the last > paragraph of this section, is that a node may not be aware of > what is the DHCP relay/server's IP address (i.e. the node may > only know the well-known > DHCPv6 Multicast addresses). IMHO, the issue is more or less > like for Router Advertisement messages security (i.e. is the > owner's IP source address authorized to be a router?) <JMC> > > interactions. The usage of CGAs can also avoid DHCPv6's > dependence on > IPSEC [RFC3315] in relay scenarios. This mechanism is applicable in > > <JMC> > s/IPSEC/IPsec > <JMC> > > environments where physical security on the link is not > assured (such > as over certain wireless infrastructures) or where > available security > mechanisms are not sufficient, and attacks on DHCPv6 are a concern. > > A CGA generated from an unauthorized public & private key pair can > prove the source address ownership and provide data integrity > protection. > > Furthermore, A CGA generated from a certificated public & > private key > pair can also achieve authorization for DHCPv6 servers or > relays, or > on another direction, user authorization. The public keys > may be pre- > configured on both parties of communication or have a third party > authority available for users to retrieve public keys. The public > keys will be used for users to generate CGAs and verify CGAs and > signatures. The pre-configuration can also include configuring more > CGA parameters such as SEC value or more depend on > policies. The pre- > configuration can even be the whole CGA and related parameters, but > in this case the address will be fixed and this situation > may not be > desired when users want to keep their addresses unknown. > > <JMC> > In the last sentence, who are the users? DHCP relay/server? > DHCP clients? > <JMC> > > > > Hope that may help you and thanks in advance for your reply. > > Best regards. > > JMC. > > 2010/4/23 Sheng Jiang <shengjiang@huawei.com>: > > A new version has been submitted. Comments from Alberto has been > > addressed in this version. Further comments are welcome. > > > > Regards, > > > > Sheng > > > >> -----Original Message----- > >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >> Sent: Friday, April 23, 2010 10:14 AM > >> To: shengjiang@huawei.com > >> Subject: New Version Notification for > draft-ietf-csi-dhcpv6-cga-ps-02 > >> > >> > >> A new version of I-D, draft-ietf-csi-dhcpv6-cga-ps-02.txt has been > >> successfully submitted by Sheng Jiang and posted to the IETF > >> repository. > >> > >> Filename: draft-ietf-csi-dhcpv6-cga-ps > >> Revision: 02 > >> Title: DHCPv6 and CGA Interaction: Problem > Statement > >> Creation_date: 2010-04-22 > >> WG ID: csi > >> Number_of_pages: 9 > >> > >> Abstract: > >> This document describes potential issues in the interaction between > >> DHCPv6 and Cryptographically Generated Addresses (CGAs). > >> Firstly, the scenario of using CGAs in DHCPv6 environments is > >> discussed. > >> Some > >> operations are clarified for the interaction of DHCPv6 servers and > >> CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may > >> have mutual benefits for each other, including using CGAs > in DHCPv6 > >> operations to enhance its security features and using DHCPv6 to > >> provide the CGA generation function. > >> > >> > >> > >> > >> The IETF Secretariat. > >> > >> > > > > _______________________________________________ > > CGA-EXT mailing list > > CGA-EXT@ietf.org > > https://www.ietf.org/mailman/listinfo/cga-ext > >
- [CGA-EXT] FW: New Version Notification for draft-… Sheng Jiang
- Re: [CGA-EXT] FW: New Version Notification for dr… Behcet Sarikaya
- Re: [CGA-EXT] FW: New Version Notification for dr… Sheng Jiang
- Re: [CGA-EXT] FW: New Version Notification for dr… Jean-Michel Combes
- Re: [CGA-EXT] FW: New Version Notification for dr… Sheng Jiang