[CGA-EXT] [Review] draft-ietf-dhc-secure-dhcpv6-00
Jean-Michel Combes <jeanmichel.combes@gmail.com> Mon, 31 May 2010 17:40 UTC
Return-Path: <jeanmichel.combes@gmail.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 D6D033A6884; Mon, 31 May 2010 10:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.672
X-Spam-Level:
X-Spam-Status: No, score=-0.672 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_50=0.001]
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 BaqOXMzFJmOr; Mon, 31 May 2010 10:40:32 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D7B3F28C0EC; Mon, 31 May 2010 10:40:22 -0700 (PDT)
Received: by wwb39 with SMTP id 39so1222067wwb.31 for <multiple recipients>; Mon, 31 May 2010 10:40:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ydL/qbovR5rZv5LItORvBQ6nb9rwotfM65Y1gN/MZKM=; b=llKQHxDWec3KMEjJFHo2csPRd+VVobsom6GLjoRzJ+W5Da7qt19Y9TF5hkv+4ggVmJ JCeoidv9R8DoywiDGdYNDcoi3c0kglDiv2fg/g4jspU5KNYKpcX0QDSObR52UZXR6x+e mpSYlMoboQCjCimsWksd9mx4iu5O68iZFDSXI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=uLZPWj8IjIlDsbsm8B2UbcUpO+Q9GHFSwIvrg5K4A2iVHRFho65Wnw3IqzTgY0056o yEGqw0hdM+QkG49o7yYl5v+4kEGgpyBPPx8FTuWVarXcIpMsySfvIyBwVQn7MrT29BJH eoJGhSve3+p8/+tCSl7sUbJHfCnae6RPXvfa4=
MIME-Version: 1.0
Received: by 10.227.141.137 with SMTP id m9mr4490951wbu.202.1275327604712; Mon, 31 May 2010 10:40:04 -0700 (PDT)
Received: by 10.216.161.203 with HTTP; Mon, 31 May 2010 10:40:04 -0700 (PDT)
Date: Mon, 31 May 2010 19:40:04 +0200
Message-ID: <AANLkTindZm3srILoYvxoLGmlOqtENgsW9qg8wbAuob4w@mail.gmail.com>
From: Jean-Michel Combes <jeanmichel.combes@gmail.com>
To: Internet-Drafts@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dhcwg@ietf.org, cga-ext@ietf.org
Subject: [CGA-EXT] [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: Mon, 31 May 2010 17:40:43 -0000
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.txt > > 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 > >
- [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