Re: [CGA-EXT] [dhcwg] [Review] draft-ietf-dhc-secure-dhcpv6-00
Sheng Jiang <shengjiang@huawei.com> Wed, 02 June 2010 09:35 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 B8D843A6985; Wed, 2 Jun 2010 02:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.735
X-Spam-Level: *
X-Spam-Status: No, score=1.735 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, 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 N3+jLGZ05oAw; Wed, 2 Jun 2010 02:35:01 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8858D3A67A5; Wed, 2 Jun 2010 02:35:00 -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 <0L3D00A82RXO20@szxga03-in.huawei.com>; Wed, 02 Jun 2010 17:34:37 +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 <0L3D00LE3RXNV2@szxga03-in.huawei.com>; Wed, 02 Jun 2010 17:34:35 +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 <0L3D008M7RXLK0@szxml04-in.huawei.com>; Wed, 02 Jun 2010 17:34:35 +0800 (CST)
Date: Wed, 02 Jun 2010 17:34:33 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <003d01cb0230$e5c80d90$ab626e0a@china.huawei.com>
To: 'Sheng Jiang' <shengjiang@huawei.com>, 'Jean-Michel Combes' <jeanmichel.combes@gmail.com>, Internet-Drafts@ietf.org
Message-id: <004301cb0236$cfe211a0$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: AcsA6Gi/nijYKiAzRKih0I494eJMYgBR1w0gAAGci/A=
Cc: dhcwg@ietf.org, cga-ext@ietf.org
Subject: Re: [CGA-EXT] [dhcwg] [Review] draft-ietf-dhc-secure-dhcpv6-00
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: Wed, 02 Jun 2010 09:35:07 -0000
Oops... an important typo here. A "not" is missed. > > <JMC> > > "However, IPSec is quite complicated." > > May you clearly explain why, please? > > <JMC> > > Given the requirements of IPSEC installation and connection > negotiation process, assuming availability of IPSEC > connection is "NOT" practical for most scenarios where DHCPv6 is used. Sheng > -----Original Message----- > From: cga-ext-bounces@ietf.org > [mailto:cga-ext-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: Wednesday, June 02, 2010 4:52 PM > To: 'Jean-Michel Combes'; Internet-Drafts@ietf.org > Cc: dhcwg@ietf.org; cga-ext@ietf.org > Subject: Re: [CGA-EXT] [dhcwg] [Review] > draft-ietf-dhc-secure-dhcpv6-00 > > Hi, Jean, > > Indeed, your comments are very help. Most of your editorial > comments will be addressed in the next update. The following > are clarifying explanation for several questions: > > > <JMC> > > There is no text about authorization (cf. my comments on > > draft-ietf-csi-dhcpv6-cga-ps-02 on the csi WG ML), so, if I am > > correct, your proposal doesn't protect against 'rogue' > > DHCP server (i.e. the rogue DHCP server has > generated/configured a CGA > > and sends erroneous information signed with the private key > > corresponding to its CGA). Or did I miss something? > > <JMC> > > No, there is no clear authorization support in this document. > It is the nature of CGA, actually. > However, the authorization can be reached if the CGA > generated from a certificated public & private key pair. In > another word, a DHCP server and its client may be > pre-configured authorization information from the same > authorize. Then, when CGA gets verified, the authorization is > also reached. > > > <JMC> > > "However, IPSec is quite complicated." > > May you clearly explain why, please? > > <JMC> > > Given the requirements of IPSEC installation and connection > negotiation process, assuming availability of IPSEC > connection is practical for most scenarios where DHCPv6 is used. > > > <JMC> HA-id and HA-id-KH > > Be careful with this field: as explained in RFC4982, someone may > > launch a downgrading attack. > > <JMC> > > If assuming practical brute force on SHA1, yes. > > > <JMC> > > In RFC3972, the RSA key length SHOULD be at least 384 bits. > > The consequence is that your proposal cannot be compliant with all > > legacy SEND nodes. > > <JMC> > > First, there is no direct contradiction between RFC3972" The > RSA key length SHOULD be at least 384 bits " and this draft " > The minimum acceptable key length for public keys used in the > generation of CGAs. The default SHOULD be 1024 bits". Given > that 384 bit RSA is not a wide accepted secure length, 1024 > is recommended here. > > > <JMC> > > In Section 5.2, it is said "The Signature option COULD be any place > > within the DHCPv6 message.". So, what is the correct policy > regarding > > the location of the Signature option? > > <JMC> > > In priciple, the signature option should be the last one to > be generated and normally be the last one in order. However, > in RFC3315, auth option has been defined to be the last one. > So if auth option is in used, the signature may be the second > last. However, as the same with other options, the location > of the signature option is not enfored. It can be different > in different implementation and it does not harm. > > Best regards, > > Sean & Sheng > > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org > [mailto:dhcwg-bounces@ietf.org] On Behalf > > Of Jean-Michel Combes > > Sent: Tuesday, June 01, 2010 1:40 AM > > To: Internet-Drafts@ietf.org > > Cc: dhcwg@ietf.org; cga-ext@ietf.org > > Subject: [dhcwg] [Review] draft-ietf-dhc-secure-dhcpv6-00 > > > > Hi, > > > > please, find a review of this document: > > > > > > Secure DHCPv6 Using CGAs > > draft-ietf-dhc-secure-dhcpv6-00.txt > > > > > > <JMC> > > There is no text about authorization (cf. my comments on > > draft-ietf-csi-dhcpv6-cga-ps-02 on the csi WG ML), so, if I am > > correct, your proposal doesn't protect against 'rogue' > > DHCP server (i.e. the rogue DHCP server has > generated/configured a CGA > > and sends erroneous information signed with the private key > > corresponding to its CGA). Or did I miss something? > > <JMC> > > > > > > 1. Introduction > > > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6 > [RFC3315]) > > enables DHCP servers to pass configuration parameters. It offers > > configuration flexibility. If not secured, DHCPv6 is > vulnerable to > > various attacks, particularly fake attack. > > > > The requirements of using CGA to secure DHCPv6 have been > introduced > > in [I-D.draft-ietf-csi-dhcpv6-cga-ps]. This document analyzes the > > security issues of DHCPv6 in more details. This document > is aiming > > to > > provide mechanisms for improving the security of DHCPv6, thus the > > address of a DHCP message sender, which can be a DHCP server, a > > reply > > > > <JMC> > > s/a reply/a relay > > <JMC> > > > > agent or a client, is able to be verified by a receiver. > > It improves > > communication security of DHCPv6 interaction. The security > > mechanisms > > specified in this document is mainly based on the > Cryptographically > > Generated Addresses (CGA [RFC3972]). > > > > Secure DHCPv6 is applicable in environments where > physical security > > on the link is not assured (such as over wireless) or where > > available > > security mechanisms are not sufficient, and attacks on > DHCPv6 are a > > concern. > > > > [snip] > > > > 3. Security Overview of DHCPv6 > > > > [snip] > > > > Communication between a server and a relay agent, and > communication > > between relay agents, can be secured through the use of IPSec, as > > described in section 21.1 in [RFC3315]. However, IPSec is quite > > complicated. A simpler security mechanism may have better deploy > > > > <JMC> > > "However, IPSec is quite complicated." > > May you clearly explain why, please? > > <JMC> > > > > ability. Furthermore, the manual configuration and > static keys are > > potential issue makers. Relay agents MAY require other security > > mechanisms besides IPSec. > > > > <JMC> > > s/IPSec/IPsec > > <JMC> > > > > [snip] > > > > 5. Extension for Secure DHCPv6 > > > > This section extends DHCPv6. Two new options and a new DUID type > > have > > been defined. The new options MUST be supported, if the node has > > been > > configured to use Secure DHCPv6. The new DUID type MUST be > > supported > > in the relay scenarios. > > > > 5.1. CGA Parameter Option > > > > The CGA option allows the verification of the sender's CGAs. The > > format of the CGA option is described as follows: > > > > 0 1 2 > 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | OPTION_CGA_PARAMETER | option-len > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > . > > . > > . CGA Parameters (variable length) > > . > > . > > . > > | > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > <JMC> > > OPTION_CGA_PARAMATER is 15 bits long and option-len is 17 > bits long: I > > assume this is a typo :) <JMC> > > > > > > > > Jiang & Shen Expires October 12, 2010 > > [Page 6]> > > > > > > > Internet-Draft draft-ietf-dhc-secure-dhcpv6-00.txt > April 2010 > > > > option-code OPTION_CGA_PARAMETER (TBA1). > > > > option-len Length of CGA Parameters in octets. > > > > CGA Parameters A variable-length field containing the CGA > > Parameters data structure described > in Section > > 4 > > of [RFC3972]. This specification > requires that > > the public key found from the CGA Parameters > > field in the CGA option MUST be that > referred > > by > > the Key Hash field in the Signature option. > > Packets received with two different > keys MUST > > be > > silently discarded. Note that a future > > extension > > MAY provide a mechanism allowing the > owner of > > an > > address and the signer to be > different parties. > > > > 5.2. Signature Option > > > > The Signature option allows public key-based signatures to be > > attached to a DHCPv6 message. The Signature option COULD be any > > place > > within the DHCPv6 message. It protects all the DHCPv6 header and > > options before it. Any options after the Signature option can be > > processed, but it should be noticed that they are not > protected by > > this Signature option. The format of the Signature option is > > described as follows: > > > > 0 1 2 > 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | OPTION_SIGNATURE | option-len > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | HA-id | SA-id > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | HA-id-KH | Reserved > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Timestamp (64-bit) > > | > > | > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > | Key Hash (128-bit) > > | > > | > > | > > | > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > . Signature (variable length) > > . > > . > > . > > . > > . > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > <JMC> > > Same comment as above about a typo: > > OPTION_SIGNATURE/HA-id/HA-id-KH are 15 bits long and > > option-len/SA-id/Reserved are 17 bits long. > > <JMC> > > > > option-code OPTION_SIGNATURE (TBA2). > > > > > > > > Jiang & Shen Expires October 12, 2010 > > [Page 7]> > > > > > > > Internet-Draft draft-ietf-dhc-secure-dhcpv6-00.txt > April 2010 > > > > option-len 32 + Length of signature field in octets. > > > > HA-id Hash Algorithm id. The hash algorithm is used > > for computing the signature result. RSA > > signature [RSA] with SHA-1 [sha-1] > is adopted. > > In order to provide hash algorithm agility, > > SHA- > > 1 is assigned an initial value 0x0000 in this > > document. > > > > <JMC> > > Be careful with this field: as explained in RFC4982, someone may > > launch a downgrading attack. > > <JMC> > > > > SA-id Signature Algorithm id. The signature > algorithm > > is used for computing the signature > result. RSA > > signature with RSASSA-PKCS1-v1_5 algorithm is > > adopted. In order to provide > algorithm agility, > > RSASSA_PKCS1-v1_5 is assigned an > initial value > > 0x0000 in this document. > > > > <JMC> > > Maybe, it would be useful to have the same values (and so the same > > length for this field) in your proposal and in > > draft-cheneau-csi-send-sig-agility. > > <JMC> > > > > HA-id-KH Hash Algorithm id for Key Hash. Hash > algorithm > > used for producing the Key Hash field in the > > Signature option. SHA-1 is adopted. > In order to > > provide hash algorithm agility, SHA-1 is > > assigned an initial value 0x0000 in this > > document. > > > > <JMC> > > IMHO, as commented above, a downgrading attack may be > possible or did > > I miss something? > > <JMC> > > > > [snip] > > > > 6. Processing Rules and Behaviors > > > > 6.1. Processing Rules of Sender > > > > A DHCPv6 node, which could be a server, relay agent or > client, can > > be > > configured to send Secure DHCPv6 messages only if CGAs have been > > configured on it. > > > > The node MUST record the following configuration information: > > > > CGA parameters Any information required to > construct CGAs, as > > described in [RFC3972]. > > > > Keypair A public-private key pair. The public key used > > for constructing the signature MUST > be the same > > in CGA parameters. > > > > CGA flag A flag that indicates whether CGA is > > used or not. > > > > If a node has been configured to use Secure DHCPv6, the node MUST > > send a message using a CGA, which be constructed as specified in > > Section 4 of [RFC3972], as the source address unless > they are sent > > with the unspecified source address. In the message, both the CGA > > option and the Signature option MUST be present in all DHCPv6 > > messages. The CGA Parameter field in the CGA option is filled > > according to the rules presented above and in [RFC3972]. > The public > > key in the field is taken from the configuration used to > generate > > the > > CGA, typically from a data structure associated with the source > > address. The Signature option MUST be constructed as explained in > > Section 5.2 and be the last DHCPv6 option. > > > > <JMC> > > In Section 5.2, it is said "The Signature option COULD be any place > > within the DHCPv6 message.". So, what is the correct policy > regarding > > the location of the Signature option? > > <JMC> > > > > In relay scenario, a DHCPv6 server MUST include an > OPTION_SERVERID > > [RFC3315] in Relay-reply message and put its CGA in the Server > > Address field of the DUID in the OPTION_SERVERID. The > CGA of DHCPv6 > > > > <JMC> > > I assume this is where DUID-SA is used, correct? If so, > maybe, clearly > > mention this. > > <JMC> > > > > server will not lose during relaying so that the client > can verify > > CGA address and signature. > > > > > > 6.2. Processing Rules of Receiver > > > > The node that supports the verification of the Secure > > DHCPv6 messages > > MUST record the following configuration information: > > > > Minbits The minimum acceptable key length for public > > keys used in the generation of CGAs. > > The default > > SHOULD be 1024 bits. Implementations MAY also > > set an upper limit for the amount of > > computation > > > > > > Jiang & Shen Expires October 12, 2010 > > [Page 10]> > > > > > > > Internet-Draft draft-ietf-dhc-secure-dhcpv6-00.txt > April 2010 > > > > needed when verifying packets that use these > > security associations. Any implementation > > SHOULD > > follow prudent cryptographic practice in > > determining the appropriate key lengths. > > > > <JMC> > > In RFC3972, the RSA key length SHOULD be at least 384 bits. > > The consequence is that your proposal cannot be compliant with all > > legacy SEND nodes. > > <JMC> > > > > [snip] > > > > In the relay scenarios, a DHCPv6 server obtains the CGA > of a client > > from the peer address field in the Relay-forward > message. A DHCPv6 > > client obtains the CGA of a server from the Server > Address field of > > the DUID in the OPTION_SERVERID. > > > > <JMC> > > I assume this is where DUID-SA is also used, correct? If so, maybe, > > clearly mention this. > > <JMC> > > > > > > Hope that may help you and thanks in advance for your reply. > > > > Best regards. > > > > JMC. > > > > > > 2010/4/12 <Internet-Drafts@ietf.org>: > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > This draft is a work item of the Dynamic Host Configuration > > Working Group of the IETF. > > > > > > > > > Title : Secure DHCPv6 Using CGAs > > > Author(s) : S. Jiang > > > Filename : draft-ietf-dhc-secure-dhcpv6-00.txt > > > Pages : 15 > > > Date : 2010-04-12 > > > > > > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > > enables DHCP > > > servers to pass configuration parameters. It offers configuration > > > flexibility. If not secured, DHCPv6 is vulnerable to > > various attacks, > > > particularly fake attack. This document analyzes the > > security issues > > > of DHCPv6 and specifies security mechanisms, mainly using CGAs. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-secure-dhcpv6-00.tx > > > t > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext
- [CGA-EXT] [Review] draft-ietf-dhc-secure-dhcpv6-00 Jean-Michel Combes
- Re: [CGA-EXT] [dhcwg] [Review] draft-ietf-dhc-sec… Sheng Jiang
- Re: [CGA-EXT] [dhcwg] [Review] draft-ietf-dhc-sec… Sheng Jiang