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