Subject: Re: [dhcwg] [Review] draft-ietf-dhc-secure-dhcpv6-00

From: Sheng Jiang <[email-masked]>
Date: Wed, 02 Jun 2010 16:52:14 +0800

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jean-Michel Combes
> Sent: Tuesday, June 01, 2010 1:40 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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  <[email-masked]>:
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dhcwg
> >
> >
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 02 Jun 2010 17:34:33 +0800

Oops... an important typo here. A "not" is missed. 

> 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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: Wednesday, June 02, 2010 4:52 PM
> To: 'Jean-Michel Combes'; [email-masked]
> 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>
> > draft-ietf-csi-dhcpv6-cga-ps-02 on the csi WG ML), so, if I am 
> > correct, your proposal doesn't protect against 'rogue'
> generated/configured a CGA 
> > and sends erroneous information signed with the private key 
> > corresponding to its CGA). Or did I miss something?
> > <JMC>
> 
> 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>
> 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>
> 
> > 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
>  
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Jean-Michel Combes
> > draft-ietf-csi-dhcpv6-cga-ps-02 on the csi WG ML), so, if I am 
> > correct, your proposal doesn't protect against 'rogue'
> 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
> > 
> is aiming 
> > to
> >    address of a DHCP message sender, which can be a DHCP server, a 
> > reply
> > 
> > <JMC>
> > s/a reply/a relay
> > <JMC>
> > 
> >    on the link is not assured (such as over wireless) or where 
> > available
> >    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
> >         0                   1                   2           
>         3
> > [Page 6]> > 
> > > > 
> >                        Parameters data structure described 
> in Section 
> > 4
> referred 
> > by
> keys MUST 
> > be
> owner of 
> > an
> >    attached to a DHCPv6 message. The Signature option COULD be any 
> > place
> >         0                   1                   2           
>         3
> > [Page 7]> > 
> > > > 
> >                        In order to provide hash algorithm agility, 
> > SHA-
> > Be careful with this field: as explained in RFC4982, someone may 
> > launch a downgrading attack.
> > <JMC>
> > 
> > Maybe, it would be useful to have the same values (and so the same 
> > length for this field) in your proposal and in 
> client, can 
> > be
> generate 
> > the
> > 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>
> > 
> > [Page 10]> > 
> > > > 
> >                        security associations. Any implementation 
> > SHOULD
> > The consequence is that your proposal cannot be compliant with all 
> > legacy SEND nodes.
> > <JMC>
> > 
> > [snip]
> > 
> > I assume this is where DUID-SA is also used, correct? If so, maybe, 
> > clearly mention this.
> > <JMC>
> > 
> > 
> CGA-EXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cga-ext