[CGA-EXT] [Review] draft-ietf-dhc-secure-dhcpv6-00

[Jean-Michel Combes <[e-mail]>]

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  <[e-mail]>:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>